[Qemu-devel] [PATCH v2] spapr: make sure RMA is in first mode of first memory node

[Alexey Kardashevskiy]

The SPAPR specification says that the RMA starts at the LPAR's logical
address 0 and is the first logical memory block reported in
the LPAR’s device tree.

So SLOF only maps the first block and that block needs to span
the full RMA.

This makes sure that the RMA area is where SLOF expects it.

Cc: Benjamin Herrenschmidt 
Signed-off-by: Alexey Kardashevskiy 
---

I came up with v1 of the patch but the actual code came from
Alexander Graf. Who should I put as author of this?

---
 hw/ppc/spapr.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 57b38cf..57473df 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1114,6 +1114,7 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
 MemoryRegion *sysmem = get_system_memory();
 MemoryRegion *ram = g_new(MemoryRegion, 1);
 hwaddr rma_alloc_size;
+hwaddr node0_size = (nb_numa_nodes > 1) ? node_mem[0] : ram_size;
 uint32_t initrd_base = 0;
 long kernel_size = 0, initrd_size = 0;
 long load_limit, rtas_limit, fw_size;
@@ -1138,7 +1139,7 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
 if (rma_alloc_size && (rma_alloc_size < ram_size)) {
 spapr->rma_size = rma_alloc_size;
 } else {
-spapr->rma_size = ram_size;
+spapr->rma_size = node0_size;
 
 /* With KVM, we don't actually know whether KVM supports an
  * unbounded RMA (PR KVM) or is limited by the hash table size
@@ -1155,6 +1156,12 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
 }
 }
 
+if (spapr->rma_size > node0_size) {
+fprintf(stderr, "Error: Numa node 0 has to span the RMA 
(%#08"HWADDR_PRIx")\n",
+spapr->rma_size);
+exit(1);
+}
+
 /* We place the device tree and RTAS just below either the top of the RMA,
  * or just below 2GB, whichever is lowere, so that it can be
  * processed with 32-bit real mode code if necessary */
-- 
1.8.4.rc4

Re: [Qemu-devel] [PATCH 1/2] pc: add etc/e820 fw_cfg file

[Gerd Hoffmann]

On Di, 2013-11-05 at 18:48 +0100, Andrea Arcangeli wrote:
> Hi,
> 
> On Mon, Nov 04, 2013 at 01:17:10PM +0100, Gerd Hoffmann wrote:
> > Unlike the existing FW_CFG_E820_TABLE entry which carries reservations
> > only the new etc/e820 file also has entries for RAM.
> 
> Acked, it looks the best the way to go if the objective is to keep
> backwards compatibility with older seabios protocol.
> 
> I have to trust you on why we need to stay backwards compatible at all
> times and why we can't commit an updated bios.bin before a new seabios
> stable release happened.

It's seabios policy, for good reasons.  Basically because it is a PITA
in certain cases if there are strict version requirements.  Also note
that seabios isn't the only possible firmware for qemu.

> About the file, I wonder what happens if too many people starts to use
> files and we'll run out of FW_CFG_FILE_SLOTS at runtime (assert(index
> < FW_CFG_FILE_SLOTS);).

Probably we should simply raise the number of slots.  We don't have
allocated any FW_CFG slots behind the file slot range yet, so there is
space.  Also there is a count in the file list struct and firmware uses
that to figure how many files are there and dynamically allocate memory
for the list, so growing the list shouldn't cause problems on the
firmware side too.

> Probably one patch could be added to
> s/FW_CFG_E820_TABLE/FW_CFG_E820_TABLE_OLD/, otherwise if somebody read
> fw_cfg.h, it won't be apparent that the grepping shouldn't stop there
> to reach the real e820 map.

Yep, either that or a comment.  Also there are more obsolete fw_cfg
entries I think.  Isn't the num_cpus entry superseded by numa info?

cheers,
  Gerd

Re: [Qemu-devel] [PATCH uq/master] pci-assign: Remove dead code for direct I/O region access from userspace

[Gleb Natapov]

Alex can you review please?

On Mon, Nov 04, 2013 at 02:42:55PM +0100, Jan Kiszka wrote:
> This feature was already deprecated back then in qemu-kvm, ie. before
> pci-assign went upstream. assigned_dev_ioport_rw will never be invoked
> with resource_fd < 0.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  hw/i386/kvm/pci-assign.c | 56 
> +---
>  1 file changed, 10 insertions(+), 46 deletions(-)
> 
> diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
> index 011764f..4e65110 100644
> --- a/hw/i386/kvm/pci-assign.c
> +++ b/hw/i386/kvm/pci-assign.c
> @@ -154,55 +154,19 @@ static uint64_t 
> assigned_dev_ioport_rw(AssignedDevRegion *dev_region,
>  uint64_t val = 0;
>  int fd = dev_region->region->resource_fd;
>  
> -if (fd >= 0) {
> -if (data) {
> -DEBUG("pwrite data=%" PRIx64 ", size=%d, e_phys=" TARGET_FMT_plx
> -  ", addr="TARGET_FMT_plx"\n", *data, size, addr, addr);
> -if (pwrite(fd, data, size, addr) != size) {
> -error_report("%s - pwrite failed %s",
> - __func__, strerror(errno));
> -}
> -} else {
> -if (pread(fd, &val, size, addr) != size) {
> -error_report("%s - pread failed %s",
> - __func__, strerror(errno));
> -val = (1UL << (size * 8)) - 1;
> -}
> -DEBUG("pread val=%" PRIx64 ", size=%d, e_phys=" TARGET_FMT_plx
> -  ", addr=" TARGET_FMT_plx "\n", val, size, addr, addr);
> +if (data) {
> +DEBUG("pwrite data=%" PRIx64 ", size=%d, e_phys=" TARGET_FMT_plx
> +  ", addr="TARGET_FMT_plx"\n", *data, size, addr, addr);
> +if (pwrite(fd, data, size, addr) != size) {
> +error_report("%s - pwrite failed %s", __func__, strerror(errno));
>  }
>  } else {
> -uint32_t port = addr + dev_region->u.r_baseport;
> -
> -if (data) {
> -DEBUG("out data=%" PRIx64 ", size=%d, e_phys=" TARGET_FMT_plx
> -  ", host=%x\n", *data, size, addr, port);
> -switch (size) {
> -case 1:
> -outb(*data, port);
> -break;
> -case 2:
> -outw(*data, port);
> -break;
> -case 4:
> -outl(*data, port);
> -break;
> -}
> -} else {
> -switch (size) {
> -case 1:
> -val = inb(port);
> -break;
> -case 2:
> -val = inw(port);
> -break;
> -case 4:
> -val = inl(port);
> -break;
> -}
> -DEBUG("in data=%" PRIx64 ", size=%d, e_phys=" TARGET_FMT_plx
> -  ", host=%x\n", val, size, addr, port);
> +if (pread(fd, &val, size, addr) != size) {
> +error_report("%s - pread failed %s", __func__, strerror(errno));
> +val = (1UL << (size * 8)) - 1;
>  }
> +DEBUG("pread val=%" PRIx64 ", size=%d, e_phys=" TARGET_FMT_plx
> +  ", addr=" TARGET_FMT_plx "\n", val, size, addr, addr);
>  }
>  return val;
>  }
> -- 
> 1.8.1.1.298.ge7eed54

--
Gleb.

Re: [Qemu-devel] USB Passthrough not working for Windows 7 guest

[Jan Kiszka]

On 2013-11-05 21:20, Jens Frederich wrote:
>> On 2013-11-05 17:01, Frederich, Jens wrote:
>>> Hi all,
>>>
>>> we're currently evaluating different RTOS systems (Windows CE, Intime, RTX,
>>> etc.).
>>> One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all
>>> works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one
>>> QEMU bug
>>> breaks my measurement setup and evaluation.
>>>
>>> I've some usb devices for the Windows 7 guest. I configure them as USB
>>> passthrough.
>>> The devices appears in the device manager of Windows 7, but with
>>> "Error code 10": device cannot start". The Windows driver fails on USB set
>>> configuration.
>>> The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL
>>> fails with
>>> invalid parameter.
>>>
>>> driver log:
>>> 0009  0.65470564  vnCDrvUsbControlRequestSetConfiguration,
>>> WdfUsbTargetDeviceSelectConfig single interface failed 0xc00d
>>> 0010  0.65472370  vnCDrvUsbIFPrepareHardwareState,
>>> vnCDrvUsbControlRequestSetConfiguration failed: 0xc00d
>>> 0011  0.65473646  vnCDrvDevConPrepareHardware,
>>> vnCDrvUsbIFPrepareHardwareState failed 0xc00d
>>> 0012  0.65474838  vnCDrvEvtDevicePrepareHardware,
>>> vnCDrvDevConPrepareHardware failed 0xc001
>>> 0013  0.6547
>>>
>>> This bug breaks my latency measurement setup and Linux RT is out of the
>>> evaluationg
>>> race. Windows CE should not win :-), it there anyway workaround or hack to
>>> fix the issue?
>>
>> Workaround: Pass-through one of the (typically) many USB host
>> controllers to the Windows guest (vfio or classic pci-assign). I did
>> this back then when *HCI emulation was still pretty immature.
>>
>> But USB device pass-through should also work. Do you happen to pass a
>> USB 2.0 device via an emulated UHCI? Or are you already using the EHCI
>> emulation?
> 
> I'm not sure which mode it has been. I've used the virt-manager to configure
> the device. A usb controller is already configured in mode 'default'.
> My steps on virt-manager:
> 
> 1. add hardware
> 2. select usb host device
> 3. I can see my usb device, I select it
> 4. start guest and open Windows device manager

Unfortunately, I do not know what virt-manager is configuring by
default. It likely also depends on its version, so you should share this
information as well. Maybe other folks here can comment on this.

> 
> I don't know is this UHCI or EHCI? On the usb host device list are
> some controller listed e.q. xhci, ehci and so on. Should I map these
> controller to Windows 7 as well?

Pick the host controller to which the USB device you want to give to the
guest is attached to (lsusb and the bus number reported via
/sys/bus/pci/devices//usbX can tell this - or trial and error). When
doing this, you no longer need to pass through the USB device itself, it
is implicitely passed.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH] spapr: add "compat" machine option

[Paul Mackerras]

On Mon, Sep 30, 2013 at 01:25:32PM +0200, Alexander Graf wrote:
> 
> On 27.09.2013, at 10:06, Alexey Kardashevskiy wrote:
> 
> > To be able to boot on newer hardware that the software support,
> > PowerISA defines a logical PVR, one per every PowerISA specification
> > version from 2.04.
[snip]
> > +case 205:
> > +spapr->arch_compat = CPU_POWERPC_LOGICAL_2_05;
> > +break;
> > +case 206:
> > +spapr->arch_compat = CPU_POWERPC_LOGICAL_2_06;
> 
> Does it make sense to declare compat mode a number or would a string be 
> easier for users? I can imagine that "-machine compat=power6" is easier to 
> understand for a user than "-machine compat=205".

That's probably true.  I don't mind either way.

> Also, we need to handle failure. If the kernel can not set the CPU to 2.05 
> mode for example (IIRC POWER8 doesn't allow you to) we should bail out here.

POWER8 does have 2.05 (POWER6) and 2.06 (POWER7) compatibility modes.

> > +/* Architecture compatibility mode */
> > +uint32_t arch_compat;
> 
> Do we really need to carry this in the vcpu struct? Or can we just 
> fire-and-forget about it? If we want to preserve anything, it should be the 
> PCR register.

There are two relevant values here; the compatibility mode (if any)
that the user has requested via the command line, and the mode that
has been negotiated with the ibm,client-architecture-support (CAS)
call.  CAS should select the latest mode supported by the guest that
is not later than the mode requested on the command line, and is
supported by QEMU, and is not later than the architecture of the
host.  Both values should be sent across to the destination VM on
migration AFAICS.

On reset/reboot, the compatibility mode should not change.  The device
tree that is supplied to the new SLOF instance should reflect the
current compatibility mode.

Regards,
Paul.

Re: [Qemu-devel] [PATCH v2] cpu-exec: Fix compiler warning (-Werror=clobbered)

[Stefan Weil]

Am 05.11.2013 19:03, schrieb Andreas Färber:
> Am 05.11.2013 18:52, schrieb Stefan Weil:
>> Am 31.10.2013 20:41, schrieb Jan Kiszka:
>>> On 2013-10-31 20:31, Stefan Weil wrote:
 Reloading of local variables after sigsetjmp is only needed for some
 buggy compilers.

 The code which should reload these variables causes compiler warnings
 with gcc 4.7 when compiler optimizations are enabled:

 cpu-exec.c:204:15: error:
  variable ‘cpu’ might be clobbered by ‘longjmp’ or ‘vfork’
>> [-Werror=clobbered]
 cpu-exec.c:207:15: error:
  variable ‘cc’ might be clobbered by ‘longjmp’ or ‘vfork’
>> [-Werror=clobbered]
 cpu-exec.c:202:28: error:
  argument ‘env’ might be clobbered by ‘longjmp’ or ‘vfork’
>> [-Werror=clobbered]
 Now this code is only used for compilers which need it
 (and gcc 4.5.x, x > 0 which does not need it but won't give warnings).

 There were bug reports for clang and gcc 4.5.0, while gcc 4.5.1
 was reported to work fine without the reload code.

 Signed-off-by: Stefan Weil 
 ---

 v2: Don't remove the code which causes the warnings, but use it
 only with clang or gcc < 4.6.

  cpu-exec.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/cpu-exec.c b/cpu-exec.c
 index 30cfa2a..fec20c3 100644
 --- a/cpu-exec.c
 +++ b/cpu-exec.c
 @@ -677,14 +677,18 @@ int cpu_exec(CPUArchState *env)
 only be set by a memory fault) */
  } /* for(;;) */
  } else {
 -/* Reload env after longjmp - the compiler may have
>> smashed all
 - * local variables as longjmp is marked 'noreturn'. */
 +#if defined(__clang__) || !QEMU_GNUC_PREREQ(4, 6)
 +/* Some compilers wrongly smash all local variables after
 + * siglongjmp. There were bug reports for gcc 4.5.0 and
>> clang.
 + * Reload essential local variables here for those
>> compilers.
 + * gcc 4.7 would complain about this code (-Wclobbered). */
  cpu = current_cpu;
  env = cpu->env_ptr;
  #if !(defined(CONFIG_USER_ONLY) && \
(defined(TARGET_M68K) || defined(TARGET_PPC) ||
>> defined(TARGET_S390X)))
  cc = CPU_GET_CLASS(cpu);
  #endif
 +#endif /* __clang__ or old gcc */
  }
  } /* for(;;) */


>>> Are all clang versions affected? Then this looks reasonable.
>>>
>>> Jan
>> Ping?
>>
>> As cpu-exec.c has no explicit maintainer, I'd add this patch to my next
>> pull request, if nobody minds, but I'd appreciate more comments or a
>> Reviewed-by of course.
> I feel kind of responsable for this as CPU maintainer, but I wasn't
> CC'ed and have not been following the list so closely lately. ;)
>
> It seems the person reporting this for FreeBSD hasn't been CC'ed either?
>
> Having applied the previous patch complementing the reload, I'm
> generally okay with #ifdef'ing it out. But I'd be happier if Jan and/or
> Peter or anyone else would provide some *-by, including Tested-by.
>
> Regards,
> Andreas

Tested-by is not really useful here because the code change is trivial:

Either you have a clang compiler (which sets __clang__, already used
in other parts of QEMU), or you have an old gcc- in both cases the
compilation result remains unchanged.

Or you have a compiler which never needed the additional code.
Then QEMU will work like it did before the reload code was added.

Testing might be useful if anybody had the time to install and test lots of
gcc and clang (and maybe others) compiler versions, but I am rather
sure that nobody wants to do this :-)

Adding assertions in an #else part as Peter suggested is possible.
I have them in my QEMU repository, too. Feel free to add them, or
I can also send a v3 if this is needed.

I cc this mail to Dimitry who reported the clang problem and to Jürgen
who fixed it.

Regards,
Stefan

Re: [Qemu-devel] [PATCH v2] linux-user: Fix stat64 syscall for SPARC64

[Stefan Weil]

Am 31.10.2013 05:33, schrieb Erik de Castro Lopo:
> Stefan Weil wrote:
>
>> Some targets use a stat64 structure for the stat64 syscall while others
>> use a stat structure. SPARC64 used the wrong kind.
>>
>> Instead of extending the conditional compilation in syscall.c, now a
>> macro TARGET_HAS_STRUCT_STAT64 is defined whenever a target has a
>> target_stat64.
>>
>> Signed-off-by: Stefan Weil 
> Reviewed-by: Erik de Castro Lopo 

Ping?

Peter, maybe you want to review this patch? I slightly modified your
suggestion.

Riku, could you please include the patch in your queue (allow Peter to
review it before)?

Thanks,
Stefan

[Qemu-devel] [PATCH v2] qmp: access the local QemuOptsLists for drive option

[Amos Kong]

Currently we have three QemuOptsList (qemu_common_drive_opts,
qemu_legacy_drive_opts, and qemu_drive_opts), only qemu_drive_opts
is added to vm_config_groups[].

This patch changes query-command-line-options to access three local
QemuOptsLists for drive option, and merge the description items
together.

Signed-off-by: Amos Kong 
---
V2: access local QemuOptsLists for drive (kevin)
---
 blockdev.c |  1 -
 include/qemu/config-file.h |  1 +
 include/sysemu/sysemu.h|  2 ++
 util/qemu-config.c | 77 +-
 vl.c   |  3 ++
 5 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index b260477..f09f991 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -47,7 +47,6 @@
 #include "sysemu/arch_init.h"
 
 static QTAILQ_HEAD(drivelist, DriveInfo) drives = 
QTAILQ_HEAD_INITIALIZER(drives);
-extern QemuOptsList qemu_common_drive_opts;
 
 static const char *const if_name[IF_COUNT] = {
 [IF_NONE] = "none",
diff --git a/include/qemu/config-file.h b/include/qemu/config-file.h
index ad4a9e5..508428f 100644
--- a/include/qemu/config-file.h
+++ b/include/qemu/config-file.h
@@ -8,6 +8,7 @@
 QemuOptsList *qemu_find_opts(const char *group);
 QemuOptsList *qemu_find_opts_err(const char *group, Error **errp);
 void qemu_add_opts(QemuOptsList *list);
+void qemu_add_drive_opts(QemuOptsList *list);
 int qemu_set_option(const char *str);
 int qemu_global_option(const char *str);
 void qemu_add_globals(void);
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index cd5791e..495dae8 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -193,6 +193,8 @@ QemuOpts *qemu_get_machine_opts(void);
 
 bool usb_enabled(bool default_usb);
 
+extern QemuOptsList qemu_legacy_drive_opts;
+extern QemuOptsList qemu_common_drive_opts;
 extern QemuOptsList qemu_drive_opts;
 extern QemuOptsList qemu_chardev_opts;
 extern QemuOptsList qemu_device_opts;
diff --git a/util/qemu-config.c b/util/qemu-config.c
index a59568d..867fb4b 100644
--- a/util/qemu-config.c
+++ b/util/qemu-config.c
@@ -8,6 +8,7 @@
 #include "qmp-commands.h"
 
 static QemuOptsList *vm_config_groups[32];
+static QemuOptsList *drive_config_groups[4];
 
 static QemuOptsList *find_list(QemuOptsList **lists, const char *group,
Error **errp)
@@ -77,6 +78,59 @@ static CommandLineParameterInfoList 
*query_option_descs(const QemuOptDesc *desc)
 return param_list;
 }
 
+/* remove repeated entry from the info list */
+static void cleanup_infolist(CommandLineParameterInfoList *head)
+{
+CommandLineParameterInfoList *pre_entry, *cur, *del_entry;
+
+cur = head;
+while (cur->next) {
+pre_entry = head;
+while (pre_entry != cur->next) {
+if (!strcmp(pre_entry->value->name, cur->next->value->name)) {
+del_entry = cur->next;
+cur->next = cur->next->next;
+g_free(del_entry);
+break;
+}
+pre_entry = pre_entry->next;
+}
+cur = cur->next;
+}
+}
+
+/* merge the description items of two parameter infolists */
+static void connect_infolist(CommandLineParameterInfoList *head,
+ CommandLineParameterInfoList *new)
+{
+CommandLineParameterInfoList *cur;
+
+cur = head;
+while (cur->next) {
+cur = cur->next;
+}
+cur->next = new;
+}
+
+/* access all the local QemuOptsLists for drive option */
+static CommandLineParameterInfoList *get_drive_infolist(void)
+{
+CommandLineParameterInfoList *head = NULL, *cur;
+int i;
+
+for (i = 0; drive_config_groups[i] != NULL; i++) {
+if (!head) {
+head = query_option_descs(drive_config_groups[i]->desc);
+} else {
+cur = query_option_descs(drive_config_groups[i]->desc);
+connect_infolist(head, cur);
+}
+}
+cleanup_infolist(head);
+
+return head;
+}
+
 CommandLineOptionInfoList *qmp_query_command_line_options(bool has_option,
   const char *option,
   Error **errp)
@@ -89,7 +143,12 @@ CommandLineOptionInfoList 
*qmp_query_command_line_options(bool has_option,
 if (!has_option || !strcmp(option, vm_config_groups[i]->name)) {
 info = g_malloc0(sizeof(*info));
 info->option = g_strdup(vm_config_groups[i]->name);
-info->parameters = query_option_descs(vm_config_groups[i]->desc);
+if (!strcmp("drive", vm_config_groups[i]->name)) {
+info->parameters = get_drive_infolist();
+   } else {
+info->parameters =
+query_option_descs(vm_config_groups[i]->desc);
+}
 entry = g_malloc0(sizeof(*entry));
 entry->value = info;
 entry->next = conf_list;
@@ -109,6 +168,22 @@ QemuOpts

[Qemu-devel] [Bug 1248376] [NEW] "fstenv" gets the wrong result in qemu 1.6.1

[Minghua Wang]

Public bug reported:

The float instruction "fstenv" gets the wrong result, when I tested it
in QEMU 1.6.1.

The detailed testing environments are: 
1)the QEMU's guest OS is 32-bit windows 7 professional.(version: 6.1.7600). 
2)the QEMU's host machine I used is 64-bit Fedora Core 13.


I used the following command line to compile QEMU 1.6.1:
./configure --target-list=i386-softmmu
make 
make install

Then, I launched the QEMU guest with the following command:
qemu-system-i386  xxx.img  -m  1024M


Here are some more details:
03FA0005 DAC7   fcmovb st,st(7)
03FA0007 D97424 F4 fstenv (28-byte) ptr ss:[esp-0xC]
03FA000B 5Bpop ebx
03FA000C 33C9   xor ecx,ecx

when 0x03FA000B: pop ebx finished excuting,  the value of ebx should be
0x03FA0005. But in QEMU 1.6.1+windows 7 pro(32 bit) which was described
above, ebx's wrongly turned out to be 0x0!

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1248376

Title:
  "fstenv" gets the wrong result in qemu 1.6.1

Status in QEMU:
  New

Bug description:
  The float instruction "fstenv" gets the wrong result, when I tested it
  in QEMU 1.6.1.

  The detailed testing environments are: 
  1)the QEMU's guest OS is 32-bit windows 7 professional.(version: 6.1.7600). 
  2)the QEMU's host machine I used is 64-bit Fedora Core 13.

  
  I used the following command line to compile QEMU 1.6.1:
  ./configure --target-list=i386-softmmu
  make 
  make install

  Then, I launched the QEMU guest with the following command:
  qemu-system-i386  xxx.img  -m  1024M


  Here are some more details:
  03FA0005 DAC7   fcmovb st,st(7)
  03FA0007 D97424 F4 fstenv (28-byte) ptr ss:[esp-0xC]
  03FA000B 5Bpop ebx
  03FA000C 33C9   xor ecx,ecx

  when 0x03FA000B: pop ebx finished excuting,  the value of ebx should
  be 0x03FA0005. But in QEMU 1.6.1+windows 7 pro(32 bit) which was
  described above, ebx's wrongly turned out to be 0x0!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1248376/+subscriptions

Re: [Qemu-devel] [PATCH 1.7] pc: get rid of builtin pvpanic for "-M pc-1.5"

[Anthony Liguori]

Paolo Bonzini  writes:

> This causes two slight backwards-incompatibilities between "-M pc-1.5"
> and 1.5's "-M pc":

Can you rebase this?  It no longer applies because of the acpi building
changes.

Regards,

Anthony Liguori

>
> (1) a fw_cfg file is removed with this patch.  This is only a problem
> if migration stops the virtual machine exactly during fw_cfg enumeration.
>
> (2) after migration, a VM created without an explicit "-device pvpanic"
> will stop reporting panics to management.
>
> The first problem only occurs if migration is done at a very, very
> early point (and I'm not sure it can happen in practice for reasonable-size
> VMs, since it will likely take more time to send the RAM to destination,
> than it will take for BIOS to scan fw_cfg).
>
> The second problem only occurs if the guest panics _and_ has a guest
> driver _and_ management knows to look at the crash event, so it is
> mostly theoretical at this point in time.
>
> Thus keep the code simple, and pretend it was never broken.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/i386/pc_piix.c| 7 ---
>  hw/i386/pc_q35.c | 7 ---
>  hw/misc/pvpanic.c| 5 -
>  include/hw/i386/pc.h | 3 ---
>  4 files changed, 22 deletions(-)
>
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index c6042c7..a041e53 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -57,7 +57,6 @@ static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, 0x170 };
>  static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
>  static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
>  
> -static bool has_pvpanic;
>  static bool has_pci_info = true;
>  
>  /* PC hardware initialisation */
> @@ -225,10 +224,6 @@ static void pc_init1(QEMUMachineInitArgs *args,
>  if (pci_enabled) {
>  pc_pci_device_init(pci_bus);
>  }
> -
> -if (has_pvpanic) {
> -pvpanic_init(isa_bus);
> -}
>  }
>  
>  static void pc_init_pci(QEMUMachineInitArgs *args)
> @@ -245,13 +240,11 @@ static void pc_compat_1_6(QEMUMachineInitArgs *args)
>  static void pc_compat_1_5(QEMUMachineInitArgs *args)
>  {
>  pc_compat_1_6(args);
> -has_pvpanic = true;
>  }
>  
>  static void pc_compat_1_4(QEMUMachineInitArgs *args)
>  {
>  pc_compat_1_5(args);
> -has_pvpanic = false;
>  x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
>  x86_cpu_compat_set_features("Westmere", FEAT_1_ECX, 0, 
> CPUID_EXT_PCLMULQDQ);
>  }
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index ca84e1c..593ed2a 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -47,7 +47,6 @@
>  /* ICH9 AHCI has 6 ports */
>  #define MAX_SATA_PORTS 6
>  
> -static bool has_pvpanic;
>  static bool has_pci_info = true;
>  
>  /* PC hardware initialisation */
> @@ -214,10 +213,6 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
>  if (pci_enabled) {
>  pc_pci_device_init(host_bus);
>  }
> -
> -if (has_pvpanic) {
> -pvpanic_init(isa_bus);
> -}
>  }
>  
>  static void pc_compat_1_6(QEMUMachineInitArgs *args)
> @@ -229,13 +224,11 @@ static void pc_compat_1_6(QEMUMachineInitArgs *args)
>  static void pc_compat_1_5(QEMUMachineInitArgs *args)
>  {
>  pc_compat_1_6(args);
> -has_pvpanic = true;
>  }
>  
>  static void pc_compat_1_4(QEMUMachineInitArgs *args)
>  {
>  pc_compat_1_5(args);
> -has_pvpanic = false;
>  x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
>  x86_cpu_compat_set_features("Westmere", FEAT_1_ECX, 0, 
> CPUID_EXT_PCLMULQDQ);
>  }
> diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
> index b64e3bb..4c85906 100644
> --- a/hw/misc/pvpanic.c
> +++ b/hw/misc/pvpanic.c
> @@ -112,11 +112,6 @@ static void pvpanic_isa_realizefn(DeviceState *dev, 
> Error **errp)
>  isa_register_ioport(d, &s->io, s->ioport);
>  }
>  
> -void pvpanic_init(ISABus *bus)
> -{
> -isa_create_simple(bus, TYPE_ISA_PVPANIC_DEVICE);
> -}
> -
>  static Property pvpanic_isa_properties[] = {
>  DEFINE_PROP_UINT16("ioport", PVPanicState, ioport, 0x505),
>  DEFINE_PROP_END_OF_LIST(),
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 6083839..f6313b2 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -213,9 +213,6 @@ static inline bool isa_ne2000_init(ISABus *bus, int base, 
> int irq, NICInfo *nd)
>  void pc_system_firmware_init(MemoryRegion *rom_memory,
>   bool isapc_ram_fw);
>  
> -/* pvpanic.c */
> -void pvpanic_init(ISABus *bus);
> -
>  /* e820 types */
>  #define E820_RAM1
>  #define E820_RESERVED   2
> -- 
> 1.8.3.1

Re: [Qemu-devel] [PATCH] spapr: add "compat" machine option

[Paul Mackerras]

On Tue, Nov 05, 2013 at 10:06:04AM +0100, Paolo Bonzini wrote:
> Il 30/09/2013 14:57, Alexey Kardashevskiy ha scritto:
> >> > Why is the option under -machine instead of -cpu?
> > Because it is still the same CPU and the guest will still read the real
> > PVR from the hardware (which it may not support but this is why we need
> > compatibility mode).
> 
> How do you support migration from a newer to an older CPU then? 

PowerVM has supported this for years, so there are well-established
interfaces that existing guest kernels use for this.

Basically, the hypervisor can put the CPU into a mode where the
processor behaves when in user mode according to an earlier version of
the architecture.  POWER8 conforms to architecture 2.07, and it has a
register with bits that allow it to be put into an architecture 2.05
(POWER6) mode or an architecture 2.06 (POWER7) mode.  In 2.05 mode,
none of the instructions and registers that are new in POWER7 and
POWER8 are available in user mode, and in 2.06 mode, none of the
facilities that are new in POWER8 are available in user mode.

The other thing the hypervisor does is tell the guest which
architecture mode the CPU is running in via a property in the device
tree.  Linux kernels use that to determine the list of hardware
features that they can use.

Under PowerVM, if you are running a guest on a POWER8 (say) and you
want to be able to be able to migrate to a POWER6 later on, you have
to run the guest in architecture 2.05 mode, even if the guest knows
about later architecture versions.

> I think
> the guest should never see anything about the hardware CPU model.

The architecture doesn't let us do that, but our guest kernels are
accustomed to largely ignoring the actual PVR and operating on the
basis of the architecture level that we tell them via the device
tree.

Regards,
Paul.

Re: [Qemu-devel] [PATCH 2/6] qapi: rename MonitorEvent to QEvent

[Wenchao Xia]

于 2013/11/5 22:06, Luiz Capitulino 写道:

On Tue, 05 Nov 2013 13:31:09 +0800
Wenchao Xia  wrote:


于 2013/11/5 10:51, Luiz Capitulino 写道:

On Tue, 05 Nov 2013 10:17:28 +0800
Wenchao Xia  wrote:


于 2013/11/4 21:33, Luiz Capitulino 写道:

On Mon, 04 Nov 2013 09:59:50 +0800
Wenchao Xia  wrote:


于 2013/11/1 22:02, Luiz Capitulino 写道:

On Mon, 21 Oct 2013 10:16:01 +0800
Wenchao Xia  wrote:


Signed-off-by: Wenchao Xia 
---
 block.c|2 +-
 include/block/block_int.h  |2 +-
 include/monitor/monitor.h  |6 +++---
 monitor.c  |   12 ++--
 stubs/mon-protocol-event.c |2 +-
 ui/vnc.c   |2 +-
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/block.c b/block.c
index 2c15e5d..458a4f8 100644
--- a/block.c
+++ b/block.c
@@ -1760,7 +1760,7 @@ void bdrv_set_dev_ops(BlockDriverState *bs, const 
BlockDevOps *ops,
 }

 void bdrv_emit_qmp_error_event(const BlockDriverState *bdrv,
-   MonitorEvent ev,
+   QEvent ev,
BlockErrorAction action, bool is_read)
 {
 QObject *data;
diff --git a/include/block/block_int.h b/include/block/block_int.h
index bcc72e2..bfdaf84 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -337,7 +337,7 @@ AioContext *bdrv_get_aio_context(BlockDriverState *bs);
 int is_windows_drive(const char *filename);
 #endif
 void bdrv_emit_qmp_error_event(const BlockDriverState *bdrv,
-   MonitorEvent ev,
+   QEvent ev,
BlockErrorAction action, bool is_read);

 /**
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 10fa0e3..8b14a6f 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -20,7 +20,7 @@ extern Monitor *default_mon;
 #define MONITOR_CMD_ASYNC   0x0001

 /* QMP events */
-typedef enum MonitorEvent {
+typedef enum QEvent {


Qt has a QEvent class, so QEvent is not a good name for us if we're
considering making it public in the schema (which could become an
external library in the distant future).

I suggest calling it QMPEvent.



  Maybe QMPEventType, since QMPEvent should be used an union?


If we add the 'event' type, like:

{ 'event': 'BLOCK_IO_ERROR', 'data': { ... } }

Then we don't need an union.



 It would bring a little trouble to C code caller, for example the
event generate function(just like monitor_protocol_event) would be:
event_generate(QMPEvent *e);


Hmm, no.

Today, events are open-coded and an event's definition lives in the code,
like the DEVICE_TRAY_MOVED event:

static void bdrv_emit_qmp_eject_event(BlockDriverState *bs, bool ejected)
{
  QObject *data;

  data = qobject_from_jsonf("{ 'device': %s, 'tray-open': %i }",
bdrv_get_device_name(bs), ejected);
  monitor_protocol_event(QEVENT_DEVICE_TRAY_MOVED, data);

  qobject_decref(data);
}

Having an union for the event's names saves some typing elsewhere, but
it doesn't solve the problem of having the event definition in the code.
Adding event type support to the QAPI does solve this problem.

Taking the DEVICE_TRAY_MOVED event as an example, we would have the
following entry in the qapi-schema.json file:

{ 'event': 'DEVICE_TRAY_MOVED', 'data': { 'device': 'str',
'tray-open': 'bool' } }

Then the QAPI generator would generate this function:

void qmp_send_event_device_tray_moved(const char *device, bool tray_open);

This function uses visitors to build a qobject which is then passed
to monitor_protocol_event(), along with the event name. Also note that
monitor_protocol_event() could take the event name as a string, which
completely eliminates the current enum MonitorEvent.

I believe this is the direction we want to go wrt events.



It seems a different direction: let QAPI generator recognize
keyword 'event', and generate emit functions.


Yes, the same way we have it for QMP commands.


My draft is a bit different:
caller:

QMPEvent *e = g_malloc0(sizeof(QMPEvent));
e->kind = QMP_EVENT_TYPE_DEVICE_TRAY_MOVED;
e->device_tray_moved = g_malloc0(sizeof(QMPEventDeviceTrayMoved));
e->device_tray_moved->device = g_strdup("ide0-hd");
e->device_tray_moved->tray_open = false;
qmp_event_generate(e);
qapi_free_QMPEvent(e);

Then qmp_event_generate() will use visitors to build qobject and then
emit it.


Seems a lot more complex to me, we're going to write a lot of code if
we do this.



  OK, it is a good enough reason, I'll write qapi-event.py to get
qapi-event.h and qapi-event.c.


Compared with above, I think qmp_send_event_device_tray_moved()
method saves malloc and free calls, other things are similar(My draft
tells the caller how to set value by structure define, while your way
tells it by func

Re: [Qemu-devel] [PATCH RFC 07/10] qapi script: support direct inheritance for struct

[Wenchao Xia]

于 2013/11/5 21:41, Eric Blake 写道:

On 11/04/2013 05:37 PM, Wenchao Xia wrote:

Now it is possible to inherit another struct inside data directly,
which saves trouble to define trivial structure.

Signed-off-by: Wenchao Xia 
---
  docs/qapi-code-gen.txt |   21 +
  scripts/qapi-visit.py  |   14 ++
  2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index 0728f36..3e42ff4 100644
--- a/docs/qapi-code-gen.txt
+++ b/docs/qapi-code-gen.txt
@@ -70,6 +70,27 @@ both fields like this:
   { "file": "/some/place/my-image",
 "backing": "/some/place/my-backing-file" }

+It is possible to directly inherit other struct by keyword '_base':
+
+ { 'type': 'NetworkConnectionInfo', 'data': { 'host': 'str', 'service': 'str' 
} }
+ { 'type': 'VncConnectionInfo',
+   'data': {
+  'server': {
+  '_base': 'NetworkConnectionInfo',


Interesting idea for shorthand.  However, I would suggest that you pick
a different character than '_', since '_' is valid in names.  That is,
we already have special handling of leading '*' to mark a field as
optional, so I suggest something like '^' to mark a base class.  By
using a non-name character, it becomes more obvious that the leading
character has a special meaning to the qapi generator.

I'm also not convinced yet that we want this shorthand; in particular,
I'm worried whether it will make the introspection patches harder to write.


  I am not sure about this approach either, so put RFC tag on it. The
purpose is allow not to define structures that would be only used once.

  What instrospection patch do you mean? Python instrospection
mechnism? You mean there is a python utility which recognize
only keyword "base" now?

[Qemu-devel] [PATCH V6 5/5] blockdev: Add infinite loop check in drive_init()

[Xu Wang]

Check the backing file for a loop during image boot, to avoid a lack or
response or segfault.

Signed-off-by: Xu Wang 
---
 blockdev.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/blockdev.c b/blockdev.c
index b260477..7c0927f 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -510,6 +510,12 @@ static DriveInfo *blockdev_init(QDict *bs_opts,
 
 bdrv_flags |= ro ? 0 : BDRV_O_RDWR;
 
+/* Add backing file loop check */
+if (!bdrv_backing_chain_okay(file, drv ? drv->format_name : NULL)) {
+error_report("drive_init: backing file loop check failed");
+goto err;
+}
+
 QINCREF(bs_opts);
 ret = bdrv_open(dinfo->bdrv, file, bs_opts, bdrv_flags, drv, &error);
 
-- 
1.8.1.4

[Qemu-devel] [PATCH V6 3/5] block: Add check infinite loop in bdrv_img_create()

[Xu Wang]

Backing file loop should be checked before qemu-img create command
execution. If loop is found, qemu-img create should be stopped and
an error printed.

Signed-off-by: Xu Wang 
---
 block.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/block.c b/block.c
index 3443117..8423e80 100644
--- a/block.c
+++ b/block.c
@@ -4670,15 +4670,15 @@ void bdrv_img_create(const char *filename, const char 
*fmt,
 }
 
 backing_file = get_option_parameter(param, BLOCK_OPT_BACKING_FILE);
+backing_fmt = get_option_parameter(param, BLOCK_OPT_BACKING_FMT);
 if (backing_file && backing_file->value.s) {
-if (!strcmp(filename, backing_file->value.s)) {
-error_setg(errp, "Error: Trying to create an image with the "
- "same filename as the backing file");
+if (!bdrv_new_chain_okay(filename, backing_file->value.s,
+backing_fmt->value.s)) {
+error_report("bdrv_img_create: loop exists, image create failed");
 goto out;
 }
 }
 
-backing_fmt = get_option_parameter(param, BLOCK_OPT_BACKING_FMT);
 if (backing_fmt && backing_fmt->value.s) {
 backing_drv = bdrv_find_format(backing_fmt->value.s);
 if (!backing_drv) {
-- 
1.8.1.4

[Qemu-devel] [PATCH V6 0/5] Refine and export backing file loop check

[Xu Wang]

If there is loop exists in the backing file chain, many problems
could be caused by it, such as no response and segment fault during
system boot. Hence stopping backing file loop appear is very necessary.
These patches refine and export loop checking function from collect_image_
info_list() to block.c and build a independent function named bdrv_
backing_file_loop_check(). Backing file loop checking is added before
image created, before change backing file and before system boot.

Updates from V5:
  1. Simplify the function of loop checking (Just filename comparation.
 Thanks Eric's suggestion).
  2. Delete WIN32 platform support (There is no need to this patch now).
  3. Adjust position of backing file loop checking (calling checking function
 before change happen).
  4. Function name updates and comments description fix.

Updates from V4:
  1. Add backing file loop check in bdrv_new_open().
  2. Adjust open file logic of collect_image_info_list() (bdrv_new_open()
 is called only once when opening the whole chain).
  3. Remove redundant brackets in lnk file check logic.
  4. Add error output in bdrv_img_create().
  5. Remove MAX_PATH_LEN to use PATH_MAX instead.

Updates from V3:
  1. Comments fix for function bdrv_backing_file_loop_check().
  2. Add ret check for fseek()/fread() in get_lnk_target_file().
  3. Add limit of shortcuts filename length reading during comparing.
  4. Add error_report() in driv_init().
  5. Remove redundant loop check in qcow2/qed_change_backing_file().

Updates from V2:
  1. Removed parameter @chain from bdrv_backing_file_loop_check()
  2. Comments and format fix, all patches were checked by checkpatch.pl
  3. Fixed *bs leak.
  4. Improved logic of .lnk file recognization.
  5. Add filename lenth limit check in while()
  6. Changed get_win_inode() to get_inode() and move all inode get method
 into it to make logic more simpler.
  7. Added value of @fmt as suggested.
  8. Added backing file loop check in qcow2.c/qed.c

Xu Wang (5):
  block/qemu-img: Refine and export infinite loop checking in
collect_image_info_list()
  qemu-img: Add infinite loop checking in bdrv_new_open()
  block: Add check infinite loop in bdrv_img_create()
  block: Add backing file loop check in change_backing_file()
  blockdev: Add infinite loop check in drive_init()

 block.c   | 130 --
 blockdev.c|   6 +++
 include/block/block.h |   4 ++
 qemu-img.c|  52 ++--
 4 files changed, 162 insertions(+), 30 deletions(-)

-- 
1.8.1.4

[Qemu-devel] [PATCH V6 4/5] block: Add backing file loop check in change_backing_file()

[Xu Wang]

Backing file loop should be checked before calling change_backing_
file(). If loop appeared, this calling should be stopped and an
error printed.

Signed-off-by: Xu Wang 
---
 block.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/block.c b/block.c
index 8423e80..cb50bfd 100644
--- a/block.c
+++ b/block.c
@@ -2083,6 +2083,11 @@ int bdrv_change_backing_file(BlockDriverState *bs,
 return -EINVAL;
 }
 
+/* Check if loop exists in backing files chain after change */
+if (!bdrv_new_chain_okay(bs->filename, backing_file, backing_fmt)) {
+return -EIO;
+}
+
 if (drv->bdrv_change_backing_file != NULL) {
 ret = drv->bdrv_change_backing_file(bs, backing_file, backing_fmt);
 } else {
-- 
1.8.1.4

[Qemu-devel] [PATCH V6 2/5] qemu-img: Add infinite loop checking in bdrv_new_open()

[Xu Wang]

Every image should be checked if there is infinite loop in backing
file chain before open it. So infinite loop check was added into
bdrv_new_open(). If @filename is opened without the flag
BDRV_O_NO_BACKING, the infinite loop check should be called.

Signed-off-by: Xu Wang 
---
 qemu-img.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/qemu-img.c b/qemu-img.c
index d5ec45b..3af7996 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -281,6 +281,14 @@ static BlockDriverState *bdrv_new_open(const char 
*filename,
 drv = NULL;
 }
 
+/* check backing file loop if the whole chain need to be opened */
+if (!(flags & BDRV_O_NO_BACKING) &&
+!bdrv_backing_chain_okay(filename, fmt)) {
+error_report("bdrv_new_open: Open %s failed. There is loop exists "
+ "in the backing chain", filename);
+goto fail;
+}
+
 ret = bdrv_open(bs, filename, NULL, flags, drv, &local_err);
 if (ret < 0) {
 error_report("Could not open '%s': %s", filename,
-- 
1.8.1.4

[Qemu-devel] [PATCH V6 1/5] block/qemu-img: Refine and export infinite loop checking in collect_image_info_list()

[Xu Wang]

If there is a loop in the backing file chain, it could cause problems
such as no response or a segfault during system boot. Hence detecting a
backing file loop is necessary. This patch extracts the loop check from
collect_image_info_list() in block.c into independent functions
bdrv_backing_chain_okay() and bdrv_image_create_okay().

Signed-off-by: Xu Wang 
---
 block.c   | 117 ++
 include/block/block.h |   4 ++
 qemu-img.c|  44 ---
 3 files changed, 139 insertions(+), 26 deletions(-)

diff --git a/block.c b/block.c
index 58efb5b..3443117 100644
--- a/block.c
+++ b/block.c
@@ -4490,6 +4490,123 @@ bdrv_acct_done(BlockDriverState *bs, BlockAcctCookie 
*cookie)
 bs->total_time_ns[cookie->type] += get_clock() - cookie->start_time_ns;
 }
 
+static gboolean str_equal_func(gconstpointer a, gconstpointer b)
+{
+return strcmp(a, b) == 0;
+}
+
+static bool file_chain_loop_check(GHashTable *filenames, const char *filename,
+  const char *fmt) {
+BlockDriverState *bs;
+BlockDriver *drv;
+char fbuf[1024];
+int ret;
+Error *local_err = NULL;
+
+while (filename && (filename[0] != '\0')) {
+if (g_hash_table_lookup_extended(filenames, filename, NULL, NULL)) {
+error_report("Backing file '%s' creates an infinite loop.",
+ filename);
+return true;
+}
+g_hash_table_insert(filenames, (gpointer)filename, NULL);
+
+bs = bdrv_new("image");
+
+if (fmt) {
+drv = bdrv_find_format(fmt);
+if (!drv) {
+error_report("Unknown file format '%s'", fmt);
+bdrv_delete(bs);
+return true;
+}
+} else {
+drv = NULL;
+}
+
+ret = bdrv_open(bs, filename, NULL,
+BDRV_O_CACHE_WB | BDRV_O_NO_BACKING, drv, &local_err);
+if (ret < 0) {
+error_report("Could not open '%s': %s", filename,
+ error_get_pretty(local_err));
+error_free(local_err);
+local_err = NULL;
+return true;
+}
+
+bdrv_get_backing_filename(bs, fbuf, sizeof(fbuf));
+filename = fbuf;
+fmt = NULL;
+
+bdrv_unref(bs);
+}
+
+return false;
+}
+
+/**
+ * Check backing file chain if there is a loop in it.
+ *
+ * @filename: topmost image filename of backing file chain.
+ * @fmt: topmost image format of backing file chain(may be NULL to autodetect).
+ *
+ * Returns: true for backing file loop or error happened, false for no loop.
+ */
+bool bdrv_backing_chain_okay(const char *filename, const char *fmt) {
+GHashTable *filenames;
+
+if (filename == NULL || filename[0] == '\0') {
+return true;
+}
+
+filenames = g_hash_table_new_full(g_str_hash, str_equal_func, NULL, NULL);
+
+if (file_chain_loop_check(filenames, filename, fmt)) {
+goto err;
+}
+
+g_hash_table_destroy(filenames);
+return true;
+
+err:
+g_hash_table_destroy(filenames);
+return false;
+}
+
+/**
+ * Check if there is loop exists in the backing file chain and if there will
+ * be loop occur after backing file chain updated or new image created.
+ *
+ * @filename: the image filename to be created.
+ * @backing_file: topmost image filename of backing file chain.
+ * @backing_fmt: topmost image format (may be NULL to autodetect).
+ *
+ * Returns: true for backing file loop or error happened, false for no loop.
+ */
+bool bdrv_new_chain_okay(const char *filename, const char *backing_file,
+  const char *backing_fmt) {
+GHashTable *filenames;
+
+if (backing_file == NULL || backing_file[0] == '\0') {
+return true;
+}
+
+filenames = g_hash_table_new_full(g_str_hash, str_equal_func, NULL, NULL);
+
+g_hash_table_insert(filenames, (gpointer)filename, NULL);
+
+if (file_chain_loop_check(filenames, backing_file, backing_fmt)) {
+goto err;
+}
+
+g_hash_table_destroy(filenames);
+return true;
+
+err:
+g_hash_table_destroy(filenames);
+return false;
+}
+
 void bdrv_img_create(const char *filename, const char *fmt,
  const char *base_filename, const char *base_fmt,
  char *options, uint64_t img_size, int flags,
diff --git a/include/block/block.h b/include/block/block.h
index 3560deb..0945c09 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -378,6 +378,10 @@ int bdrv_save_vmstate(BlockDriverState *bs, const uint8_t 
*buf,
 int bdrv_load_vmstate(BlockDriverState *bs, uint8_t *buf,
   int64_t pos, int size);
 
+bool bdrv_backing_chain_okay(const char *filename, const char *fmt);
+bool bdrv_new_chain_okay(const char *filename, const char *backing_file,
+const char *backing_fmt);
+
 void bdrv_img_create(const char *file

Re: [Qemu-devel] [PATCH] RFC: powerpc: add PVR compatibility check

[Paul Mackerras]

On Tue, Nov 05, 2013 at 05:16:33PM +0100, Andreas Färber wrote:
> Am 05.11.2013 07:05, schrieb Alexander Graf:
> > 
> > 
> > Am 05.11.2013 um 05:00 schrieb Paul Mackerras :
> > 
> >> On Mon, Nov 04, 2013 at 10:05:58AM +0100, Alexander Graf wrote:
> >>>
> >>> Yeah, we really need to check that guest vpcu == host vcpu for HV KVM.
> >>
> >> In general I agree, but the one difficulty I see is that a check for
> >> exact equality will interact badly with qemu's habit of picking a
> >> specific processor version when the user specifies something general
> >> like "POWER7".  So if the user does -cpu POWER7 on a machine with
> >> (for example) a POWER7 v2.1 processor, but qemu arbitrarily picks the
> >> PVR for POWER7 v2.3, then it will fail, which will be completely
> >> puzzling to the user -- "I asked for POWER7, and it is a POWER7,
> >> what's the problem??".
> >>
> >> Maybe if the user asks for a non-specific processor type, and the
> >> host's PVR matches the request, then qemu should take the host's PVR
> >> rather than just picking some arbitrary processor version.
> > 
> > Yup.
> 
> But then it's no longer generally reproducible: "POWER7" won't be
> "POWER7" on another machine.

There aren't any observable differences between POWER7 versions that
have been sold to customers, as far as I have been able to ascertain
(other than the PVR value, of course).  So this whole business of
carefully distinguishing between POWER7 v2.2 and POWER7 v2.3 is
largely a waste of time as far as I can see.

I admit that in the past we (IBM) did a silly thing in releasing the
POWER5+ v3.0 chip with some architecturally new features (64k pages
and some other MMU changes).  That was a mistake and I don't think
we'll do it again.

I think the default assumption should be that versions of a given IBM
POWER chip (identified by the upper 16 bits of the PVR) are
architecturally identical, and behaviourally identical at the level
at which QEMU models the chip.  Differences between chips would
normally be limited to bug fixes and performance improvements.  Then
we just need a way to cope with POWER5+ v3.0.

> One thing I original did iirc was to hide the aliases from QMP. You can
> always do stupid things on the command line and then we can blame you,
> but if libvirt and upper layers don't offer "POWER7" to the end user
> then we don't need to worry about the average user misinterpreting its
> semantics.

Given that the only difference between POWER7 v2.2 and POWER7 v2.3
(say) will be which set of host systems you get an error on, there
doesn't seem to me to be a lot of point.

Paul.

Re: [Qemu-devel] [PATCH RFC 03/10] qapi script: check correctness of discriminator values in union

[Wenchao Xia]

于 2013/11/5 21:25, Eric Blake 写道:

On 11/04/2013 05:37 PM, Wenchao Xia wrote:

It will check whether the values specfied are wrotten correctly when


s/specfied/specified/
s/wrotten/written/


discriminator is a pre-defined enum type, which help check whether the
schema is in good form.

It is allowed that, not every value in enum is used, so do not check


s/that,/that/


that case.


Why do you allow partial coverage?  That feels like an accident waiting
to happen.  Does the user get a sane error message if they request an
enum value that wasn't mapped to a union branch?  I think it would be
wiser to mandate that if the discriminator is an enum, then the union
must cover all values of the enum.


  abort() will be called in qapi-visit.c, it is OK for output visitor,
but bad for input visitor since user input may trigger it. I think
change abort() to error_set() could solve the problem, then we allow
map part of enum value.


+
+# Return the descriminator enum define, if discriminator is specified in


s/descriminator/discriminator/


+# @expr and it is a pre-defined enum type
+def descriminator_find_enum_define(expr):


s/descriminator/discriminator/ - and fix all callers


+discriminator = expr.get('discriminator')
+base = expr.get('base')
+
+# Only support discriminator when base present
+if not (discriminator and base):
+return None
+
+base_fields = find_base_fields(base)
+
+if not base_fields:
+sys.stderr.write("Base '%s' is not a valid type\n"
+ % base)
+sys.exit(1)
+
+descriminator_type = base_fields.get(discriminator)


s/descriminator/discriminator/

[Qemu-devel] [PATCH for-1.7 2/2] tests: fix memleak in error path test for input visitor

[Wenchao Xia]

Signed-off-by: Wenchao Xia 
Reviewed-by: Eric Blake 
Cc: qemu-sta...@nongnu.org
---
 tests/test-qmp-input-visitor.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tests/test-qmp-input-visitor.c b/tests/test-qmp-input-visitor.c
index 0beb8fb..1e1c6fa 100644
--- a/tests/test-qmp-input-visitor.c
+++ b/tests/test-qmp-input-visitor.c
@@ -604,6 +604,7 @@ static void test_visitor_in_errors(TestInputVisitorData 
*data,
 g_assert(error_is_set(&errp));
 g_assert(p->string == NULL);
 
+error_free(errp);
 g_free(p->string);
 g_free(p);
 }
-- 
1.7.1

[Qemu-devel] [PATCH for-1.7 1/2] qapi: fix memleak by adding implict struct functions in dealloc visitor

[Wenchao Xia]

Otherwise member "base" is leaked in a qapi_free_STRUCTURE() call.

Signed-off-by: Wenchao Xia 
Reviewed-by: Eric Blake 
Cc: qemu-sta...@nongnu.org
---
 qapi/qapi-dealloc-visitor.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/qapi/qapi-dealloc-visitor.c b/qapi/qapi-dealloc-visitor.c
index 1334de3..dc53545 100644
--- a/qapi/qapi-dealloc-visitor.c
+++ b/qapi/qapi-dealloc-visitor.c
@@ -76,6 +76,24 @@ static void qapi_dealloc_end_struct(Visitor *v, Error **errp)
 }
 }
 
+static void qapi_dealloc_start_implicit_struct(Visitor *v,
+   void **obj,
+   size_t size,
+   Error **errp)
+{
+QapiDeallocVisitor *qov = to_qov(v);
+qapi_dealloc_push(qov, obj);
+}
+
+static void qapi_dealloc_end_implicit_struct(Visitor *v, Error **errp)
+{
+QapiDeallocVisitor *qov = to_qov(v);
+void **obj = qapi_dealloc_pop(qov);
+if (obj) {
+g_free(*obj);
+}
+}
+
 static void qapi_dealloc_start_list(Visitor *v, const char *name, Error **errp)
 {
 QapiDeallocVisitor *qov = to_qov(v);
@@ -162,6 +180,8 @@ QapiDeallocVisitor *qapi_dealloc_visitor_new(void)
 
 v->visitor.start_struct = qapi_dealloc_start_struct;
 v->visitor.end_struct = qapi_dealloc_end_struct;
+v->visitor.start_implicit_struct = qapi_dealloc_start_implicit_struct;
+v->visitor.end_implicit_struct = qapi_dealloc_end_implicit_struct;
 v->visitor.start_list = qapi_dealloc_start_list;
 v->visitor.next_list = qapi_dealloc_next_list;
 v->visitor.end_list = qapi_dealloc_end_list;
-- 
1.7.1

[Qemu-devel] [PATCH for-1.7 0/2] fix qapi mem leaks

[Wenchao Xia]

The bugfix patches are picked up from RFC series:
http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg00363.html

Wenchao Xia (2):
  qapi: fix memleak by adding implict struct functions in dealloc visitor
  tests: fix memleak in error path test for input visitor

 qapi/qapi-dealloc-visitor.c|   20 
 tests/test-qmp-input-visitor.c |1 +
 2 files changed, 21 insertions(+), 0 deletions(-)

Re: [Qemu-devel] [PATCH RFC 09/10] tests: fix memleak in error path test for input visitor

[Wenchao Xia]

于 2013/11/5 21:20, Eric Blake 写道:

On 11/04/2013 05:37 PM, Wenchao Xia wrote:

Signed-off-by: Wenchao Xia 
Cc: qemu-sta...@nongnu.org
---
  tests/test-qmp-input-visitor.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)


Reviewed-by: Eric Blake 

You should repost your mem-leak patches for qemu-stable as an
independent thread marked "for-1.7", without RFC, to ensure that they
are applied in a timely manner without waiting for the rest of this series.



  OK, will resend.



diff --git a/tests/test-qmp-input-visitor.c b/tests/test-qmp-input-visitor.c
index 0beb8fb..1e1c6fa 100644
--- a/tests/test-qmp-input-visitor.c
+++ b/tests/test-qmp-input-visitor.c
@@ -604,6 +604,7 @@ static void test_visitor_in_errors(TestInputVisitorData 
*data,
  g_assert(error_is_set(&errp));
  g_assert(p->string == NULL);

+error_free(errp);
  g_free(p->string);
  g_free(p);
  }

Re: [Qemu-devel] About the IO-mirroring functionality inside the qemu

[Andrew Cathrow]

http://wiki.qemu.org/Features/BlockJob

- Original Message -
> From: "Yaodong Yang" 
> To: qemu-devel@nongnu.org, qemu-disc...@nongnu.org
> Cc: "Yaodong Yang" 
> Sent: Tuesday, November 5, 2013 9:07:27 PM
> Subject: [Qemu-devel] About the IO-mirroring functionality inside the qemu
> 
> Hi all,
> 
> Does the Qemu have the storage migration tool, like the io-mirroring
> inside the vmware? io-mirroring means for all the ioes, they are
> send to both source and destination at the same time.
> 
> Thanks!
> 

Re: [Qemu-devel] About the IO-mirroring functionality inside the qemu

[Zhanghaoyu (A)]

>Hi all,
>
>Does the Qemu have the storage migration tool, like the io-mirroring inside 
>the vmware? io-mirroring means for all the ioes, they are send to both source 
>and destination at the same time.
drive_mirror maybe your choice.

Thanks,
Zhang Haoyu
>
>Thanks!

[Qemu-devel] About the IO-mirroring functionality inside the qemu

[Yaodong Yang]

Hi all,

Does the Qemu have the storage migration tool, like the io-mirroring inside the 
vmware? io-mirroring means for all the ioes, they are send to both source and 
destination at the same time.

Thanks!

[Qemu-devel] i386: pc: align gpa<->hpa on 1GB boundary (v3)

[Marcelo Tosatti]

v2: condition enablement of new mapping to new machine types (Paolo)
v3: fix changelog

-


Align guest physical address and host physical address
beyond guest 4GB on a 1GB boundary.

Otherwise 1GB TLBs cannot be cached for the range.

Signed-off-by: Marcelo Tosatti 

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0c313fe..534e067 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1116,7 +1116,7 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory,
 {
 int linux_boot, i;
 MemoryRegion *ram, *option_rom_mr;
-MemoryRegion *ram_below_4g, *ram_above_4g;
+MemoryRegion *ram_below_4g, *ram_above_4g, *ram_above_4g_piecetwo;
 FWCfgState *fw_cfg;
 
 linux_boot = (kernel_filename != NULL);
@@ -1136,10 +1136,46 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory,
 memory_region_add_subregion(system_memory, 0, ram_below_4g);
 if (above_4g_mem_size > 0) {
 ram_above_4g = g_malloc(sizeof(*ram_above_4g));
-memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g", ram,
- below_4g_mem_size, above_4g_mem_size);
-memory_region_add_subregion(system_memory, 0x1ULL,
+
+/*
+ *
+ * If 1GB hugepages are used to back guest RAM, map guest address
+ * space in the range [ramsize,ramsize+holesize] to the ram block
+ * range [holestart, 4GB]
+ *
+ *  0  h 4G [ramsize,ramsize+holesize]
+ *
+ * guest-addr-space [  ] [  ][xxx]
+ */--/
+ * contiguous-ram-block [  ][xxx][ ]
+ *
+ * So that memory beyond 4GB is aligned on a 1GB boundary,
+ * at the host physical address space.
+ *
+ */
+if (guest_info->gb_align) {
+unsigned long holesize = 0x1ULL - below_4g_mem_size;
+
+memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g", ram,
+0x1ULL,
+above_4g_mem_size - holesize);
+memory_region_add_subregion(system_memory, 0x1ULL,
 ram_above_4g);
+
+ram_above_4g_piecetwo = g_malloc(sizeof(*ram_above_4g_piecetwo));
+memory_region_init_alias(ram_above_4g_piecetwo, NULL,
+ "ram-above-4g-piecetwo", ram,
+ 0x1ULL - holesize, holesize);
+memory_region_add_subregion(system_memory,
+0x1ULL +
+above_4g_mem_size - holesize,
+ram_above_4g_piecetwo);
+} else {
+memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g", ram,
+below_4g_mem_size, above_4g_mem_size);
+memory_region_add_subregion(system_memory, 0x1ULL,
+ram_above_4g);
+}
 }
 
 
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index c6042c7..305a4cd 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -59,6 +59,7 @@ static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 
 static bool has_pvpanic;
 static bool has_pci_info = true;
+static bool gb_align = true;
 
 /* PC hardware initialisation */
 static void pc_init1(QEMUMachineInitArgs *args,
@@ -124,6 +125,7 @@ static void pc_init1(QEMUMachineInitArgs *args,
 guest_info = pc_guest_info_init(below_4g_mem_size, above_4g_mem_size);
 guest_info->has_pci_info = has_pci_info;
 guest_info->isapc_ram_fw = !pci_enabled;
+guest_info->gb_align = gb_align;
 
 /* allocate ram and load rom/bios */
 if (!xen_enabled()) {
@@ -236,8 +238,14 @@ static void pc_init_pci(QEMUMachineInitArgs *args)
 pc_init1(args, 1, 1);
 }
 
+static void pc_compat_1_7(QEMUMachineInitArgs *args)
+{
+gb_align = false;
+}
+
 static void pc_compat_1_6(QEMUMachineInitArgs *args)
 {
+pc_compat_1_7(args);
 has_pci_info = false;
 rom_file_in_ram = false;
 }
@@ -269,6 +277,12 @@ static void pc_compat_1_2(QEMUMachineInitArgs *args)
 disable_kvm_pv_eoi();
 }
 
+static void pc_init_pci_1_7(QEMUMachineInitArgs *args)
+{
+pc_compat_1_7(args);
+pc_init_pci(args);
+}
+
 static void pc_init_pci_1_6(QEMUMachineInitArgs *args)
 {
 pc_compat_1_6(args);
@@ -339,13 +353,21 @@ static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
 .desc = "Standard PC (i440FX + PIIX, 1996)", \
 .hot_add_cpu = pc_hot_add_cpu
 
+#define PC_I440FX_1_8_MACHINE_OPTIONS PC_I440FX_MACHINE_OPTIONS
+static QEMUMachine pc_i440fx_machine_v1_8 = {
+PC_I440FX_1_8_MACHINE_OPTIONS,
+.name = "pc-i440fx-1.8",
+.alias = "pc",
+.init = pc_init_pci,
+.is_default = 1,
+};
+
 #define PC_I440FX_1_7_MACHINE_OPTIONS PC_I440FX_MACHINE_OPTIONS
 static QEMUMachine pc_i440fx_machine_v1_7 = {
 

Re: [Qemu-devel] [PATCH] migration: avoid starting a new migration task while the previous one still exist

[Zhanghaoyu (A)]

 Avoid starting a new migration task while the previous one still
>>> exist.
>>>
>>> Can you explain how to reproduce the problem?
>>>
>> When network disconnection between source and destination happened, 
>> the migration thread stuck at below stack,
>> Then I cancel the migration task, the migration state in qemu will be set to 
>> MIG_STATE_CANCELLED, so the migration job in libvirt quits.
>> Then I perform migration again, at this time, the network reconnected 
>> successfully, since the TCP timeout retransmission, above stack will not 
>> return immediately, so two migration tasks exist at the same time.
>> And still worse, source qemu will crash, because of accessing the NULL 
>> pointer in qemu_bh_schedule(s->cleanup_bh); statement in latter migration 
>> task, since the "s->cleanup_bh" had been deleted by previous migration task.
>
>Thanks for explaining.  CANCELLING looks like a useful addition.
>
>Why do you need both CANCELLING and COMPLETING?  The COMPLETED state should be 
>set only after all I/O is done.
>
There is a period of time from the timing of setting COMPLETED state to that of 
migration task exits,
so it's problematic in COMPLETED->CANCELLED transition, but if applying your 
below proposal, the problem gone.
do {
old_state = s->state;
if (old_state != MIG_STATE_SETUP && old_state != MIG_STATE_ACTIVE) {
break;
}
migrate_set_state(s, old_state, MIG_STATE_CANCELLED);
} while (s->state != MIG_STATE_CANCELLED);

>I agree with Eric that the CANCELLING state should not be exposed via QMP.
>"info migrate" and "query-migrate" can keep showing "active" for maximum 
>backwards compatibility.
>
>More comments below.
>
>
>> -if (s->state != MIG_STATE_COMPLETED) {
>> +if (s->state != MIG_STATE_COMPLETING) {
>>  qemu_savevm_state_cancel();
>> +if (s->state == MIG_STATE_CANCELLING) {
>> +migrate_set_state(s, MIG_STATE_CANCELLING, 
>> MIG_STATE_CANCELLED); 
>> +}
>
>I think you can remove the "if" and unconditionally call migrate_set_state.

Do you mean to remove the "if (s->state == MIG_STATE_CANCELLING)" ?
The s->state probably is MIG_STATE_ERROR here, is it okay to unconditionally 
call migrate_set_state?

Thanks,
Zhang Haoyu

>
>> +}else {
>> +migrate_set_state(s, MIG_STATE_COMPLETING, 
>> + MIG_STATE_COMPLETED);
>>  }
>>  
>>  notifier_list_notify(&migration_state_notifiers, s);  }
>>  
>> -static void migrate_set_state(MigrationState *s, int old_state, int 
>> new_state) -{
>> -if (atomic_cmpxchg(&s->state, old_state, new_state) == new_state) {
>> -trace_migrate_set_state(new_state);
>> -}
>> -}
>> -
>>  void migrate_fd_error(MigrationState *s)  {
>>  DPRINTF("setting error state\n"); @@ -328,7 +337,7 @@ static void 
>> migrate_fd_cancel(MigrationState *s)  {
>>  DPRINTF("cancelling migration\n");
>>  
>> -migrate_set_state(s, s->state, MIG_STATE_CANCELLED);
>> +migrate_set_state(s, s->state, MIG_STATE_CANCELLING);
>
>Here probably we want something like
>
>do {
>old_state = s->state;
>if (old_state != MIG_STATE_SETUP && old_state != MIG_STATE_ACTIVE) {
>break;
>}
>migrate_set_state(s, old_state, MIG_STATE_CANCELLING);
>} while (s->state != MIG_STATE_CANCELLING);
>
>to avoid a bogus COMPLETED->CANCELLED transition.  Please separate the patch 
>in two parts:
>
>(1) the first uses the above code, with CANCELLED instead of CANCELLING
>
>(2) the second, similar to the one you have posted, introduces the new 
>CANCELLING state
>
>Thanks,
>
>Paolo

[Qemu-devel] i386: pc: align gpa<->hpa on 1GB boundary (v2)

[Marcelo Tosatti]

Align guest physical address and host physical address
beyond guest 4GB on a 1GB boundary, in case hugetlbfs is used.

Otherwise 1GB TLBs cannot be cached for the range.

Signed-off-by: Marcelo Tosatti 

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0c313fe..534e067 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1116,7 +1116,7 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory,
 {
 int linux_boot, i;
 MemoryRegion *ram, *option_rom_mr;
-MemoryRegion *ram_below_4g, *ram_above_4g;
+MemoryRegion *ram_below_4g, *ram_above_4g, *ram_above_4g_piecetwo;
 FWCfgState *fw_cfg;
 
 linux_boot = (kernel_filename != NULL);
@@ -1136,10 +1136,46 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory,
 memory_region_add_subregion(system_memory, 0, ram_below_4g);
 if (above_4g_mem_size > 0) {
 ram_above_4g = g_malloc(sizeof(*ram_above_4g));
-memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g", ram,
- below_4g_mem_size, above_4g_mem_size);
-memory_region_add_subregion(system_memory, 0x1ULL,
+
+/*
+ *
+ * If 1GB hugepages are used to back guest RAM, map guest address
+ * space in the range [ramsize,ramsize+holesize] to the ram block
+ * range [holestart, 4GB]
+ *
+ *  0  h 4G [ramsize,ramsize+holesize]
+ *
+ * guest-addr-space [  ] [  ][xxx]
+ */--/
+ * contiguous-ram-block [  ][xxx][ ]
+ *
+ * So that memory beyond 4GB is aligned on a 1GB boundary,
+ * at the host physical address space.
+ *
+ */
+if (guest_info->gb_align) {
+unsigned long holesize = 0x1ULL - below_4g_mem_size;
+
+memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g", ram,
+0x1ULL,
+above_4g_mem_size - holesize);
+memory_region_add_subregion(system_memory, 0x1ULL,
 ram_above_4g);
+
+ram_above_4g_piecetwo = g_malloc(sizeof(*ram_above_4g_piecetwo));
+memory_region_init_alias(ram_above_4g_piecetwo, NULL,
+ "ram-above-4g-piecetwo", ram,
+ 0x1ULL - holesize, holesize);
+memory_region_add_subregion(system_memory,
+0x1ULL +
+above_4g_mem_size - holesize,
+ram_above_4g_piecetwo);
+} else {
+memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g", ram,
+below_4g_mem_size, above_4g_mem_size);
+memory_region_add_subregion(system_memory, 0x1ULL,
+ram_above_4g);
+}
 }
 
 
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index c6042c7..305a4cd 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -59,6 +59,7 @@ static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 
 static bool has_pvpanic;
 static bool has_pci_info = true;
+static bool gb_align = true;
 
 /* PC hardware initialisation */
 static void pc_init1(QEMUMachineInitArgs *args,
@@ -124,6 +125,7 @@ static void pc_init1(QEMUMachineInitArgs *args,
 guest_info = pc_guest_info_init(below_4g_mem_size, above_4g_mem_size);
 guest_info->has_pci_info = has_pci_info;
 guest_info->isapc_ram_fw = !pci_enabled;
+guest_info->gb_align = gb_align;
 
 /* allocate ram and load rom/bios */
 if (!xen_enabled()) {
@@ -236,8 +238,14 @@ static void pc_init_pci(QEMUMachineInitArgs *args)
 pc_init1(args, 1, 1);
 }
 
+static void pc_compat_1_7(QEMUMachineInitArgs *args)
+{
+gb_align = false;
+}
+
 static void pc_compat_1_6(QEMUMachineInitArgs *args)
 {
+pc_compat_1_7(args);
 has_pci_info = false;
 rom_file_in_ram = false;
 }
@@ -269,6 +277,12 @@ static void pc_compat_1_2(QEMUMachineInitArgs *args)
 disable_kvm_pv_eoi();
 }
 
+static void pc_init_pci_1_7(QEMUMachineInitArgs *args)
+{
+pc_compat_1_7(args);
+pc_init_pci(args);
+}
+
 static void pc_init_pci_1_6(QEMUMachineInitArgs *args)
 {
 pc_compat_1_6(args);
@@ -339,13 +353,21 @@ static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
 .desc = "Standard PC (i440FX + PIIX, 1996)", \
 .hot_add_cpu = pc_hot_add_cpu
 
+#define PC_I440FX_1_8_MACHINE_OPTIONS PC_I440FX_MACHINE_OPTIONS
+static QEMUMachine pc_i440fx_machine_v1_8 = {
+PC_I440FX_1_8_MACHINE_OPTIONS,
+.name = "pc-i440fx-1.8",
+.alias = "pc",
+.init = pc_init_pci,
+.is_default = 1,
+};
+
 #define PC_I440FX_1_7_MACHINE_OPTIONS PC_I440FX_MACHINE_OPTIONS
 static QEMUMachine pc_i440fx_machine_v1_7 = {
 PC_I440FX_1_7_MACHINE_OPTIONS,
 .name = "pc-i440fx-1.7",
 

Re: [Qemu-devel] Multi-head support RFC

[Dave Airlie]

On Wed, Nov 6, 2013 at 6:42 AM, John Baboval  wrote:
> Hello,
>
> I am currently the device model maintainer for XenClient Enterprise. As you
> may or may not know, we maintain a patch queue on top of QEMU (currently
> 1.3) that adds functionality needed to support XCE features.
>
> One of the major things we add is robust multi-head support. This includes
> DDC emulation for EDID data, variable VRAM size, monitor hot-plug support,
> simulated VSYNC, and guest controlled display orientation. This includes
> both the necessary interfaces between the hw and ui, and a new emulated
> adapter (with drivers) that exercises the interfaces.

I don't think we'd want to lump all these things together though,

I've started looking at doing multi-head support for a new virtio-gpu,
and I've gotten basic multi-head working with SDL2.0 with cursor
support.

It currently just adds multiple DisplaySurfaces to the QemuConsole,
now Gerd said he thought I should be using multiple QemuConsoles but I
really didn't think this was a good idea, and I still think multiple
surfaces makes more sense wrt how best to interact with this.

Why do you need to emulate DDC btw? is this just to fool the guest
vesa code etc?

Dave.

Re: [Qemu-devel] [PATCH v3] ppc: introduce CPUPPCState::cpu_dt_id

[Scott Wood]

On Tue, 2013-11-05 at 07:00 +0100, Alexander Graf wrote:
> 
> Am 05.11.2013 um 02:48 schrieb Scott Wood :
> 
> > On Tue, 2013-11-05 at 12:26 +1100, Alexey Kardashevskiy wrote:
> >> On 11/05/2013 06:42 AM, Scott Wood wrote:
> >>> On Mon, 2013-11-04 at 10:41 +0100, Alexander Graf wrote:
>  What we really have are 3 semantically separate entities:
>  
>   * QEMU internal cpu id
>   * KVM internal cpu id
>   * DT exposed cpu id
>  
>  As you have noted, it's a good idea to keep the QEMU internal cpu id
>  linear, thus completely separate from the others. The DT exposed cpu id
>  should be 100% local to hw/ppc/spapr*.c. I don't think any code outside
>  of the DT generation and anything that accesses the "Virtual Processor
>  Number" in sPAPR needs to care about the DT cpu id. All that code is
>  100% KVM agnostic.
> >>> 
> >>> This patch isn't just for sPAPR...  On e500 the DT cpu id is supposed to
> >>> match the MPIC cpu id.
> >> 
> >> 
> >> At least is my patch correct for e500?
> > 
> > I think so.
> > 
> >> I do not really know what is the difference between e500 and spapr in this 
> >> part.
> > 
> > e500 does not have sPAPR, and if the DT ID is "100% local to
> > hw/ppc/spapr*.c" then the MPIC code will have a problem.
> > 
> > Currently we don't support smt on e500 in QEMU, but e6500 (an
> > e500-derivative) does have smt, so it could happen in the future.
> 
> Sure, at that point we add logic that syncs the kvm and dt ids to whatever 
> the kernel expects from the e500 machine file.
> 
> The current logic that says "every Nth vcpu id is a core, the ones in
> between are threads" is fairly implementation specific to the spapr hv
> code, no?

It's the same on e6500, though I agree that in theory it should not be
generic code specifying the scheme.  My point relates to the consumer of
this information -- "device tree CPU ID" is a concept that makes sense
outside of sPAPR.

Note that the connection between the interrupt controller and the CPU
reg is an ePAPR requirement, not just a coincidence, or something we
only do on MPIC.  PIR is also supposed to match the device tree CPU ID
-- especially under KVM, where PIR is not modifiable by the guest, in
the absence of a device tree binding specifically for PIR which we do
not have.

-Scott

[Qemu-devel] [PATCH v3] Fix pc migration from qemu <= 1.5

[Cole Robinson]

The following commit introduced a migration incompatibility:

commit 568f0690fd9aa4d39d84b04c1a5dbb53a915c3fe
Author: David Gibson 
Date:   Thu Jun 6 18:48:49 2013 +1000

pci: Replace pci_find_domain() with more general pci_root_bus_path()

The issue is that i440fx savevm idstr went from :00:00.0/I440FX to
:00.0/I440FX. Unfortunately we are stuck with the breakage for
1.6 machine types.

Add a compat property to maintain the busted idstr for the 1.6 machine
types, but revert to the old style format for 1.7+, and <= 1.5.

Tested with migration from qemu 1.5, qemu 1.6, and qemu.git.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Cole Robinson 
---

v3:
Don't regress -M pc-q35*

 hw/pci-host/piix.c|  9 -
 hw/pci-host/q35.c | 10 --
 include/hw/i386/pc.h  | 16 
 include/hw/pci-host/q35.h |  1 +
 4 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index bad3953..edc974e 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -48,6 +48,7 @@ typedef struct I440FXState {
 PCIHostState parent_obj;
 PcPciInfo pci_info;
 uint64_t pci_hole64_size;
+uint32_t short_root_bus;
 } I440FXState;
 
 #define PIIX_NUM_PIC_IRQS   16  /* i8259 * 2 */
@@ -720,13 +721,19 @@ static const TypeInfo i440fx_info = {
 static const char *i440fx_pcihost_root_bus_path(PCIHostState *host_bridge,
 PCIBus *rootbus)
 {
+I440FXState *s = I440FX_PCI_HOST_BRIDGE(host_bridge);
+
 /* For backwards compat with old device paths */
-return "";
+if (s->short_root_bus) {
+return "";
+}
+return ":00";
 }
 
 static Property i440fx_props[] = {
 DEFINE_PROP_SIZE(PCI_HOST_PROP_PCI_HOLE64_SIZE, I440FXState,
  pci_hole64_size, DEFAULT_PCI_HOLE64_SIZE),
+DEFINE_PROP_UINT32("short_root_bus", I440FXState, short_root_bus, 0),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index b8feed1..c043998 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -61,8 +61,13 @@ static void q35_host_realize(DeviceState *dev, Error **errp)
 static const char *q35_host_root_bus_path(PCIHostState *host_bridge,
   PCIBus *rootbus)
 {
-/* For backwards compat with old device paths */
-return "";
+Q35PCIHost *s = Q35_HOST_DEVICE(host_bridge);
+
+ /* For backwards compat with old device paths */
+if (s->mch.short_root_bus) {
+return "";
+}
+return ":00";
 }
 
 static void q35_host_get_pci_hole_start(Object *obj, Visitor *v,
@@ -124,6 +129,7 @@ static Property mch_props[] = {
 MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT),
 DEFINE_PROP_SIZE(PCI_HOST_PROP_PCI_HOLE64_SIZE, Q35PCIHost,
  mch.pci_hole64_size, DEFAULT_PCI_HOLE64_SIZE),
+DEFINE_PROP_UINT32("short_root_bus", Q35PCIHost, mch.short_root_bus, 0),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 03cc0ba..57e8d16 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -260,6 +260,14 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 .driver   = "qemu32-" TYPE_X86_CPU,\
 .property = "model",\
 .value= stringify(3),\
+},{\
+.driver   = "i440FX-pcihost",\
+.property = "short_root_bus",\
+.value= stringify(1),\
+},{\
+.driver   = "q35-pcihost",\
+.property = "short_root_bus",\
+.value= stringify(1),\
 }
 
 #define PC_COMPAT_1_5 \
@@ -296,6 +304,14 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 .driver = TYPE_X86_CPU,\
 .property = "pmu",\
 .value = "on",\
+},{\
+.driver   = "i440FX-pcihost",\
+.property = "short_root_bus",\
+.value= stringify(0),\
+},{\
+.driver   = "q35-pcihost",\
+.property = "short_root_bus",\
+.value= stringify(0),\
 }
 
 #define PC_COMPAT_1_4 \
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index aee91aa..309065f 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -61,6 +61,7 @@ typedef struct MCHPCIState {
 ram_addr_t above_4g_mem_size;
 uint64_t pci_hole64_size;
 PcGuestInfo *guest_info;
+uint32_t short_root_bus;
 } MCHPCIState;
 
 typedef struct Q35PCIHost {
-- 
1.8.4.2

Re: [Qemu-devel] [PATCH v2] pci-assign: Fix error_report of pci-stub message

[Cole Robinson]

cc-ing qemu-trivial since this hasn't been picked up yet AFAICT.

- Cole

On 10/11/2013 11:52 AM, Cole Robinson wrote:
> Using multiple calls to error_report here means every line is
> prefaced with the (potentially long) pci-assign command line
> arguments.
> 
> Use a single error_printf to preserve the intended formatting.
> Since this code path is always preceded by an error_report call,
> we don't lose the command line reporting.
> 
> Signed-off-by: Cole Robinson 
> ---
> 
> v2: Switch to error_printf
> 
>  hw/i386/kvm/pci-assign.c | 36 
>  1 file changed, 16 insertions(+), 20 deletions(-)
> 
> diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
> index 5618173..f013a1c 100644
> --- a/hw/i386/kvm/pci-assign.c
> +++ b/hw/i386/kvm/pci-assign.c
> @@ -791,26 +791,22 @@ static void assign_failed_examine(AssignedDevice *dev)
>  goto fail;
>  }
>  
> -error_report("*** The driver '%s' is occupying your device "
> - "%04x:%02x:%02x.%x.",
> - ns, dev->host.domain, dev->host.bus, dev->host.slot,
> - dev->host.function);
> -error_report("***");
> -error_report("*** You can try the following commands to free it:");
> -error_report("***");
> -error_report("*** $ echo \"%04x %04x\" > /sys/bus/pci/drivers/pci-stub/"
> - "new_id", vendor_id, device_id);
> -error_report("*** $ echo \"%04x:%02x:%02x.%x\" > /sys/bus/pci/drivers/"
> - "%s/unbind",
> - dev->host.domain, dev->host.bus, dev->host.slot,
> - dev->host.function, ns);
> -error_report("*** $ echo \"%04x:%02x:%02x.%x\" > /sys/bus/pci/drivers/"
> - "pci-stub/bind",
> - dev->host.domain, dev->host.bus, dev->host.slot,
> - dev->host.function);
> -error_report("*** $ echo \"%04x %04x\" > /sys/bus/pci/drivers/pci-stub"
> - "/remove_id", vendor_id, device_id);
> -error_report("***");
> +error_printf("*** The driver '%s' is occupying your device "
> +"%04x:%02x:%02x.%x.\n"
> +"***\n"
> +"*** You can try the following commands to free it:\n"
> +"***\n"
> +"*** $ echo \"%04x %04x\" > /sys/bus/pci/drivers/pci-stub/new_id\n"
> +"*** $ echo \"%04x:%02x:%02x.%x\" > /sys/bus/pci/drivers/%s/unbind\n"
> +"*** $ echo \"%04x:%02x:%02x.%x\" > /sys/bus/pci/drivers/"
> +"pci-stub/bind\n"
> +"*** $ echo \"%04x %04x\" > 
> /sys/bus/pci/drivers/pci-stub/remove_id\n"
> +"***",
> +ns, dev->host.domain, dev->host.bus, dev->host.slot,
> +dev->host.function, vendor_id, device_id,
> +dev->host.domain, dev->host.bus, dev->host.slot, dev->host.function,
> +ns, dev->host.domain, dev->host.bus, dev->host.slot,
> +dev->host.function, vendor_id, device_id);
>  
>  return;
>  
> 

Re: [Qemu-devel] [PATCH v2] Fix pc migration from qemu <= 1.5

[Cole Robinson]

On 11/04/2013 11:19 PM, Alex Williamson wrote:
> On Tue, 2013-10-08 at 15:35 -0400, Cole Robinson wrote:
>> The following commit introduced a migration incompatibility:
>>
>> commit 568f0690fd9aa4d39d84b04c1a5dbb53a915c3fe
>> Author: David Gibson 
>> Date:   Thu Jun 6 18:48:49 2013 +1000
>>
>> pci: Replace pci_find_domain() with more general pci_root_bus_path()
>>
>> The issue is that i440fx savevm idstr went from :00:00.0/I440FX to
>> :00.0/I440FX. Unfortunately we are stuck with the breakage for
>> 1.6 machine types.
>>
>> Add a compat property to maintain the busted idstr for the 1.6 machine
>> types, but revert to the old style format for 1.7+, and <= 1.5.
>>
>> Tested with migration from qemu 1.5, qemu 1.6, and qemu.git.
>>
>> Cc: qemu-sta...@nongnu.org
>> Signed-off-by: Cole Robinson 
>> ---
>>
>> v2:
>> Drop needless 1.7 compat bits
>>
>>  hw/pci-host/piix.c|  9 -
>>  hw/pci-host/q35.c | 10 --
>>  include/hw/i386/pc.h  | 16 
>>  include/hw/pci-host/q35.h |  1 +
>>  4 files changed, 33 insertions(+), 3 deletions(-)
> ...
>> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
>> index 9b2ddc4..79f6934 100644
>> --- a/include/hw/i386/pc.h
>> +++ b/include/hw/i386/pc.h
>> @@ -230,6 +230,14 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
>>  .driver   = "e1000",\
>>  .property = "mitigation",\
>>  .value= "off",\
>> +},{\
>> +.driver   = "i440FX-pcihost",\
>> +.property = "short_root_bus",\
>> +.value= stringify(1),\
>> +},{\
>> +.driver   = "mch",\
>> +.property = "short_root_bus",\
>> +.value= stringify(1),\
> 
> This should be "q35-pcihost" in place of "mch".  Same below.  Otherwise
> a q35 machine just fails with a property not found error.  Thanks,
> 

Thanks, v3 sent now.

- Cole

Re: [Qemu-devel] [PATCH v2] rdma: rename 'x-rdma' => 'rdma'

[Eric Blake]

On 10/26/2013 02:03 PM, mrhi...@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" 
> 
> As far as we can tell, all known bugs have been fixed:
> 
> 1. Parallel RDMA migrations are working
> 2. IPv6 migration is working
> 3. Libvirt patches are ready
> 4. virt-test is working
> 
> Signed-off-by: Michael R. Hines 
> ---
>  docs/rdma.txt|   24 ++--
>  migration-rdma.c |2 +-
>  migration.c  |6 +++---
>  qapi-schema.json |4 ++--
>  4 files changed, 16 insertions(+), 20 deletions(-)

> +++ b/qapi-schema.json
> @@ -615,7 +615,7 @@
>  #  This feature allows us to minimize migration traffic for certain 
> work
>  #  loads, by sending compressed difference of the pages
>  #
> -# @x-rdma-pin-all: Controls whether or not the entire VM memory footprint is
> +# @rdma-pin-all: Controls whether or not the entire VM memory footprint is
>  #  mlock()'d on demand or all at once. Refer to docs/rdma.txt for 
> usage.
>  #  Disabled by default. Experimental: may (or may not) be renamed 
> after
>  #  further testing is complete. (since 1.6)

This text is still out-of-date.  s/1.6/1.7/ (if we are still trying to
get it in 1.7), as well as removing mention of it being experimental.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 00/20] Add an IPMI device to QEMU

[Bret Ketchum]

>> I was pointed at these patches as an example of useful
>> functionality that's out of qemu merely for lack of review
>> resources. I'd like to help.
>>
>> Now that we have code to generate ACPI tables
>> directly in qemu, this series can be rebased on top of
>> that, with no need for new FW CFG entries or bios changes.
>>
>> If you have the time, pls Cc me on patches and I'll try to
>> help shepherd them upstream.
>>
>Ok, thanks.  I will make some time this week to get the patches updated
>to the current git tree.

I've been using an adaptation of these patches which work with 1.6.1.
I've a situation where a VM would like access to the BMC via the usual ISA
IO port interface of the host platform. Does it seem reasonable that this
new isa-ipmi device be enhance to provide a host device passhthrough
function to the actual BMC of the host platform?

I'd also be willing to assist in making this device available in a near
future release.

Bret

Re: [Qemu-devel] Qemu IPMI support

[Bret Ketchum]

   Will do, thanks.


On Tue, Nov 5, 2013 at 7:53 AM, Michael S. Tsirkin  wrote:

> On Tue, Nov 05, 2013 at 07:27:42AM -0600, Bret Ketchum wrote:
> > Gentlemen,
> >
> > Hope this email finds you well and hope you can point me in the right
> > direction. I've a project which requires a VM to see a BMC at an IO Port
> on an
> > ISA bus. I've adapted (rather in the process of) the patches described
> here:
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg04335.html
> >
> > To 1.6.1 but am wondering about the process where a patch on
> qemu-devel
> > finds its way into a release. I'd like to see Corey's patch become
> reality for
> > obvious reasons. How may I facilitate this patch becoming a part of a
> future
> > release?
> >
> > Any insight is appreciated and thanks in advance.
> >
> > Bret
> >
> >
>
> I think it's a good idea to rebase this on top of latest bits.
>
> In particular, there's no need to add FW CFG interfaces
> anymore, now that we generate the ACPI tables in QEMU.
>
> Pls Cc me on the series when you post them,
> I'll try to help review.
>
> --
> MST
>

Re: [Qemu-devel] [Bug 1246012] Re: QEMU removes postgresql

[Serge Hallyn]

Quoting Joe Doe (joe.doe.launch...@mailinator.com):
> You guys speak in technical terms that I can hardly understand.
> postgresql-9.2 is not the default version for Ubuntu(I believe 9.1 is), but 
> can easily be installed by using the steps here -> 
> http://www.postgresql.org/download/linux/ubuntu/ .
> 
> Anyways, the issue seems to be here:
> 
> >sudo apt-get install kvm virt-manager

I installed the postgresql-9.2 packages from the url you
listed, and installed qemu-kvm, kvm, and virt-manager,
but still was not able to reproduce this.

Please show the results of

cat /etc/apt/sources.list
for f in /etc/apt/sources.list.d/*; do
echo $f
cat $f
done
apt-cache show libvirt-bin
apt-cache show logrotate
apt-cache show qemu-kvm
apt-cache show kvm
apt-cache show virt-manager
apt-cache show postgresql-9.2
apt-cache show postgresql-common
apt-cache show postgresql-plperl-9.2

(then re-mark the status of the bug as New)

> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Note, selecting 'qemu-system-x86' instead of 'kvm'
> qemu-system-x86 is already the newest version.
> The following extra packages will be installed:
>   libvirt-bin logrotate
> Suggested packages:
>   radvd python-guestfs python-spice-client-gtk
> The following packages will be REMOVED:
>   postgresql-9.2 postgresql-common postgresql-plperl-9.2
> The following NEW packages will be installed:
>   libvirt-bin logrotate virt-manager
> 0 upgraded, 3 newly installed, 3 to remove and 0 not upgraded.
> Need to get 0 B/3,570 kB of archives.
> After this operation, 5,177 kB disk space will be freed.
> Do you want to continue [Y/n]? Y
> (Reading database ... 210251 files and directories currently installed.)
> Removing postgresql-plperl-9.2 ...
> Removing postgresql-9.2 ...
>  * Stopping PostgreSQL 9.2 database server [ OK ]
> Removing postgresql-common ...
> Removing 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by 
> postgresql-common'
> Processing triggers for ureadahead ...
> Processing triggers for man-db ...
> Selecting previously unselected package logrotate.
> (Reading database ... 209976 files and directories currently installed.)
> Unpacking logrotate (from .../logrotate_3.8.3-3ubuntu2_amd64.deb) ...
> Selecting previously unselected package libvirt-bin.
> Unpacking libvirt-bin (from .../libvirt-bin_1.1.1-0ubuntu8_amd64.deb) ...
> Selecting previously unselected package virt-manager.
> Unpacking virt-manager (from .../virt-manager_0.9.5-1ubuntu1_all.deb) ...
> Processing triggers for man-db ...
> Processing triggers for ureadahead ...
> Processing triggers for gconf2 ...
> Processing triggers for bamfdaemon ...
> Rebuilding /usr/share/applications/bamf-2.index...
> Processing triggers for desktop-file-utils ...
> Processing triggers for gnome-menus ...
> Processing triggers for mime-support ...
> Processing triggers for hicolor-icon-theme ...
> Setting up logrotate (3.8.3-3ubuntu2) ...
> Setting up libvirt-bin (1.1.1-0ubuntu8) ...
> libvirt-bin start/running, process 24248
> Setting up libvirt-bin dnsmasq configuration.
> Setting up virt-manager (0.9.5-1ubuntu1) ...
> 
> As you can see from the logs, installing kvm removes postgresql
> automatically.
> 
> Furthermore, even if I install postgresql later on, starting qemu, shuts down 
> postres.
> No matter how much I tried, it was impossible for me to run qemu and 
> postgresql-9.2 on my machine at the same time. 
> 
> My version of Ubuntu is Saucy Salamander.
> 
> So are you saying this is not something related to QEMU project?
> Who should this be addressed to?

This is a packaging issue related to the dependencies.  By the above
example it actually sounds like virt-manager, not qemu, is conflicting.

 status: incomplete.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1246012

Title:
  QEMU removes postgresql

Status in QEMU:
  Invalid

Bug description:
  >sudo apt-get install kvm virt-manager removed postgresql-9.2 from my system.
  Furthermore, it seem impossible for me to run postgresql and qemu at the same 
time.
  Starting one, kills the other.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1246012/+subscriptions

[Qemu-devel] [Bug 1246012] Re: QEMU removes postgresql

[Joe Doe]

You guys speak in technical terms that I can hardly understand.
postgresql-9.2 is not the default version for Ubuntu(I believe 9.1 is), but can 
easily be installed by using the steps here -> 
http://www.postgresql.org/download/linux/ubuntu/ .

Anyways, the issue seems to be here:

>sudo apt-get install kvm virt-manager
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'qemu-system-x86' instead of 'kvm'
qemu-system-x86 is already the newest version.
The following extra packages will be installed:
  libvirt-bin logrotate
Suggested packages:
  radvd python-guestfs python-spice-client-gtk
The following packages will be REMOVED:
  postgresql-9.2 postgresql-common postgresql-plperl-9.2
The following NEW packages will be installed:
  libvirt-bin logrotate virt-manager
0 upgraded, 3 newly installed, 3 to remove and 0 not upgraded.
Need to get 0 B/3,570 kB of archives.
After this operation, 5,177 kB disk space will be freed.
Do you want to continue [Y/n]? Y
(Reading database ... 210251 files and directories currently installed.)
Removing postgresql-plperl-9.2 ...
Removing postgresql-9.2 ...
 * Stopping PostgreSQL 9.2 database server [ OK ]
Removing postgresql-common ...
Removing 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by 
postgresql-common'
Processing triggers for ureadahead ...
Processing triggers for man-db ...
Selecting previously unselected package logrotate.
(Reading database ... 209976 files and directories currently installed.)
Unpacking logrotate (from .../logrotate_3.8.3-3ubuntu2_amd64.deb) ...
Selecting previously unselected package libvirt-bin.
Unpacking libvirt-bin (from .../libvirt-bin_1.1.1-0ubuntu8_amd64.deb) ...
Selecting previously unselected package virt-manager.
Unpacking virt-manager (from .../virt-manager_0.9.5-1ubuntu1_all.deb) ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
Processing triggers for gconf2 ...
Processing triggers for bamfdaemon ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for desktop-file-utils ...
Processing triggers for gnome-menus ...
Processing triggers for mime-support ...
Processing triggers for hicolor-icon-theme ...
Setting up logrotate (3.8.3-3ubuntu2) ...
Setting up libvirt-bin (1.1.1-0ubuntu8) ...
libvirt-bin start/running, process 24248
Setting up libvirt-bin dnsmasq configuration.
Setting up virt-manager (0.9.5-1ubuntu1) ...

As you can see from the logs, installing kvm removes postgresql
automatically.

Furthermore, even if I install postgresql later on, starting qemu, shuts down 
postres.
No matter how much I tried, it was impossible for me to run qemu and 
postgresql-9.2 on my machine at the same time. 

My version of Ubuntu is Saucy Salamander.

So are you saying this is not something related to QEMU project?
Who should this be addressed to?

Thank you

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1246012

Title:
  QEMU removes postgresql

Status in QEMU:
  Invalid

Bug description:
  >sudo apt-get install kvm virt-manager removed postgresql-9.2 from my system.
  Furthermore, it seem impossible for me to run postgresql and qemu at the same 
time.
  Starting one, kills the other.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1246012/+subscriptions

[Qemu-devel] [PATCH] MAINTAINERS: add git tree info for HMP, QMP and QAPI

[Luiz Capitulino]

Signed-off-by: Luiz Capitulino 
---
 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 77edacf..02b85ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -699,6 +699,7 @@ S: Supported
 F: monitor.c
 F: hmp.c
 F: hmp-commands.hx
+T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
 
 Network device layer
 M: Anthony Liguori 
@@ -720,6 +721,7 @@ M: Luiz Capitulino 
 M: Michael Roth 
 S: Supported
 F: qapi/
+T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
 
 QAPI Schema
 M: Eric Blake 
@@ -727,6 +729,7 @@ M: Luiz Capitulino 
 M: Markus Armbruster 
 S: Supported
 F: qapi-schema.json
+T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
 
 QMP
 M: Luiz Capitulino 
@@ -735,6 +738,7 @@ F: qmp.c
 F: monitor.c
 F: qmp-commands.hx
 F: QMP/
+T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
 
 SLIRP
 M: Jan Kiszka 
-- 
1.8.1.4

[Qemu-devel] Multi-head support RFC

[John Baboval]

Hello,

I am currently the device model maintainer for XenClient Enterprise. As 
you may or may not know, we maintain a patch queue on top of QEMU 
(currently 1.3) that adds functionality needed to support XCE features.


One of the major things we add is robust multi-head support. This 
includes DDC emulation for EDID data, variable VRAM size, monitor 
hot-plug support, simulated VSYNC, and guest controlled display 
orientation. This includes both the necessary interfaces between the hw 
and ui, and a new emulated adapter (with drivers) that exercises the 
interfaces.


Between QEMU 1.3 and QEMU 1.6, a lot of changes were made to the 
QemuConsole and DisplayState structures that will require significant 
changes to our patches. I'd like to adapt to these changes in such a way 
that they might make some of our work acceptable upstream. As such, I'd 
like to describe how the patches currently work, describe how I'd 
propose they work in the new version, and solicit feedback as to if the 
plans would be acceptable.


I've stuck our current patch queue on github for convenience. If I refer 
to a patch in the below description, you can check it out there: 
https://github.com/jbaboval/xce-qemu.pq


This is what we currently do:

In QEMU 1.3, there was a DisplayState list. We used one DisplayState per 
monitor. The DisplayChangeListener has a new hw_add_display vector, so 
that when the UI requests a second monitor the new display gets attached 
to the emulated hardware. (patch: add_display_ptr)


Each DisplayState was given an ID, so that emulated hardware could keep 
track of which EDID and other metadata went with with DisplayState. 
(patch: display-id-allocation)


A new function, gui_start_updates, starts refresh of the new display. 
This seems to be equivalent to the new gui_setup_refresh() that exists 
in newer versions. (patch: gui_start_updates)


A new vector, hw_store_edid, was added to DisplayState so that UIs could 
tell emulated hardware what the EDID for a given display should be. 
(patch: edid-vector)


A new vector, hw_notify, was added to DisplayState so the UIs could tell 
the emulated hardware about interesting events, such as monitor hotplugs 
(new windows), orientation changes, availability of hardware cursor 
functionality, etc... (patch: display-hw-notify)


VRAM size was made configurable, so that more could be allocated to 
handle multiple high-resolution displays. (patch: variable-vram-size)



The flow is:

- The user requests a hotplug (user added a "monitor" with a menu, UI 
reacted to a udev hotplug or XRandR event, or whatever)
- The UI asks the hw to allocate a new display. If the hw doesn't 
support it (vector is NULL), the system continues with one display.
- The hw returns a new DisplayState to the UI with all the hw_ vectors 
filled in

- The UI registers its DisplayChangeListener with the new DisplayState
- The UI provides an EDID for the new display with hw_store_edid()
- The UI notifies the guest that an event has occured with hw_notify()
- The UI starts a gui timer for the new DisplayState with 
gui_start_updates()
- The guest driver does its normal thing, sets the mode on the new 
display, and starts rendering

- The timer handler calls gfx_hw_update for the DisplayState
- The hw calls dpy_update for changes on the new DisplayState

.


In the latest code, DisplayState isn't a list anymore, and many 
operations that apply to a DisplayState apply to a QemuConsole instead. 
Also, the DisplaySurface is a property of the QemuConsole now instead of 
part of the DisplayState. I'm going to have to make some fairly 
fundamental changes to our current architecture to adapt to the latest 
upstream changes, and I would appreciate feedback on the options.


I don't think it makes sense to have a QemuConsole per display.

I can use a model similar to what qxl does, and put the framebuffer for 
each display inside a single DisplaySurface allocated to be a bounding 
rectangle around all framebuffers. This has the advantage of looking 
like something that already exists in the tree, but has several 
disadvantages. It was convenient - but not necessary - to have a 
DisplaySurface per display, since that kept track of the display mode, 
allowed different depths per monitor (not very useful, but possible), 
etc. If the displays are different resolutions, it leaves a dead space 
of wasted memory inside the region. If there's a single DisplaySurface, 
some other structure/list/array will need to be added to track the 
individual resolutions, offsets, and strides of the sub-regions in order 
to be able to display them in separate windows or - more likely - as 
full screen on real displays. It also makes hot-plugging more complex, 
since adding/removing a display will alter the configuration of the 
existing displays.


I could turn the DisplayState and DisplaySurface in QEMU console into 
lists, and run much like my existing patches.


I could move the DisplaySurface back into DisplaySta

Re: [Qemu-devel] [PATCH] ossaudio: do not enable by default

[Peter Maydell]

On 5 November 2013 19:57, Anthony Liguori  wrote:
> This patch just requires that you explicitly select oss so it's not
> breaking audio on BSD.

That sounds to me like it's breaking audio for all the
users for whom it previously worked out of the box
without any particular configure or command line options.
In fact I suspect it also breaks audio for all the *linux*
users for whom it previously worked without special options.

-- PMM

Re: [Qemu-devel] USB Passthrough not working for Windows 7 guest

[Jens Frederich]

>On 2013-11-05 17:01, Frederich, Jens wrote:
>> Hi all,
>>
>> we're currently evaluating different RTOS systems (Windows CE, Intime, RTX,
>> etc.).
>> One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all
>> works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one
>> QEMU bug
>> breaks my measurement setup and evaluation.
>>
>> I've some usb devices for the Windows 7 guest. I configure them as USB
>> passthrough.
>> The devices appears in the device manager of Windows 7, but with
>> "Error code 10": device cannot start". The Windows driver fails on USB set
>> configuration.
>> The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL
>> fails with
>> invalid parameter.
>>
>> driver log:
>> 0009  0.65470564  vnCDrvUsbControlRequestSetConfiguration,
>> WdfUsbTargetDeviceSelectConfig single interface failed 0xc00d
>> 0010  0.65472370  vnCDrvUsbIFPrepareHardwareState,
>> vnCDrvUsbControlRequestSetConfiguration failed: 0xc00d
>> 0011  0.65473646  vnCDrvDevConPrepareHardware,
>> vnCDrvUsbIFPrepareHardwareState failed 0xc00d
>> 0012  0.65474838  vnCDrvEvtDevicePrepareHardware,
>> vnCDrvDevConPrepareHardware failed 0xc001
>> 0013  0.6547
>>
>> This bug breaks my latency measurement setup and Linux RT is out of the
>> evaluationg
>> race. Windows CE should not win :-), it there anyway workaround or hack to
>> fix the issue?
>
>Workaround: Pass-through one of the (typically) many USB host
>controllers to the Windows guest (vfio or classic pci-assign). I did
>this back then when *HCI emulation was still pretty immature.
>
>But USB device pass-through should also work. Do you happen to pass a
>USB 2.0 device via an emulated UHCI? Or are you already using the EHCI
>emulation?

I'm not sure which mode it has been. I've used the virt-manager to configure
the device. A usb controller is already configured in mode 'default'.
My steps on virt-manager:

1. add hardware
2. select usb host device
3. I can see my usb device, I select it
4. start guest and open Windows device manager

I don't know is this UHCI or EHCI? On the usb host device list are
some controller listed e.q. xhci, ehci and so on. Should I map these
controller to Windows 7 as well?

thanks,
Jens

Re: [Qemu-devel] [PATCH] ossaudio: do not enable by default

[Peter Maydell]

On 5 November 2013 19:57, Anthony Liguori  wrote:
> Since the oss code can fail to initialize without handling it
> gracefully, it really cannot be default on any platform.

Can you describe what the actual problem is we're trying
to fix here, please? I can't see a description of it
in any of the mailing list threads (there are references
to irc conversations but it's really not clear what the
actual symptoms are).

I have a system with no /dev/dsp, and it can build and
run systems fine (including passing 'make check') with
the oss backend as the (default-by-configure) only backend.
The only thing that happens is that there are a bunch of
warnings from ossaudio, like this:
oss: Could not initialize ADC
oss: Failed to open `/dev/dsp'
oss: Reason: No such file or directory
oss: Could not initialize ADC
oss: Failed to open `/dev/dsp'
oss: Reason: No such file or directory
audio: Failed to create voice `mm_ac97.in'

but they don't prevent make check from working,
they don't prevent systems from booting, and they
have been present for *years*.

I really don't see why you suddenly needed to
apply this patch despite the fact that most of
the response you got to it was negative.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] block: Save errno before error_setg_errno

[Benoît Canet]

Le Tuesday 05 Nov 2013 à 20:03:33 (+0100), Max Reitz a écrit :
> error_setg_errno() may overwrite errno; therefore, its value should be
> read before calling that function and not afterwards.
> 
> Signed-off-by: Max Reitz 
> ---
>  block.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/block.c b/block.c
> index 58efb5b..0e96a22 100644
> --- a/block.c
> +++ b/block.c
> @@ -1084,8 +1084,8 @@ int bdrv_open(BlockDriverState *bs, const char 
> *filename, QDict *options,
>  snprintf(backing_filename, sizeof(backing_filename),
>   "%s", filename);
>  } else if (!realpath(filename, backing_filename)) {
> -error_setg_errno(errp, errno, "Could not resolve path '%s'", 
> filename);
>  ret = -errno;
> +error_setg_errno(errp, errno, "Could not resolve path '%s'", 
> filename);
>  goto fail;
>  }
>  
> -- 
> 1.8.4.2
> 

Reviewed-by: Benoit Canet 
> 

Re: [Qemu-devel] [PATCH] ossaudio: do not enable by default

[Anthony Liguori]

Gerd Hoffmann  writes:

> On So, 2013-11-03 at 08:45 -0800, Anthony Liguori wrote:
>> Modern Linux's no longer support /dev/dsp so enabling it by
>> default causes audio failures on newer Linux distros.
>
> That will break sound on BSD.
>
> I think we should do something like this instead:
>
> --- a/configure
> +++ b/configure
> @@ -554,7 +554,7 @@ Haiku)
>LIBS="-lposix_error_mapper -lnetwork $LIBS"
>  ;;
>  *)
> -  audio_drv_list="oss"
> +  audio_drv_list="pa alsa oss"
>audio_possible_drivers="oss alsa sdl esd pa"
>linux="yes"
>linux_user="yes"
>
> i.e. build pulseaudio and alsa by default on linux and prioritize them
> over oss.

This patch just requires that you explicitly select oss so it's not
breaking audio on BSD.

Since the oss code can fail to initialize without handling it
gracefully, it really cannot be default on any platform.

Same problem would occur on BSD if the permissions on /dev/dsp were
restrictive.

Regards,

Anthony Liguori

>
> cheers,
>   Gerd

Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0

[Peter Maydell]

On 5 November 2013 19:31, Andreas Färber  wrote:
> Am 05.11.2013 20:09, schrieb Peter Maydell:
>> I don't think there's any need to respin a patch
>> just because somebody thinks it might be worth
>> applying to stable.
>
> Point is, if you are ping'ing Anthony to apply this with his
> fully-automated patches tool, then he won't add the Cc and in turn it
> will unlikely be backported to 1.6.2.
>
> The response I got at QEMU Summit was that it is both the contributor's
> and the submaintainer's responsibility to add the Cc to the commit
> message. But maybe you're going to tell me that I misunderstood that as
> well...

I don't remember what people said particularly, but I don't
think our process for stable should rely on patch submitters
having to add cc tags and resend stuff because that's a
lot of faff for something most people don't care about.
Whoever is maintaining stable ought IMHO to be making their
own judgements about whether a fix is worth backporting
based on their criteria for what kind of fix to put in
that branch.

-- PMM

Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0

[Andreas Färber]

Am 05.11.2013 20:09, schrieb Peter Maydell:
> On 5 November 2013 18:45, Andreas Färber  wrote:
>> Am 05.11.2013 19:04, schrieb Peter Maydell:
>>> Ping!
>>
>> A typo in the commit message has been reported
> 
> What typo? Alex sent a reply claiming that there was
> a missing space in the subject but that appears to be
> entirely his email client's problem, since as you can
> see from this mail and also in Linaro's patchwork
> http://patches.linaro.org/21203/ there is a space there.
> (I would link to the qemu patchwork but it seems to
> be down right now.)

Looks like you're right. You replying to his claim would've helped. ;)

>> , and it has been
>> requested to add Cc: qemu-sta...@nongnu.org.
> 
> I don't think there's any need to respin a patch
> just because somebody thinks it might be worth
> applying to stable.

Point is, if you are ping'ing Anthony to apply this with his
fully-automated patches tool, then he won't add the Cc and in turn it
will unlikely be backported to 1.6.2.

The response I got at QEMU Summit was that it is both the contributor's
and the submaintainer's responsibility to add the Cc to the commit
message. But maybe you're going to tell me that I misunderstood that as
well...

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH] block: Save errno before error_setg_errno

[Eric Blake]

On 11/05/2013 12:03 PM, Max Reitz wrote:
> error_setg_errno() may overwrite errno; therefore, its value should be
> read before calling that function and not afterwards.
> 
> Signed-off-by: Max Reitz 
> ---
>  block.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Eric Blake 

Still, wouldn't it be easier to patch error_setg_errno (and friends) to
guarantee that errno is unchanged on exit compared to its value on
entrance, rather than having to audit for other mistakes like this?

> 
> diff --git a/block.c b/block.c
> index 58efb5b..0e96a22 100644
> --- a/block.c
> +++ b/block.c
> @@ -1084,8 +1084,8 @@ int bdrv_open(BlockDriverState *bs, const char 
> *filename, QDict *options,
>  snprintf(backing_filename, sizeof(backing_filename),
>   "%s", filename);
>  } else if (!realpath(filename, backing_filename)) {
> -error_setg_errno(errp, errno, "Could not resolve path '%s'", 
> filename);
>  ret = -errno;
> +error_setg_errno(errp, errno, "Could not resolve path '%s'", 
> filename);
>  goto fail;
>  }
>  
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0

[Peter Maydell]

On 5 November 2013 18:45, Andreas Färber  wrote:
> Am 05.11.2013 19:04, schrieb Peter Maydell:
>> Ping!
>
> A typo in the commit message has been reported

What typo? Alex sent a reply claiming that there was
a missing space in the subject but that appears to be
entirely his email client's problem, since as you can
see from this mail and also in Linaro's patchwork
http://patches.linaro.org/21203/ there is a space there.
(I would link to the qemu patchwork but it seems to
be down right now.)

>, and it has been
> requested to add Cc: qemu-sta...@nongnu.org.

I don't think there's any need to respin a patch
just because somebody thinks it might be worth
applying to stable.

-- PMM

Re: [Qemu-devel] [PATCH v2 2/2] qemu-iotests: Add test for unbacked mirroring

[Max Reitz]

On 05.11.2013 10:00, Wenchao Xia wrote:
> 于 2013/11/5 8:35, Max Reitz 写道:
>> Add a new test for mirroring unbacked images in "absolute-paths" mode.
>> This should work, if possible, but most importantly, qemu should never
>> crash.
>>
>> Signed-off-by: Max Reitz 
>> ---
>>   tests/qemu-iotests/070 | 91 
>> ++
>>   tests/qemu-iotests/070.out | 33 +
>>   tests/qemu-iotests/group   |  1 +
>>   3 files changed, 125 insertions(+)
>>   create mode 100755 tests/qemu-iotests/070
>>   create mode 100644 tests/qemu-iotests/070.out
>>
>> diff --git a/tests/qemu-iotests/070 b/tests/qemu-iotests/070
>> new file mode 100755
>> index 000..25ecf99
>> --- /dev/null
>> +++ b/tests/qemu-iotests/070
>> @@ -0,0 +1,91 @@
>> +#!/bin/bash
>> +#
>> +# Test mirroring block device without backing file in absolute-paths mode
>> +#
>> +# Copyright (C) 2013 Red Hat, Inc.
>> +#
>> +# This program is free software; you can redistribute it and/or modify
>> +# it under the terms of the GNU General Public License as published by
>> +# the Free Software Foundation; either version 2 of the License, or
>> +# (at your option) any later version.
>> +#
>> +# This program is distributed in the hope that it will be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program.  If not, see .
>> +#
>> +
>> +# creator
>> +owner=mre...@redhat.com
>> +
>> +seq="$(basename $0)"
>> +echo "QA output created by $seq"
>> +
>> +here="$PWD"
>> +tmp=/tmp/$$
>> +status=1# failure is the default!
>> +
>> +_cleanup()
>> +{
>> +_cleanup_test_img
>> +}
>> +trap "_cleanup; exit \$status" 0 1 2 3 15
>> +
>> +# get standard environment, filters and checks
>> +. ./common.rc
>> +. ./common.filter
>> +
>> +_supported_fmt qed qcow2 qcow2 vmdk
>> +_supported_proto file
>> +_supported_os Linux
>> +
>> +function do_run_qemu()
>> +{
>> +echo Testing: "$@" | _filter_imgfmt
>> +$QEMU -nographic -qmp stdio -serial none "$@"
>> +echo
>> +}
>> +
>> +function run_qemu()
>> +{
>> +# Filter out empty returns and the SHUTDOWN event, because these may 
>> occur
>> +# interleaved with the block job events (in a non-deterministic manner).
>> +# Also, filter out the "Formatting" message which is emitted when the 
>> target
>> +# image is created - it contains format-specific information.
>> +do_run_qemu "$@" 2>&1 | _filter_testdir | _filter_qmp |\
>> +grep -v '{"return": {}}' | grep -v '"event": "SHUTDOWN"' |\
>> +grep -v '^Formatting'
>> +}
>> +
>> +size=128K
>> +
>> +_make_test_img $size
>> +
>> +for sync in full top none
>> +do
>> +
>> +echo
>> +echo "=== Mirroring non-backed image in absolute-paths mode with sync=$sync 
>> ==="
>> +echo
>> +
>> +run_qemu -drive file="$TEST_IMG",format="$IMGFMT",if=none,id=disk \
>> + -device virtio-blk-pci,drive=disk,id=virtio0 <> +{ "execute": "qmp_capabilities" }
>> +{ "execute": "drive-mirror",
>> +"arguments": { "device": "disk", "target": "$TEST_IMG.target",
>> +   "format": "$IMGFMT", "mode": "absolute-paths",
>> +   "sync": "$sync" } }
>> +{ "execute": "quit" }
>> +EOF
>> +
>> +rm -f $TEST_IMG.target
>> +
>> +done
>> +
>> +# success, all done
>> +echo "*** done"
>> +rm -f $seq.full
>> +status=0
>> diff --git a/tests/qemu-iotests/070.out b/tests/qemu-iotests/070.out
>> new file mode 100644
>> index 000..246b0f1
>> --- /dev/null
>> +++ b/tests/qemu-iotests/070.out
>> @@ -0,0 +1,33 @@
>> +QA output created by 070
>> +Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=131072
>> +
>> +=== Mirroring non-backed image in absolute-paths mode with sync=full ===
>> +
>> +Testing: -drive file=TEST_DIR/t.IMGFMT,format=IMGFMT,if=none,id=disk 
>> -device virtio-blk-pci,drive=disk,id=virtio0
>> +QMP_VERSION
>> +{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
>> "BLOCK_JOB_READY", "data": {"device": "disk", "len": 131072, "offset": 
>> 131072, "speed": 0, "type": "mirror"}}
>> +{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
>> "BLOCK_JOB_COMPLETED", "data": {"device": "disk", "len": 131072, "offset": 
>> 131072, "speed": 0, "type": "mirror"}}
>> +{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
>> "DEVICE_TRAY_MOVED", "data": {"device": "ide1-cd0", "tray-open": true}}
>> +{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
>> "DEVICE_TRAY_MOVED", "data": {"device": "floppy0", "tray-open": true}}
>> +
>> +
>> +=== Mirroring non-backed image in absolute-paths mode with sync=top ===
>> +
>> +Testing: -drive file=TEST_DIR/t.IMGFMT,format=IMGFMT,if=none,id=disk 
>> -device virtio-blk-pci,drive=disk,id=virtio0
>> +QMP_VERSIO

Re: [Qemu-devel] [PATCH v2 1/2] block/drive-mirror: Check for NULL backing_hd

[Max Reitz]

On 05.11.2013 04:32, Fam Zheng wrote:
>
> On 11/05/2013 08:35 AM, Max Reitz wrote:
>> It should be possible to execute the QMP "drive-mirror" command in
>> "none" sync mode and "absolute-paths" mode even for block devices
>> lacking a backing file.
>>
>> "absolute-paths" does in fact not require a backing file to be present,
>> as can be seen from the "top" sync mode code path. "top" basically
>> states that the device should indeed have a backing file - however, the
>> current code catches the case if it doesn't and then simply treats it as
>> "full" sync mode, creating a target image without a backing file (in
>> "absolute-paths" mode). Thus, "absolute-paths" does not imply the target
>> file must indeed have a backing file.
>>
>> Therefore, the target file may be left unbacked in case of "none" sync
>> mode as well, if the specified device is not backed either. Currently,
>> qemu will crash trying to dereference the backing file pointer since it
>> assumes that it will always be non-NULL in that case ("none" with
>> "absolute-paths").
>>
>> Signed-off-by: Max Reitz 
>> ---
>>   blockdev.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/blockdev.c b/blockdev.c
>> index b260477..986e59d 100644
>> --- a/blockdev.c
>> +++ b/blockdev.c
>> @@ -2038,8 +2038,8 @@ void qmp_drive_mirror(const char *device, const
>> char *target,
>>   case NEW_IMAGE_MODE_ABSOLUTE_PATHS:
>>   /* create new image with backing file */
>>   bdrv_img_create(target, format,
>> -source->filename,
>> -source->drv->format_name,
>> +source ? source->filename : NULL,
>> +source ? source->drv->format_name : NULL,
>>   NULL, size, flags, &local_err, false);
>>   break;
>>   default:
> The code around here is:
>
> 2029 if (sync == MIRROR_SYNC_MODE_FULL && mode !=
> NEW_IMAGE_MODE_EXISTING) {
> 2030 /* create new image w/o backing file */
> 2031 assert(format && drv);
> 2032 bdrv_img_create(target, format,
> 2033 NULL, NULL, NULL, size, flags,
> &local_err, false);
> 2034 } else {
> 2035 switch (mode) {
> 2036 case NEW_IMAGE_MODE_EXISTING:
> 2037 break;
> 2038 case NEW_IMAGE_MODE_ABSOLUTE_PATHS:
> 2039 /* create new image with backing file */
> 2040 bdrv_img_create(target, format,
> 2041 source->filename,
> 2042 source->drv->format_name,
> 2043 NULL, size, flags, &local_err, false);
> 2044 break;
> 2045 default:
> 2046 abort();
> 2047 }
> 2048 }
>
> Why not update the if condition and reuse the branch, I think this is
> a better branching? Either should be fine, but in your change you
> should also update the comment in line 2039.

Okay, I'll go for updating the condition.

Max

> Thanks,
> Fam

Re: [Qemu-devel] [PATCH v2 0/9] Remove legacy unaligned bswap functions

[Richard Henderson]

On 11/06/2013 02:38 AM, Peter Maydell wrote:
> This is a simple resend of a patchset which has been
> on the list reviewed but unapplied for nine weeks, since
> it's probably fallen out of Anthony's patches cache.
> 
> 
> The bswap.h header includes a set of "legacy unaligned functions"
> that (since commit c732a52d3 at the beginning of this year) are
> just wrappers for underlying {ld,st} functions. The legacy
> functions aren't used in many places, so just replace all their
> uses with uses of the new-style {ld,st} functions; this lets us
> remove the legacy wrappers altogether.
> 
> Since we know the {ld,st}* routines are definitely functions,
> we can in the process remove some casts which were left over
> from when the legacy unaligned functions were previously macros.
> 
> The patchset is divided up by function being removed, rather
> than by which device/subsystem is being fixed; I think this way
> round is easier to review since you only have to keep one
> substitution in your head when reading a patch.
> 
> Peter Maydell (9):
>   bswap.h: Remove cpu_to_le16wu()
>   bswap.h: Remove cpu_to_le32wu()
>   bswap.h: Remove le16_to_cpupu()
>   bswap.h: Remove le32_to_cpupu()
>   bswap.h: Remove be32_to_cpupu()
>   bswap.h: Remove cpu_to_be16wu()
>   bswap.h: Remove cpu_to_be32wu()
>   bswap.h: Remove cpu_to_be64wu()
>   bswap.h: Remove cpu_to_32wu()

Reviewed-by: Richard Henderson 

... again.

> 
>  block/qcow2-cluster.c |2 +-
>  hw/acpi/core.c|3 +--
>  hw/block/cdrom.c  |   10 +-
>  hw/display/vga_template.h |   14 --
>  hw/ide/atapi.c|   16 +++
>  hw/net/e1000.c|   22 +
>  hw/net/ne2000.c   |4 ++--
>  hw/pci/pcie_aer.c |4 ++--
>  include/hw/pci/pci.h  |8 
>  include/qemu/bswap.h  |   47 
> -
>  10 files changed, 40 insertions(+), 90 deletions(-)
> 

[Qemu-devel] [PATCH] block: Save errno before error_setg_errno

[Max Reitz]

error_setg_errno() may overwrite errno; therefore, its value should be
read before calling that function and not afterwards.

Signed-off-by: Max Reitz 
---
 block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block.c b/block.c
index 58efb5b..0e96a22 100644
--- a/block.c
+++ b/block.c
@@ -1084,8 +1084,8 @@ int bdrv_open(BlockDriverState *bs, const char *filename, 
QDict *options,
 snprintf(backing_filename, sizeof(backing_filename),
  "%s", filename);
 } else if (!realpath(filename, backing_filename)) {
-error_setg_errno(errp, errno, "Could not resolve path '%s'", 
filename);
 ret = -errno;
+error_setg_errno(errp, errno, "Could not resolve path '%s'", 
filename);
 goto fail;
 }
 
-- 
1.8.4.2

Re: [Qemu-devel] [PULL v3 52/57] qom: Fix pointer to int property helpers' documentation

[Andreas Färber]

Am 05.11.2013 18:12, schrieb Andreas Färber:
> From: "Michael S. Tsirkin" 
> 
> Relocate to alongside the other object_property_add_* helpers while at it.
> 
> Signed-off-by: Andreas Färber 

Sorry Michael, forgot to edit the --author after resolving the merge
conflict.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] [Bug 1247478] Re: usb passthrough mass storage write data corruption

[Sascha Krissler]

it is apparently not a qemu bug, but either a libusb or (more likely) linux bug.
it happens on linux 3.6 but not linux 3.4, with the difference of:
(USBFS_CAP_NO_PACKET_SIZE_LIM | USBFS_CAP_BULK_SCATTER_GATHER)
added to the hcd capabilities bitfield in 3.6

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1247478

Title:
  usb passthrough mass storage write data corruption

Status in QEMU:
  New

Bug description:
  the windows 7 professional guest writes to usb high speed mass storage 
devices connected via host-libusb
  in bulk packages of either size 20480 or 4096 (as far as the actual file data 
is concerned and
  except for the last packet for odd-sized files). The pattern is:
  3 times bulk out 20480
  1 time bulk out 4096

  and that repeats for files longer than 65536 bytes.

  the file on the usb disk is corrupted and it is always corrupt in the last 
4096 bytes of each
  20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 
36864-40960 and
  57344-61440.
  and so on. and because the 4096 sized  bulk out is always error free, the 
next corrupt span is from
  81920-86016.

  the last 4096 bytes of the 20480 sized transfer is always identical to the 
first 4096 bytes of the same
  transfer.

  to reproduce: run windows7 guest on and pass through usb2.0 disk with 
host-libusb. write a large file.
  (possibly check the bulk transfer sizes with usbmon).
  note that attaching usb disks with hw/usb/dev-storage does work just fine.
  cannot reproduce with linux as it always writes just 4096 bytes and writes 
with a linux guest are
  always ok even with usb passthrough.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1247478/+subscriptions

Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0

[Andreas Färber]

Am 05.11.2013 19:04, schrieb Peter Maydell:
> Ping!

A typo in the commit message has been reported, and it has been
requested to add Cc: qemu-sta...@nongnu.org. Since you neither CC
qemu-trivial nor a particular maintainer that would fix those for you,
you'll have to respin.

Andreas

> 
> thanks
> -- PMM
> 
> On 21 October 2013 21:03, Peter Maydell  wrote:
>> Our rules.mak adds '-rR' to MAKEFLAGS to indicate that we will be
>> explicitly specifying everything and not relying on any default
>> variables or rules. However we were accidentally relying on the
>> default ARFLAGS ("rv"). This went unnoticed because of a bug in
>> GNU Make 3.82 and earlier which meant that adding -rR to MAKEFLAGS
>> only affected submakes, not the currently running instance.
>> Explicitly set ARFLAGS in config-host.mak, in the same way we
>> handle CFLAGS and LDFLAGS; this will allow us to work with
>> Make 4.0.
>>
>> Thanks to Paul Smith for analyzing this bug for us.
>>
>> Reported-by: Ken Moffat 
>> Signed-off-by: Peter Maydell 
>> ---
>> Ken: I think this should work (and it doesn't break building with
>> old makes), but I don't have a make 4.0 to hand; if you could
>> test it I'd appreciate it.
>>
>>  configure | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/configure b/configure
>> index 57ee62a..4eb3a07 100755
>> --- a/configure
>> +++ b/configure
>> @@ -308,6 +308,9 @@ query_pkg_config() {
>>  pkg_config=query_pkg_config
>>  sdl_config="${SDL_CONFIG-${cross_prefix}sdl-config}"
>>
>> +# If the user hasn't specified ARFLAGS, default to 'rv', just as make does.
>> +ARFLAGS="${ARFLAGS-rv}"
>> +
>>  # default flags for all hosts
>>  QEMU_CFLAGS="-fno-strict-aliasing $QEMU_CFLAGS"
>>  QEMU_CFLAGS="-Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
>> $QEMU_CFLAGS"
>> @@ -3664,6 +3667,7 @@ echo "C compiler$cc"
>>  echo "Host C compiler   $host_cc"
>>  echo "C++ compiler  $cxx"
>>  echo "Objective-C compiler $objcc"
>> +echo "ARFLAGS   $ARFLAGS"
>>  echo "CFLAGS$CFLAGS"
>>  echo "QEMU_CFLAGS   $QEMU_CFLAGS"
>>  echo "LDFLAGS   $LDFLAGS"
>> @@ -4239,6 +4243,7 @@ echo "HOST_CC=$host_cc" >> $config_host_mak
>>  echo "CXX=$cxx" >> $config_host_mak
>>  echo "OBJCC=$objcc" >> $config_host_mak
>>  echo "AR=$ar" >> $config_host_mak
>> +echo "ARFLAGS=$ARFLAGS" >> $config_host_mak
>>  echo "AS=$as" >> $config_host_mak
>>  echo "CPP=$cpp" >> $config_host_mak
>>  echo "OBJCOPY=$objcopy" >> $config_host_mak
>> --
>> 1.7.11.4
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0

[Peter Maydell]

Ping!

thanks
-- PMM

On 21 October 2013 21:03, Peter Maydell  wrote:
> Our rules.mak adds '-rR' to MAKEFLAGS to indicate that we will be
> explicitly specifying everything and not relying on any default
> variables or rules. However we were accidentally relying on the
> default ARFLAGS ("rv"). This went unnoticed because of a bug in
> GNU Make 3.82 and earlier which meant that adding -rR to MAKEFLAGS
> only affected submakes, not the currently running instance.
> Explicitly set ARFLAGS in config-host.mak, in the same way we
> handle CFLAGS and LDFLAGS; this will allow us to work with
> Make 4.0.
>
> Thanks to Paul Smith for analyzing this bug for us.
>
> Reported-by: Ken Moffat 
> Signed-off-by: Peter Maydell 
> ---
> Ken: I think this should work (and it doesn't break building with
> old makes), but I don't have a make 4.0 to hand; if you could
> test it I'd appreciate it.
>
>  configure | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/configure b/configure
> index 57ee62a..4eb3a07 100755
> --- a/configure
> +++ b/configure
> @@ -308,6 +308,9 @@ query_pkg_config() {
>  pkg_config=query_pkg_config
>  sdl_config="${SDL_CONFIG-${cross_prefix}sdl-config}"
>
> +# If the user hasn't specified ARFLAGS, default to 'rv', just as make does.
> +ARFLAGS="${ARFLAGS-rv}"
> +
>  # default flags for all hosts
>  QEMU_CFLAGS="-fno-strict-aliasing $QEMU_CFLAGS"
>  QEMU_CFLAGS="-Wall -Wundef -Wwrite-strings -Wmissing-prototypes $QEMU_CFLAGS"
> @@ -3664,6 +3667,7 @@ echo "C compiler$cc"
>  echo "Host C compiler   $host_cc"
>  echo "C++ compiler  $cxx"
>  echo "Objective-C compiler $objcc"
> +echo "ARFLAGS   $ARFLAGS"
>  echo "CFLAGS$CFLAGS"
>  echo "QEMU_CFLAGS   $QEMU_CFLAGS"
>  echo "LDFLAGS   $LDFLAGS"
> @@ -4239,6 +4243,7 @@ echo "HOST_CC=$host_cc" >> $config_host_mak
>  echo "CXX=$cxx" >> $config_host_mak
>  echo "OBJCC=$objcc" >> $config_host_mak
>  echo "AR=$ar" >> $config_host_mak
> +echo "ARFLAGS=$ARFLAGS" >> $config_host_mak
>  echo "AS=$as" >> $config_host_mak
>  echo "CPP=$cpp" >> $config_host_mak
>  echo "OBJCOPY=$objcopy" >> $config_host_mak
> --
> 1.7.11.4

Re: [Qemu-devel] [PATCH v2] cpu-exec: Fix compiler warning (-Werror=clobbered)

[Andreas Färber]

Am 05.11.2013 18:52, schrieb Stefan Weil:
> Am 31.10.2013 20:41, schrieb Jan Kiszka:
>> On 2013-10-31 20:31, Stefan Weil wrote:
>>> Reloading of local variables after sigsetjmp is only needed for some
>>> buggy compilers.
>>>
>>> The code which should reload these variables causes compiler warnings
>>> with gcc 4.7 when compiler optimizations are enabled:
>>>
>>> cpu-exec.c:204:15: error:
>>>  variable ‘cpu’ might be clobbered by ‘longjmp’ or ‘vfork’
> [-Werror=clobbered]
>>> cpu-exec.c:207:15: error:
>>>  variable ‘cc’ might be clobbered by ‘longjmp’ or ‘vfork’
> [-Werror=clobbered]
>>> cpu-exec.c:202:28: error:
>>>  argument ‘env’ might be clobbered by ‘longjmp’ or ‘vfork’
> [-Werror=clobbered]
>>>
>>> Now this code is only used for compilers which need it
>>> (and gcc 4.5.x, x > 0 which does not need it but won't give warnings).
>>>
>>> There were bug reports for clang and gcc 4.5.0, while gcc 4.5.1
>>> was reported to work fine without the reload code.
>>>
>>> Signed-off-by: Stefan Weil 
>>> ---
>>>
>>> v2: Don't remove the code which causes the warnings, but use it
>>> only with clang or gcc < 4.6.
>>>
>>>  cpu-exec.c |8 ++--
>>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/cpu-exec.c b/cpu-exec.c
>>> index 30cfa2a..fec20c3 100644
>>> --- a/cpu-exec.c
>>> +++ b/cpu-exec.c
>>> @@ -677,14 +677,18 @@ int cpu_exec(CPUArchState *env)
>>> only be set by a memory fault) */
>>>  } /* for(;;) */
>>>  } else {
>>> -/* Reload env after longjmp - the compiler may have
> smashed all
>>> - * local variables as longjmp is marked 'noreturn'. */
>>> +#if defined(__clang__) || !QEMU_GNUC_PREREQ(4, 6)
>>> +/* Some compilers wrongly smash all local variables after
>>> + * siglongjmp. There were bug reports for gcc 4.5.0 and
> clang.
>>> + * Reload essential local variables here for those
> compilers.
>>> + * gcc 4.7 would complain about this code (-Wclobbered). */
>>>  cpu = current_cpu;
>>>  env = cpu->env_ptr;
>>>  #if !(defined(CONFIG_USER_ONLY) && \
>>>(defined(TARGET_M68K) || defined(TARGET_PPC) ||
> defined(TARGET_S390X)))
>>>  cc = CPU_GET_CLASS(cpu);
>>>  #endif
>>> +#endif /* __clang__ or old gcc */
>>>  }
>>>  } /* for(;;) */
>>> 
>>>
>>
>> Are all clang versions affected? Then this looks reasonable.
>>
>> Jan
> 
> Ping?
> 
> As cpu-exec.c has no explicit maintainer, I'd add this patch to my next
> pull request, if nobody minds, but I'd appreciate more comments or a
> Reviewed-by of course.

I feel kind of responsable for this as CPU maintainer, but I wasn't
CC'ed and have not been following the list so closely lately. ;)

It seems the person reporting this for FreeBSD hasn't been CC'ed either?

Having applied the previous patch complementing the reload, I'm
generally okay with #ifdef'ing it out. But I'd be happier if Jan and/or
Peter or anyone else would provide some *-by, including Tested-by.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH v2] cpu-exec: Fix compiler warning (-Werror=clobbered)

[Peter Maydell]

On 5 November 2013 17:52, Stefan Weil  wrote:
> Am 31.10.2013 20:41, schrieb Jan Kiszka:
>> On 2013-10-31 20:31, Stefan Weil wrote:
>>> Reloading of local variables after sigsetjmp is only needed for some
>>> buggy compilers.
>>>
>>> The code which should reload these variables causes compiler warnings
>>> with gcc 4.7 when compiler optimizations are enabled:
>>>
>>> cpu-exec.c:204:15: error:
>>>  variable ‘cpu’ might be clobbered by ‘longjmp’ or ‘vfork’
>>> [-Werror=clobbered]
>>> cpu-exec.c:207:15: error:
>>>  variable ‘cc’ might be clobbered by ‘longjmp’ or ‘vfork’
>>> [-Werror=clobbered]
>>> cpu-exec.c:202:28: error:
>>>  argument ‘env’ might be clobbered by ‘longjmp’ or ‘vfork’
>>> [-Werror=clobbered]
>>>
>>> Now this code is only used for compilers which need it
>>> (and gcc 4.5.x, x > 0 which does not need it but won't give warnings).
>>>
>>> There were bug reports for clang and gcc 4.5.0, while gcc 4.5.1
>>> was reported to work fine without the reload code.
>>>
>>> Signed-off-by: Stefan Weil 
>>> ---
>>>
>>> v2: Don't remove the code which causes the warnings, but use it
>>> only with clang or gcc < 4.6.
>>>
>>>  cpu-exec.c |8 ++--
>>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/cpu-exec.c b/cpu-exec.c
>>> index 30cfa2a..fec20c3 100644
>>> --- a/cpu-exec.c
>>> +++ b/cpu-exec.c
>>> @@ -677,14 +677,18 @@ int cpu_exec(CPUArchState *env)
>>> only be set by a memory fault) */
>>>  } /* for(;;) */
>>>  } else {
>>> -/* Reload env after longjmp - the compiler may have smashed
>>> all
>>> - * local variables as longjmp is marked 'noreturn'. */
>>> +#if defined(__clang__) || !QEMU_GNUC_PREREQ(4, 6)
>>> +/* Some compilers wrongly smash all local variables after
>>> + * siglongjmp. There were bug reports for gcc 4.5.0 and
>>> clang.
>>> + * Reload essential local variables here for those
>>> compilers.
>>> + * gcc 4.7 would complain about this code (-Wclobbered). */
>>>  cpu = current_cpu;
>>>  env = cpu->env_ptr;
>>>  #if !(defined(CONFIG_USER_ONLY) && \
>>>(defined(TARGET_M68K) || defined(TARGET_PPC) ||
>>> defined(TARGET_S390X)))
>>>  cc = CPU_GET_CLASS(cpu);
>>>  #endif
>>> +#endif /* __clang__ or old gcc */
>>>  }
>>>  } /* for(;;) */
>>>
>>>
>>
>> Are all clang versions affected? Then this looks reasonable.
>>
>> Jan
>
> Ping?
>
> As cpu-exec.c has no explicit maintainer, I'd add this patch to my next pull
> request, if nobody minds, but I'd appreciate more comments or a Reviewed-by
> of course.

Not a blocking of this patch, but it occured to me that maybe
we could have an assert in the #else path here to catch other
buggy compilers.

-- PMM

Re: [Qemu-devel] [PATCH v2] cpu-exec: Fix compiler warning (-Werror=clobbered)

[Stefan Weil]

Am 31.10.2013 20:41, schrieb Jan Kiszka:
> On 2013-10-31 20:31, Stefan Weil wrote:
>> Reloading of local variables after sigsetjmp is only needed for some
>> buggy compilers.
>>
>> The code which should reload these variables causes compiler warnings
>> with gcc 4.7 when compiler optimizations are enabled:
>>
>> cpu-exec.c:204:15: error:
>>  variable ‘cpu’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Werror=clobbered]
>> cpu-exec.c:207:15: error:
>>  variable ‘cc’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Werror=clobbered]
>> cpu-exec.c:202:28: error:
>>  argument ‘env’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Werror=clobbered]
>>
>> Now this code is only used for compilers which need it
>> (and gcc 4.5.x, x > 0 which does not need it but won't give warnings).
>>
>> There were bug reports for clang and gcc 4.5.0, while gcc 4.5.1
>> was reported to work fine without the reload code.
>>
>> Signed-off-by: Stefan Weil 
>> ---
>>
>> v2: Don't remove the code which causes the warnings, but use it
>> only with clang or gcc < 4.6.
>>
>>  cpu-exec.c |8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/cpu-exec.c b/cpu-exec.c
>> index 30cfa2a..fec20c3 100644
>> --- a/cpu-exec.c
>> +++ b/cpu-exec.c
>> @@ -677,14 +677,18 @@ int cpu_exec(CPUArchState *env)
>> only be set by a memory fault) */
>>  } /* for(;;) */
>>  } else {
>> -/* Reload env after longjmp - the compiler may have
smashed all
>> - * local variables as longjmp is marked 'noreturn'. */
>> +#if defined(__clang__) || !QEMU_GNUC_PREREQ(4, 6)
>> +/* Some compilers wrongly smash all local variables after
>> + * siglongjmp. There were bug reports for gcc 4.5.0 and
clang.
>> + * Reload essential local variables here for those
compilers.
>> + * gcc 4.7 would complain about this code (-Wclobbered). */
>>  cpu = current_cpu;
>>  env = cpu->env_ptr;
>>  #if !(defined(CONFIG_USER_ONLY) && \
>>(defined(TARGET_M68K) || defined(TARGET_PPC) ||
defined(TARGET_S390X)))
>>  cc = CPU_GET_CLASS(cpu);
>>  #endif
>> +#endif /* __clang__ or old gcc */
>>  }
>>  } /* for(;;) */
>> 
>>
>
> Are all clang versions affected? Then this looks reasonable.
>
> Jan

Ping?

As cpu-exec.c has no explicit maintainer, I'd add this patch to my next
pull request, if nobody minds, but I'd appreciate more comments or a
Reviewed-by of course.

Stefan

Re: [Qemu-devel] [PATCH] configure: Enable pie for powerpc and arm Linux

[Andreas Färber]

Am 04.11.2013 22:16, schrieb Paolo Bonzini:
> Il 04/11/2013 21:51, Richard Henderson ha scritto:
  if test "$pie" = ""; then
case "$cpu-$targetos" in
 -i386-Linux|x86_64-Linux|x32-Linux|i386-OpenBSD|x86_64-OpenBSD)
 +
 i386-Linux|x86_64-Linux|x32-Linux|ppc*-Linux|arm*-Linux|aarch64*-Linux|i386-OpenBSD|x86_64-OpenBSD)
>> I'd much prefer that we have a blacklist than a whitelist for this.
>> Honestly, most ELF systems can support PIE, and we have very few
>> non-ELF systems to support.
> 
> Since the test is followed by a compile test, we probably do not even
> need the whitelist.

I remember reading a report here that someone ran into a link issue with
PIE on x86 at build time (check went okay) and was able to resolve it
via --disable-pie. Unfortunately I couldn't locate the post - do you
remember what that was about? Was that some BSD rather than Linux maybe?

It's probably a good idea to still allow overriding it, whether we
white- or blacklist or trust a compile test.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 1/2] pc: add etc/e820 fw_cfg file

[Andrea Arcangeli]

Hi,

On Mon, Nov 04, 2013 at 01:17:10PM +0100, Gerd Hoffmann wrote:
> Unlike the existing FW_CFG_E820_TABLE entry which carries reservations
> only the new etc/e820 file also has entries for RAM.

Acked, it looks the best the way to go if the objective is to keep
backwards compatibility with older seabios protocol.

I have to trust you on why we need to stay backwards compatible at all
times and why we can't commit an updated bios.bin before a new seabios
stable release happened. Otherwise we could have just fixed
FW_CFG_E820_TABLE breaking backwards compatibility without introducing
a partially overlapping fw_cfg.

About the file, I wonder what happens if too many people starts to use
files and we'll run out of FW_CFG_FILE_SLOTS at runtime (assert(index
< FW_CFG_FILE_SLOTS);). To me seeing the list of all fw_cfg IDs in a
header file to define all possible paravirt APIs seabios need to know
about, looked not so bad, but then grepping for fw_cfg_add_file is
equivalent. The main issue is that if we use files from now, it would
be nicer not to limit those to FW_CFG_FILE_SLOTS but to allocate them
a bit more dynamically without asserts but this is offtopic (I just
happened to read how files are created to review this patch).

Probably one patch could be added to
s/FW_CFG_E820_TABLE/FW_CFG_E820_TABLE_OLD/, otherwise if somebody read
fw_cfg.h, it won't be apparent that the grepping shouldn't stop there
to reach the real e820 map.

Thanks!
Andrea

Re: [Qemu-devel] [PATCH] configure: Enable pie for powerpc and arm Linux

[Andreas Färber]

Am 04.11.2013 13:19, schrieb Dinar Valeev:
> From: Dinar Valeev 
> 
> This patch enables pie for PowerPC and ARM architectures
> 
> Signed-off-by: Dinar Valeev 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 91372f9..0130e7e 100755
> --- a/configure
> +++ b/configure
> @@ -1297,7 +1297,7 @@ fi
>  
>  if test "$pie" = ""; then
>case "$cpu-$targetos" in
> -i386-Linux|x86_64-Linux|x32-Linux|i386-OpenBSD|x86_64-OpenBSD)
> +
> i386-Linux|x86_64-Linux|x32-Linux|ppc*-Linux|arm*-Linux|aarch64*-Linux|i386-OpenBSD|x86_64-OpenBSD)
>;;
>  *)
>pie="no"

For the benefit of the list, we have been using the ppc part of this
patch for the openSUSE ppc/ppc64 builds (some helper would otherwise
fail to link), and for our arm/aarch64 builds we've been using
--enable-pie to skip the above test. So those are known to work for us.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] USB Passthrough not working for Windows 7 guest

[Jan Kiszka]

On 2013-11-05 17:01, Frederich, Jens wrote:
> Hi all,
> 
> we're currently evaluating different RTOS systems (Windows CE, Intime, RTX, 
> etc.).
> One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all
> works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one 
> QEMU bug
> breaks my measurement setup and evaluation.
> 
> I've some usb devices for the Windows 7 guest. I configure them as USB 
> passthrough.
> The devices appears in the device manager of Windows 7, but with
> "Error code 10": device cannot start". The Windows driver fails on USB set 
> configuration.
> The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL 
> fails with
> invalid parameter.
> 
> driver log:
> 0009  0.65470564  vnCDrvUsbControlRequestSetConfiguration, 
> WdfUsbTargetDeviceSelectConfig single interface failed 0xc00d  
> 0010  0.65472370  vnCDrvUsbIFPrepareHardwareState, 
> vnCDrvUsbControlRequestSetConfiguration failed: 0xc00d 
> 0011  0.65473646  vnCDrvDevConPrepareHardware, 
> vnCDrvUsbIFPrepareHardwareState failed 0xc00d  
> 0012  0.65474838  vnCDrvEvtDevicePrepareHardware, 
> vnCDrvDevConPrepareHardware failed 0xc001   
> 0013  0.6547
> 
> This bug breaks my latency measurement setup and Linux RT is out of the 
> evaluationg
> race. Windows CE should not win :-), it there anyway workaround or hack to 
> fix the issue?

Workaround: Pass-through one of the (typically) many USB host
controllers to the Windows guest (vfio or classic pci-assign). I did
this back then when *HCI emulation was still pretty immature.

But USB device pass-through should also work. Do you happen to pass a
USB 2.0 device via an emulated UHCI? Or are you already using the EHCI
emulation? In the latter case, activating USB tracing (see also
qemu/docs/tracing.txt) and posting the results here may help analysing
the issue.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH] configure: detect endian via compile test

[Peter Maydell]

On 26 September 2013 21:54, Paolo Bonzini  wrote:
> Il 26/09/2013 05:22, Doug Goldstein ha scritto:
>> On Mon, Sep 9, 2013 at 2:30 PM, Stefan Weil  wrote:
>>> Am 28.08.2013 10:21, schrieb James Hogan:
 On 1 July 2013 04:30, Mike Frysinger  wrote:
> This avoids needing to execute a program and keeping an (incomplete)
> list when cross-compiling. Signed-off-by: Mike Frysinger
> 
 This fixes mipsel cross compiling. I also checked it detected a mips
 (be) compiler as big endian. Tested-by: James Hogan
  [mips] Can somebody please apply this. Maybe
 for stable too? Cheers James
>>>
>>> Ping? Aurelien, Anthony, who wants to commit this patch?
>>> Richard already reviewed it.
>>>
>>> See also http://patchwork.ozlabs.org/patch/268687/ for
>>> another configure patch waiting for a commit.
>>>
>>> Regards,
>>> Stefan
>>>
>>>
>>
>> Ping on getting this into master (and then over to stable).
>>
>
> Thanks Doug.  Anthony, Aurelien, can you commit it?

Ping -- looks like this one got dropped :-(

-- PMM

[Qemu-devel] [PATCH v2 3/9] bswap.h: Remove le16_to_cpupu()

[Peter Maydell]

Replace the legacy le16_to_cpupu() with lduw_le_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 hw/acpi/core.c   |3 +--
 include/hw/pci/pci.h |2 +-
 include/qemu/bswap.h |5 -
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 246ade3..58308a3 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -170,8 +170,7 @@ static void acpi_table_install(const char unsigned *blob, 
size_t bloblen,
 }
 
 /* increase number of tables */
-stw_le_p(acpi_tables,
- le16_to_cpupu((uint16_t *)acpi_tables) + 1u);
+stw_le_p(acpi_tables, lduw_le_p(acpi_tables) + 1u);
 
 /* Update the header fields. The strings need not be NUL-terminated. */
 changed_fields = 0;
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 9cd0642..9c961a9 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -427,7 +427,7 @@ pci_set_word(uint8_t *config, uint16_t val)
 static inline uint16_t
 pci_get_word(const uint8_t *config)
 {
-return le16_to_cpupu((const uint16_t *)config);
+return lduw_le_p(config);
 }
 
 static inline void
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index d0c4ff0..1c50002 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -412,11 +412,6 @@ static inline void stfq_be_p(void *ptr, float64 v)
 
 /* Legacy unaligned versions.  Note that we never had a complete set.  */
 
-static inline uint16_t le16_to_cpupu(const uint16_t *p)
-{
-return lduw_le_p(p);
-}
-
 static inline uint32_t le32_to_cpupu(const uint32_t *p)
 {
 return ldl_le_p(p);
-- 
1.7.9.5

[Qemu-devel] [PATCH v2 5/9] bswap.h: Remove be32_to_cpupu()

[Peter Maydell]

Replace the legacy be32_to_cpupu() with ldl_be_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 hw/net/e1000.c   |2 +-
 include/qemu/bswap.h |5 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index ec8ecd7..a5fb8fc 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -603,7 +603,7 @@ xmit_seg(E1000State *s)
 if (tp->tcp) {
 sofar = frames * tp->mss;
 cpu_to_be32wu((uint32_t *)(tp->data+css+4),// seq
-be32_to_cpupu((uint32_t *)(tp->data+css+4))+sofar);
+ldl_be_p(tp->data+css+4)+sofar);
 if (tp->paylen - sofar > tp->mss)
 tp->data[css + 13] &= ~9;  // PSH, FIN
 } else // UDP
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index ac5b2e0..9524931 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -412,11 +412,6 @@ static inline void stfq_be_p(void *ptr, float64 v)
 
 /* Legacy unaligned versions.  Note that we never had a complete set.  */
 
-static inline uint32_t be32_to_cpupu(const uint32_t *p)
-{
-return ldl_be_p(p);
-}
-
 static inline void cpu_to_be16wu(uint16_t *p, uint16_t v)
 {
 stw_be_p(p, v);
-- 
1.7.9.5

[Qemu-devel] [PATCH v2 8/9] bswap.h: Remove cpu_to_be64wu()

[Peter Maydell]

Replace the legacy cpu_to_be64wu() with stq_be_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 block/qcow2-cluster.c |2 +-
 include/qemu/bswap.h  |5 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 0348b97..f242244 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -101,7 +101,7 @@ int qcow2_grow_l1_table(BlockDriverState *bs, uint64_t 
min_size,
 /* set new table */
 BLKDBG_EVENT(bs->file, BLKDBG_L1_GROW_ACTIVATE_TABLE);
 cpu_to_be32w((uint32_t*)data, new_l1_size);
-cpu_to_be64wu((uint64_t*)(data + 4), new_l1_table_offset);
+stq_be_p(data + 4, new_l1_table_offset);
 ret = bdrv_pwrite_sync(bs->file, offsetof(QCowHeader, l1_size), 
data,sizeof(data));
 if (ret < 0) {
 goto fail;
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index b95cc73..4cbd6e7 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -412,11 +412,6 @@ static inline void stfq_be_p(void *ptr, float64 v)
 
 /* Legacy unaligned versions.  Note that we never had a complete set.  */
 
-static inline void cpu_to_be64wu(uint64_t *p, uint64_t v)
-{
-stq_be_p(p, v);
-}
-
 static inline void cpu_to_32wu(uint32_t *p, uint32_t v)
 {
 stl_p(p, v);
-- 
1.7.9.5

Re: [Qemu-devel] [PATCH v2] docs/memory.txt: Clarify and expand priority/overlap documentation

[Peter Maydell]

On 15 October 2013 15:42, Peter Maydell  wrote:
> The documentation of how overlapping memory regions behave and how
> the priority system works was rather brief, and confusion about
> priorities seems to be quite common for developers trying to understand
> how the memory region system works, so expand and clarify it.
> This includes a worked example with overlaps, documentation of the
> behaviour when an overlapped container has "holes", and mention
> that it's valid for a region to have both MMIO callbacks and
> subregions (and how this interacts with priorities when it does).
>
> Signed-off-by: Peter Maydell 

Ping!

thanks
-- PMM

[Qemu-devel] [PULL v3 52/57] qom: Fix pointer to int property helpers' documentation

[Andreas Färber]

From: "Michael S. Tsirkin" 

Relocate to alongside the other object_property_add_* helpers while at it.

Signed-off-by: Andreas Färber 
---
 include/qom/object.h | 73 +---
 1 file changed, 52 insertions(+), 21 deletions(-)

diff --git a/include/qom/object.h b/include/qom/object.h
index d02172a..a275db2 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -795,27 +795,6 @@ void object_property_add(Object *obj, const char *name, 
const char *type,
 void object_property_del(Object *obj, const char *name, Error **errp);
 
 /**
- * object_property_add_uint8_ptr:
- * object_property_add_uint16_ptr:
- * object_property_add_uint32_ptr:
- * object_property_add_uint64_ptr:
- * @obj: the object to add a property to
- * @name: the name of the property
- * @v: pointer to value
- *
- * Add an integer property in memory.  This function will add a
- * property of the appropriate type.
- */
-void object_property_add_uint8_ptr(Object *obj, const char *name,
-   const uint8_t *v, Error **errp);
-void object_property_add_uint16_ptr(Object *obj, const char *name,
-const uint16_t *v, Error **errp);
-void object_property_add_uint32_ptr(Object *obj, const char *name,
-const uint32_t *v, Error **errp);
-void object_property_add_uint64_ptr(Object *obj, const char *name,
-const uint64_t *v, Error **Errp);
-
-/**
  * object_property_find:
  * @obj: the object
  * @name: the name of the property
@@ -1134,6 +1113,58 @@ void object_property_add_bool(Object *obj, const char 
*name,
   Error **errp);
 
 /**
+ * object_property_add_uint8_ptr:
+ * @obj: the object to add a property to
+ * @name: the name of the property
+ * @v: pointer to value
+ * @errp: if an error occurs, a pointer to an area to store the error
+ *
+ * Add an integer property in memory.  This function will add a
+ * property of type 'uint8'.
+ */
+void object_property_add_uint8_ptr(Object *obj, const char *name,
+   const uint8_t *v, Error **errp);
+
+/**
+ * object_property_add_uint16_ptr:
+ * @obj: the object to add a property to
+ * @name: the name of the property
+ * @v: pointer to value
+ * @errp: if an error occurs, a pointer to an area to store the error
+ *
+ * Add an integer property in memory.  This function will add a
+ * property of type 'uint16'.
+ */
+void object_property_add_uint16_ptr(Object *obj, const char *name,
+const uint16_t *v, Error **errp);
+
+/**
+ * object_property_add_uint32_ptr:
+ * @obj: the object to add a property to
+ * @name: the name of the property
+ * @v: pointer to value
+ * @errp: if an error occurs, a pointer to an area to store the error
+ *
+ * Add an integer property in memory.  This function will add a
+ * property of type 'uint32'.
+ */
+void object_property_add_uint32_ptr(Object *obj, const char *name,
+const uint32_t *v, Error **errp);
+
+/**
+ * object_property_add_uint64_ptr:
+ * @obj: the object to add a property to
+ * @name: the name of the property
+ * @v: pointer to value
+ * @errp: if an error occurs, a pointer to an area to store the error
+ *
+ * Add an integer property in memory.  This function will add a
+ * property of type 'uint64'.
+ */
+void object_property_add_uint64_ptr(Object *obj, const char *name,
+const uint64_t *v, Error **Errp);
+
+/**
  * object_child_foreach:
  * @obj: the object whose children will be navigated
  * @fn: the iterator function to be called
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH v2] docs/memory.txt: Clarify and expand priority/overlap documentation

[Peter Maydell]

On 5 November 2013 17:16, Michael S. Tsirkin  wrote:
> On Tue, Nov 05, 2013 at 05:11:09PM +, Peter Maydell wrote:
>> On 15 October 2013 15:42, Peter Maydell  wrote:
>> > The documentation of how overlapping memory regions behave and how
>> > the priority system works was rather brief, and confusion about
>> > priorities seems to be quite common for developers trying to understand
>> > how the memory region system works, so expand and clarify it.
>> > This includes a worked example with overlaps, documentation of the
>> > behaviour when an overlapped container has "holes", and mention
>> > that it's valid for a region to have both MMIO callbacks and
>> > subregions (and how this interacts with priorities when it does).
>> >
>> > Signed-off-by: Peter Maydell 
>>
>> Ping!

> Want to fix minor typos that Eric found?

I disagreed with them, see my reply to him.

-- PMM

Re: [Qemu-devel] [PATCH v2] docs/memory.txt: Clarify and expand priority/overlap documentation

[Michael S. Tsirkin]

On Tue, Nov 05, 2013 at 05:11:09PM +, Peter Maydell wrote:
> On 15 October 2013 15:42, Peter Maydell  wrote:
> > The documentation of how overlapping memory regions behave and how
> > the priority system works was rather brief, and confusion about
> > priorities seems to be quite common for developers trying to understand
> > how the memory region system works, so expand and clarify it.
> > This includes a worked example with overlaps, documentation of the
> > behaviour when an overlapped container has "holes", and mention
> > that it's valid for a region to have both MMIO callbacks and
> > subregions (and how this interacts with priorities when it does).
> >
> > Signed-off-by: Peter Maydell 
> 
> Ping!
> 
> thanks
> -- PMM

Want to fix minor typos that Eric found?

Re: [Qemu-devel] [PATCH for 1.7] pc: disable pci-info

[Igor Mammedov]

On Tue, 29 Oct 2013 15:35:07 +0100
Igor Mammedov  wrote:

> The BIOS that we ship in 1.7 does not use pci info
> from host and so far isn't going to use it.
> Taking in account problems it caused see 9604f70fdf and
> to avoid future incompatibility issues, it's safest to
> disable that interface by default for all machine types
> including 1.7 as it was never exposed/used by guest.
> And properly remove/cleanup it during 1.8 development cycle.

ping,
we want it for 1.7 to avoid compatibility issues.

Re: [Qemu-devel] [PATCH for 1.7] pc: disable pci-info

[Michael S. Tsirkin]

On Tue, Nov 05, 2013 at 06:11:16PM +0100, Igor Mammedov wrote:
> On Tue, 29 Oct 2013 15:35:07 +0100
> Igor Mammedov  wrote:
> 
> > The BIOS that we ship in 1.7 does not use pci info
> > from host and so far isn't going to use it.
> > Taking in account problems it caused see 9604f70fdf and
> > to avoid future incompatibility issues, it's safest to
> > disable that interface by default for all machine types
> > including 1.7 as it was never exposed/used by guest.
> > And properly remove/cleanup it during 1.8 development cycle.
> 
> ping,
> we want it for 1.7 to avoid compatibility issues.

Yes we do.

Can you rebase and resubmit please?

[Qemu-devel] [PULL v3 00/58] QOM devices patch queue 2013-11-05

[Andreas Färber]

Hello Anthony,

This is my updated QOM devices patch queue. Please pull.

v3 is rebased on mst's pull so that make check passes
and it contains new Reviewed-bys by Eric.

Thanks,
Andreas

Cc: Anthony Liguori 

Cc: Peter Maydell 
Cc: Mian M. Hamayun 
Cc: Paolo Bonzini 
Cc: Michael S. Tsirkin 
Cc: Stefan Hajnoczi 
Cc: Eric Blake 

The following changes since commit a126050a103c924b03388a9a64ce9af8c96b0969:

  Merge remote-tracking branch 'kwolf/tags/for-anthony' into staging 
(2013-10-31 17:02:26 +0100)

are available in the git repository at:


  git://github.com/afaerber/qemu-cpu.git tags/qom-devices-for-anthony

for you to fetch changes up to 80bbaee66ac38bcb5fe5a6f285e20457afcc8bec:

  pcmcia/pxa2xx: QOM'ify PXA2xxPCMCIAState (2013-11-05 18:06:52 +0100)


QOM device refactorings

* QTest coverage for all machines
* QOM realize for Milkymist UART
* QOM realize for ARM MPCore
* device_add bug fixes and cleanups
* QOM for PCMCIA/MicroDrive (last legacy IDE device)


Andreas Färber (50):
  Merge tag 'for_anthony' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu
  mips_mipssim: Silence BIOS loading warning for qtest
  puv3: Turn puv3_load_kernel() into a no-op for qtest without -kernel
  mainstone: Don't enforce use of -pflash for qtest
  gumstix: Don't enforce use of -pflash for qtest
  z2: Don't enforce use of -pflash for qtest
  palm: Don't enforce loading ROM or kernel for qtest
  omap_sx1: Don't enforce use of kernel or flash for qtest
  exynos4_boards: Silence lack of -smp 2 warning for qtest
  armv7m: Don't enforce use of kernel for qtest
  axis_dev88: Don't enforce use of kernel for qtest
  mcf5208: Don't enforce use of kernel for qtest
  an5206: Don't enforce use of kernel for qtest
  milkymist: Suppress -kernel/-bios/-drive error for qtest
  shix: Drop debug output
  shix: Don't require firmware presence for qtest
  leon3: Don't enforce use of -bios with qtest
  qtest: Prepare QOM machine tests
  a9mpcore: Split off instance_init
  arm_gic: Extract headers hw/intc/arm_gic{,_common}.h
  a9mpcore: Embed GICState
  a9scu: QOM cleanups
  a9mpcore: Embed A9SCUState
  arm_mptimer: Convert to QOM realize
  a9mpcore: Embed ARMMPTimerState
  a9mpcore: Convert to QOM realize
  a9mpcore: Prepare for QOM embedding
  a15mpcore: Split off instance_init
  a15mpcore: Embed GICState
  a15mpcore: Convert to QOM realize
  a15mpcore: Prepare for QOM embedding
  a9scu: Build only once
  arm11mpcore: Fix typo in MemoryRegion name
  arm11mpcore: Drop unused fields
  arm11mpcore: Create container MemoryRegion in instance_init
  arm11mpcore: Split off SCU device
  arm11mpcore: Convert ARM11MPCorePriveState to QOM realize
  realview_gic: Convert to QOM realize
  realview_gic: Prepare for QOM embedding
  arm11mpcore: Convert mpcore_rirq_state to QOM realize
  arm11mpcore: Prepare for QOM embedding
  arm11mpcore: Split off RealView MPCore
  qdev-monitor: Clean up qdev_device_add() variable naming
  qdev-monitor: Avoid qdev as variable name
  qdev-monitor: Inline qdev_init() for device_add
  pxa: Fix typo "dettach"
  pcmcia: QOM'ify PCMCIACardState and MicroDriveState
  microdrive: Coding Style cleanups
  ide: Drop ide_init2_with_non_qdev_drives()
  pcmcia/pxa2xx: QOM'ify PXA2xxPCMCIAState

Antony Pavlov (1):
  milkymist-uart: Use Device::realize instead of SysBusDevice::init

Igor Mammedov (1):
  qdev-monitor: Fix crash when device_add is called with abstract driver

Michael S. Tsirkin (3):
  pc: disable acpi info for isapc and old pc machine
  exec: limit system memory size
  qom: Fix pointer to int property helpers' documentation

Paolo Bonzini (1):
  vl: allow "cont" from panicked state

Stefan Hajnoczi (2):
  qdev-monitor: Unref device when device_add fails
  qdev: Drop misleading qdev_free() function

 default-configs/arm-softmmu.mak  |   1 +
 exec.c   |   7 +-
 gdbstub.c|   3 -
 hw/Makefile.objs |   1 +
 hw/acpi/piix4.c  |   2 +-
 hw/arm/armv7m.c  |  25 +--
 hw/arm/exynos4_boards.c  |   3 +-
 hw/arm/gumstix.c |  11 +-
 hw/arm/mainstone.c   |   5 +-
 hw/arm/omap_sx1.c|   3 +-
 hw/arm/palm.c|   3 +-
 hw/arm/z2.c  |   5 +-
 hw/block/tc58128.c   |  10 +-
 hw/char/milkymist-uart.c |  24 +--
 hw/core/qdev.c   |  12 +-
 hw/cpu/Makefile.objs |   1 +
 hw/c

[Qemu-devel] [PATCH v2 2/9] bswap.h: Remove cpu_to_le32wu()

[Peter Maydell]

Replace the legacy cpu_to_le32wu() with stl_le_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 hw/net/ne2000.c  |2 +-
 include/hw/pci/pci.h |2 +-
 include/qemu/bswap.h |5 -
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/hw/net/ne2000.c b/hw/net/ne2000.c
index a94cf74..9ba3d1e 100644
--- a/hw/net/ne2000.c
+++ b/hw/net/ne2000.c
@@ -467,7 +467,7 @@ static inline void ne2000_mem_writel(NE2000State *s, 
uint32_t addr,
 addr &= ~1; /* XXX: check exact behaviour if not even */
 if (addr < 32 ||
 (addr >= NE2000_PMEM_START && addr < NE2000_MEM_SIZE)) {
-cpu_to_le32wu((uint32_t *)(s->mem + addr), val);
+stl_le_p(s->mem + addr, val);
 }
 }
 
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index fae2170..9cd0642 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -433,7 +433,7 @@ pci_get_word(const uint8_t *config)
 static inline void
 pci_set_long(uint8_t *config, uint32_t val)
 {
-cpu_to_le32wu((uint32_t *)config, val);
+stl_le_p(config, val);
 }
 
 static inline uint32_t
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index ada1084..d0c4ff0 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -412,11 +412,6 @@ static inline void stfq_be_p(void *ptr, float64 v)
 
 /* Legacy unaligned versions.  Note that we never had a complete set.  */
 
-static inline void cpu_to_le32wu(uint32_t *p, uint32_t v)
-{
-stl_le_p(p, v);
-}
-
 static inline uint16_t le16_to_cpupu(const uint16_t *p)
 {
 return lduw_le_p(p);
-- 
1.7.9.5

Re: [Qemu-devel] [PATCH] tests: fix 64-bit int literals for 32-bit hosts

[Laszlo Ersek]

On 11/05/13 17:42, Stefan Hajnoczi wrote:
> On 32-bit hosts:
> 
>   CCtests/test-opts-visitor.o
> tests/test-opts-visitor.c: In function 'test_value':
> tests/test-opts-visitor.c:128: warning: integer constant is too large for 
> 'long' type
>   CCtests/test-bitops.o
> tests/test-bitops.c:34: warning: integer constant is too large for 'long' type
> tests/test-bitops.c:35: warning: integer constant is too large for 'long' type
> tests/test-bitops.c:35: warning: integer constant is too large for 'long' type
>   CCtests/endianness-test.o
> tests/endianness-test.c:47: warning: integer constant is too large for 'long' 
> type
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  tests/endianness-test.c   | 3 ++-
>  tests/test-bitops.c   | 4 ++--
>  tests/test-opts-visitor.c | 2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)

Blame it on still using gnu89 instead of c99 (or gnu99 if must be).

Laszlo

Re: [Qemu-devel] [PATCH] tests: fix 64-bit int literals for 32-bit hosts

[Eric Blake]

On 11/05/2013 09:42 AM, Stefan Hajnoczi wrote:
> On 32-bit hosts:
> 
>   CCtests/test-opts-visitor.o
> tests/test-opts-visitor.c: In function 'test_value':
> tests/test-opts-visitor.c:128: warning: integer constant is too large for 
> 'long' type
>   CCtests/test-bitops.o
> tests/test-bitops.c:34: warning: integer constant is too large for 'long' type
> tests/test-bitops.c:35: warning: integer constant is too large for 'long' type
> tests/test-bitops.c:35: warning: integer constant is too large for 'long' type
>   CCtests/endianness-test.o
> tests/endianness-test.c:47: warning: integer constant is too large for 'long' 
> type
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  tests/endianness-test.c   | 3 ++-
>  tests/test-bitops.c   | 4 ++--
>  tests/test-opts-visitor.c | 2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 00/20] Add an IPMI device to QEMU

[Corey Minyard]

On 11/05/2013 10:09 AM, Andreas Färber wrote:
> Hi,
>
> Am 05.11.2013 14:56, schrieb Michael S. Tsirkin:
>> On Wed, May 29, 2013 at 05:07:56PM -0500, miny...@acm.org wrote:
>>> I have finally gotten some time to work on this, this series of
>>> patches adds an IPMI interface to qemu.  The changes are roughly:
>>>
>>> patches 01-05 - Add the capability to have a chardev reconnect if
>>> the connections fails.  This way, if using an external BMC, qemu
>>> will detect the failure and periodically attempt to reconnect.
>>> This also adds ways for the device code to get an event on a
>>> disconnect and connect so it can handle it properly.  This is
>>> probably useful for things besides IPMI.  There are also a few
>>> small bugfixes in this.
>>>
>>> patches 06-14 - Add the IPMI device itself, with an ISA interface
>>> for now (PCI and others can also be added easily).
>>>
>>> patches 15-18 - Add a way to dynamically add content to the ACPI
>>> tables, and add the capability to add the IPMI information to the
>>> table.
>>>
>>> Patches 19-20 - Add a way to dynamically add content to the SMBIOS
>>> tables, and add an IPMI entry to the table.
>>>
>> I was pointed at these patches as an example of useful
>> functionality that's out of qemu merely for lack of review
>> resources. I'd like to help.
>>
>> Now that we have code to generate ACPI tables
>> directly in qemu, this series can be rebased on top of
>> that, with no need for new FW CFG entries or bios changes.
>>
>> If you have the time, pls Cc me on patches and I'll try to
>> help shepherd them upstream.
> Me too, I have IPMI on my radar for 1.8/2.0.
>
> Our use case would be using IPMI tools to boot/reboot/shutdown a guest
> and to access its serial console as done for the physical hosts; we had
> discussed in the past where to locate such a TCP server component,
> whether in QEMU or libvirt - am I interpreting correctly that patch 11
> is preparing an interface to have that as external process now? Or is it
> hidden somewhere in patch 10 or is this unimplemented in this version?

Patch 11 does that, it gives an external interface.  The OpenIPMI
library has a
simulator that will plug in to this interface to provide BMC functions
and an
IPMI LAN interface.

You can do the boot/reboot/shutdown via the normal mechanisms with the
external simulator.  The internal simulator doesn't have an IPMI LAN
interface,
though, so you would need the external interface.

I also have not provided a serial over LAN interface through this
interface.  If
that's what you are looking for, more work would need to be done.

Thanks,

-corey

>
> Also, some of the IPMI acronyms in the commit messages (KCS, BT, ...)
> could use some explanation in the next version. ;)
>
> Regards,
> Andreas
>

[Qemu-devel] [PATCH v5] net: Adding netmap network backend

[Vincenzo Maffione]

This patch adds support for a network backend based on netmap.
netmap is a framework for high speed packet I/O. You can use it
to build extremely fast traffic generators, monitors, software
switches or network middleboxes. Its companion software switch
VALE lets you interconnect virtual machines.
netmap and VALE are implemented as a non-intrusive kernel module,
support NICs from multiple vendors, are part of standard FreeBSD
distributions and available in source format for Linux too.

To compile QEMU with netmap support, use the following configure
options:
./configure [...] --enable-netmap --extra-cflags=-I/path/to/netmap/sys
where "/path/to/netmap" contains the netmap source code, available at
http://info.iet.unipi.it/~luigi/netmap/

The same webpage contains more information about the netmap project
(together with papers and presentations).

Signed-off-by: Vincenzo Maffione 
---
The VALE system interface will check the "ifname" string, inside the
netmap kernel module. From this point of view, QEMU is not required
to parse this string (if you are okay with this approach).

The vlan argument was just an error.

 configure |  32 
 hmp-commands.hx   |   4 +-
 net/Makefile.objs |   1 +
 net/clients.h |   5 +
 net/net.c |   6 +
 net/netmap.c  | 427 ++
 qapi-schema.json  |  23 ++-
 qemu-options.hx   |   8 +
 8 files changed, 503 insertions(+), 3 deletions(-)
 create mode 100644 net/netmap.c

diff --git a/configure b/configure
index 91372f9..cfeef21 100755
--- a/configure
+++ b/configure
@@ -156,6 +156,7 @@ curl=""
 curses=""
 docs=""
 fdt=""
+netmap="no"
 pixman=""
 sdl=""
 virtfs=""
@@ -473,6 +474,7 @@ FreeBSD)
   audio_possible_drivers="oss sdl esd pa"
   # needed for kinfo_getvmmap(3) in libutil.h
   LIBS="-lutil $LIBS"
+  netmap=""  # enable netmap autodetect
 ;;
 DragonFly)
   bsd="yes"
@@ -780,6 +782,10 @@ for opt do
   ;;
   --enable-vde) vde="yes"
   ;;
+  --disable-netmap) netmap="no"
+  ;;
+  --enable-netmap) netmap="yes"
+  ;;
   --disable-xen) xen="no"
   ;;
   --enable-xen) xen="yes"
@@ -1161,6 +1167,8 @@ echo "  --disable-uuid   disable uuid support"
 echo "  --enable-uuidenable uuid support"
 echo "  --disable-vdedisable support for vde network"
 echo "  --enable-vde enable support for vde network"
+echo "  --disable-netmap disable support for netmap network"
+echo "  --enable-netmap  enable support for netmap network"
 echo "  --disable-linux-aio  disable Linux AIO support"
 echo "  --enable-linux-aio   enable Linux AIO support"
 echo "  --disable-cap-ng disable libcap-ng support"
@@ -2065,6 +2073,26 @@ EOF
 fi
 
 ##
+# netmap headers probe
+if test "$netmap" != "no" ; then
+  cat > $TMPC << EOF
+#include 
+#include 
+#include 
+#include 
+int main(void) { return 0; }
+EOF
+  if compile_prog "" "" ; then
+netmap=yes
+  else
+if test "$netmap" = "yes" ; then
+  feature_not_found "netmap"
+fi
+netmap=no
+  fi
+fi
+
+##
 # libcap-ng library probe
 if test "$cap_ng" != "no" ; then
   cap_libs="-lcap-ng"
@@ -3720,6 +3748,7 @@ echo "uname -r  $uname_release"
 echo "GUEST_BASE$guest_base"
 echo "PIE   $pie"
 echo "vde support   $vde"
+echo "netmap support$netmap"
 echo "Linux AIO support $linux_aio"
 echo "ATTR/XATTR support $attr"
 echo "Install blobs $blobs"
@@ -3858,6 +3887,9 @@ fi
 if test "$vde" = "yes" ; then
   echo "CONFIG_VDE=y" >> $config_host_mak
 fi
+if test "$netmap" = "yes" ; then
+  echo "CONFIG_NETMAP=y" >> $config_host_mak
+fi
 if test "$cap_ng" = "yes" ; then
   echo "CONFIG_LIBCAP=y" >> $config_host_mak
 fi
diff --git a/hmp-commands.hx b/hmp-commands.hx
index caae5ad..ebe8e78 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1190,7 +1190,7 @@ ETEXI
 {
 .name   = "host_net_add",
 .args_type  = "device:s,opts:s?",
-.params = "tap|user|socket|vde|dump [options]",
+.params = "tap|user|socket|vde|netmap|dump [options]",
 .help   = "add host VLAN client",
 .mhandler.cmd = net_host_device_add,
 },
@@ -1218,7 +1218,7 @@ ETEXI
 {
 .name   = "netdev_add",
 .args_type  = "netdev:O",
-.params = "[user|tap|socket|hubport],id=str[,prop=value][,...]",
+.params = 
"[user|tap|socket|hubport|netmap],id=str[,prop=value][,...]",
 .help   = "add host network device",
 .mhandler.cmd = hmp_netdev_add,
 },
diff --git a/net/Makefile.objs b/net/Makefile.objs
index 4854a14..c25fe69 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -11,3 +11,4 @@ common-obj-$(CONFIG_AIX) += tap-aix.o
 common-obj-$(CONFIG_HAIKU) += tap-haiku.o
 common-obj-$(CONFIG_SLIRP) += slirp.o
 common-obj-$(CONFIG_VDE) += vde.o
+common-obj-$(CONFIG_NETMAP) += netmap.o
diff --git a/net/cl

[Qemu-devel] [PATCH v2 9/9] bswap.h: Remove cpu_to_32wu()

[Peter Maydell]

Replace the legacy cpu_to_32wu() with stl_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 hw/display/vga_template.h |   14 --
 include/qemu/bswap.h  |7 ---
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/hw/display/vga_template.h b/hw/display/vga_template.h
index f6f6a01..6cfae56 100644
--- a/hw/display/vga_template.h
+++ b/hw/display/vga_template.h
@@ -113,20 +113,22 @@ static void glue(vga_draw_glyph9_, DEPTH)(uint8_t *d, int 
linesize,
 do {
 font_data = font_ptr[0];
 #if BPP == 1
-cpu_to_32wu((uint32_t *)d, (dmask16[(font_data >> 4)] & xorcol) ^ 
bgcol);
+stl_p((uint32_t *)d, (dmask16[(font_data >> 4)] & xorcol) ^ bgcol);
 v = (dmask16[(font_data >> 0) & 0xf] & xorcol) ^ bgcol;
-cpu_to_32wu(((uint32_t *)d)+1, v);
+stl_p(((uint32_t *)d)+1, v);
 if (dup9)
 ((uint8_t *)d)[8] = v >> (24 * (1 - BIG));
 else
 ((uint8_t *)d)[8] = bgcol;
 
 #elif BPP == 2
-cpu_to_32wu(((uint32_t *)d)+0, (dmask4[(font_data >> 6)] & xorcol) ^ 
bgcol);
-cpu_to_32wu(((uint32_t *)d)+1, (dmask4[(font_data >> 4) & 3] & xorcol) 
^ bgcol);
-cpu_to_32wu(((uint32_t *)d)+2, (dmask4[(font_data >> 2) & 3] & xorcol) 
^ bgcol);
+stl_p(((uint32_t *)d)+0, (dmask4[(font_data >> 6)] & xorcol) ^ bgcol);
+stl_p(((uint32_t *)d)+1,
+  (dmask4[(font_data >> 4) & 3] & xorcol) ^ bgcol);
+stl_p(((uint32_t *)d)+2,
+  (dmask4[(font_data >> 2) & 3] & xorcol) ^ bgcol);
 v = (dmask4[(font_data >> 0) & 3] & xorcol) ^ bgcol;
-cpu_to_32wu(((uint32_t *)d)+3, v);
+stl_p(((uint32_t *)d)+3, v);
 if (dup9)
 ((uint16_t *)d)[8] = v >> (16 * (1 - BIG));
 else
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index 4cbd6e7..437b8e0 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -410,13 +410,6 @@ static inline void stfq_be_p(void *ptr, float64 v)
 stq_be_p(ptr, u.ll);
 }
 
-/* Legacy unaligned versions.  Note that we never had a complete set.  */
-
-static inline void cpu_to_32wu(uint32_t *p, uint32_t v)
-{
-stl_p(p, v);
-}
-
 static inline unsigned long leul_to_cpu(unsigned long v)
 {
 /* In order to break an include loop between here and
-- 
1.7.9.5

[Qemu-devel] [PATCH v2 4/9] bswap.h: Remove le32_to_cpupu()

[Peter Maydell]

Replace the legacy le32_to_cpupu() with ldl_le_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 hw/net/ne2000.c  |2 +-
 include/hw/pci/pci.h |2 +-
 include/qemu/bswap.h |5 -
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/hw/net/ne2000.c b/hw/net/ne2000.c
index 9ba3d1e..4c32e9e 100644
--- a/hw/net/ne2000.c
+++ b/hw/net/ne2000.c
@@ -497,7 +497,7 @@ static inline uint32_t ne2000_mem_readl(NE2000State *s, 
uint32_t addr)
 addr &= ~1; /* XXX: check exact behaviour if not even */
 if (addr < 32 ||
 (addr >= NE2000_PMEM_START && addr < NE2000_MEM_SIZE)) {
-return le32_to_cpupu((uint32_t *)(s->mem + addr));
+return ldl_le_p(s->mem + addr);
 } else {
 return 0x;
 }
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 9c961a9..b783e68 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -439,7 +439,7 @@ pci_set_long(uint8_t *config, uint32_t val)
 static inline uint32_t
 pci_get_long(const uint8_t *config)
 {
-return le32_to_cpupu((const uint32_t *)config);
+return ldl_le_p(config);
 }
 
 static inline void
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index 1c50002..ac5b2e0 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -412,11 +412,6 @@ static inline void stfq_be_p(void *ptr, float64 v)
 
 /* Legacy unaligned versions.  Note that we never had a complete set.  */
 
-static inline uint32_t le32_to_cpupu(const uint32_t *p)
-{
-return ldl_le_p(p);
-}
-
 static inline uint32_t be32_to_cpupu(const uint32_t *p)
 {
 return ldl_be_p(p);
-- 
1.7.9.5

[Qemu-devel] [PATCH] tests: fix 64-bit int literals for 32-bit hosts

[Stefan Hajnoczi]

On 32-bit hosts:

  CCtests/test-opts-visitor.o
tests/test-opts-visitor.c: In function 'test_value':
tests/test-opts-visitor.c:128: warning: integer constant is too large for 
'long' type
  CCtests/test-bitops.o
tests/test-bitops.c:34: warning: integer constant is too large for 'long' type
tests/test-bitops.c:35: warning: integer constant is too large for 'long' type
tests/test-bitops.c:35: warning: integer constant is too large for 'long' type
  CCtests/endianness-test.o
tests/endianness-test.c:47: warning: integer constant is too large for 'long' 
type

Signed-off-by: Stefan Hajnoczi 
---
 tests/endianness-test.c   | 3 ++-
 tests/test-bitops.c   | 4 ++--
 tests/test-opts-visitor.c | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tests/endianness-test.c b/tests/endianness-test.c
index feb32a8..8719c09 100644
--- a/tests/endianness-test.c
+++ b/tests/endianness-test.c
@@ -44,7 +44,8 @@ static const TestCase test_cases[] = {
 { "ppc", "prep", 0x8000, .bswap = true },
 { "ppc", "bamboo", 0xe800, .bswap = true, .superio = "i82378" },
 { "ppc64", "mac99", 0xf200, .bswap = true, .superio = "i82378" },
-{ "ppc64", "pseries", 0x1008000, .bswap = true, .superio = "i82378" },
+{ "ppc64", "pseries", 0x1008000ULL,
+  .bswap = true, .superio = "i82378" },
 { "sh4", "r2d", 0xfe24, .superio = "i82378" },
 { "sh4eb", "r2d", 0xfe24, .bswap = true, .superio = "i82378" },
 { "sparc64", "sun4u", 0x1fe0200LL, .bswap = true },
diff --git a/tests/test-bitops.c b/tests/test-bitops.c
index 4e713e4..8238eb5 100644
--- a/tests/test-bitops.c
+++ b/tests/test-bitops.c
@@ -31,8 +31,8 @@ static const S32Test test_s32_data[] = {
 };
 
 static const S64Test test_s64_data[] = {
-{ 0x8459826734967223, 60, 4, -8 },
-{ 0x8459826734967223, 0, 64, 0x8459826734967223 },
+{ 0x8459826734967223ULL, 60, 4, -8 },
+{ 0x8459826734967223ULL, 0, 64, 0x8459826734967223LL },
 };
 
 static void test_sextract32(void)
diff --git a/tests/test-opts-visitor.c b/tests/test-opts-visitor.c
index 9f902b5..ebeee5d 100644
--- a/tests/test-opts-visitor.c
+++ b/tests/test-opts-visitor.c
@@ -125,7 +125,7 @@ test_value(OptsVisitorFixture *f, gconstpointer test_data)
 g_assert((magic & bitval) == 0);
 magic |= bitval;
 }
-g_assert(magic == 0xBADC0FFEE0DDF00D);
+g_assert(magic == 0xBADC0FFEE0DDF00DULL);
 
 magic = 0;
 for (u16 = f->userdef->u16; u16 != NULL; u16 = u16->next) {
-- 
1.8.3.1

[Qemu-devel] [Bug 685096] Re: USB Passthrough not working for Windows 7 guest

[Jens Frederich]

All devices work on other hypervisors like VMware Workstation etc...

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/685096

Title:
  USB Passthrough not working for Windows 7 guest

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  USB Passthrough from host to guest is not working for a 32-bit Windows
  7 guest, while it works perfectly for a 32-bit Windows XP guest.

  The device appears in the device manager of Windows 7, but with "Error
  code 10: device cannot start". I have tried this with numerous USB
  thumbdrives and a USB wireless NIC, all with the same result. The
  device name and functionality is recognized, so at least some USB
  negotiation is taking place.

  I am trying this with the latest git-pull of QEMU-KVM.

  The command line to launch qemu-kvm for win7 is:
  sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 
-smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice 
tablet -usbdevice host:0781:5150

  The command line to launch qemu-kvm for winxp is:
  sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 
-smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet 
-usbdevice host:0781:5150

  Any help is appreciated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/685096/+subscriptions

[Qemu-devel] [PATCH v2 7/9] bswap.h: Remove cpu_to_be32wu()

[Peter Maydell]

Replace the legacy cpu_to_be32wu() with stl_be_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 hw/block/cdrom.c |6 +++---
 hw/net/e1000.c   |3 +--
 hw/pci/pcie_aer.c|4 ++--
 include/qemu/bswap.h |5 -
 4 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/hw/block/cdrom.c b/hw/block/cdrom.c
index 5c69f34..4e1019c 100644
--- a/hw/block/cdrom.c
+++ b/hw/block/cdrom.c
@@ -59,7 +59,7 @@ int cdrom_read_toc(int nb_sectors, uint8_t *buf, int msf, int 
start_track)
 q += 3;
 } else {
 /* sector 0 */
-cpu_to_be32wu((uint32_t *)q, 0);
+stl_be_p(q, 0);
 q += 4;
 }
 }
@@ -73,7 +73,7 @@ int cdrom_read_toc(int nb_sectors, uint8_t *buf, int msf, int 
start_track)
 lba_to_msf(q, nb_sectors);
 q += 3;
 } else {
-cpu_to_be32wu((uint32_t *)q, nb_sectors);
+stl_be_p(q, nb_sectors);
 q += 4;
 }
 len = q - buf;
@@ -127,7 +127,7 @@ int cdrom_read_toc_raw(int nb_sectors, uint8_t *buf, int 
msf, int session_num)
 lba_to_msf(q, nb_sectors);
 q += 3;
 } else {
-cpu_to_be32wu((uint32_t *)q, nb_sectors);
+stl_be_p(q, nb_sectors);
 q += 4;
 }
 
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 34ac625..8387443 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -599,8 +599,7 @@ xmit_seg(E1000State *s)
 DBGOUT(TXSUM, "tcp %d tucss %d len %d\n", tp->tcp, css, len);
 if (tp->tcp) {
 sofar = frames * tp->mss;
-cpu_to_be32wu((uint32_t *)(tp->data+css+4),// seq
-ldl_be_p(tp->data+css+4)+sofar);
+stl_be_p(tp->data+css+4, ldl_be_p(tp->data+css+4)+sofar); /* seq */
 if (tp->paylen - sofar > tp->mss)
 tp->data[css + 13] &= ~9;  // PSH, FIN
 } else // UDP
diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index 32aa0c6..991502e 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -425,7 +425,7 @@ static void pcie_aer_update_log(PCIDevice *dev, const 
PCIEAERErr *err)
 /* 7.10.8 Header Log Register */
 uint8_t *header_log =
 aer_cap + PCI_ERR_HEADER_LOG + i * sizeof err->header[0];
-cpu_to_be32wu((uint32_t*)header_log, err->header[i]);
+stl_be_p(header_log, err->header[i]);
 }
 } else {
 assert(!(err->flags & PCIE_AER_ERR_TLP_PREFIX_PRESENT));
@@ -439,7 +439,7 @@ static void pcie_aer_update_log(PCIDevice *dev, const 
PCIEAERErr *err)
 /* 7.10.12 tlp prefix log register */
 uint8_t *prefix_log =
 aer_cap + PCI_ERR_TLP_PREFIX_LOG + i * sizeof err->prefix[0];
-cpu_to_be32wu((uint32_t*)prefix_log, err->prefix[i]);
+stl_be_p(prefix_log, err->prefix[i]);
 }
 errcap |= PCI_ERR_CAP_TLP;
 } else {
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index 3bb6b71..b95cc73 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -412,11 +412,6 @@ static inline void stfq_be_p(void *ptr, float64 v)
 
 /* Legacy unaligned versions.  Note that we never had a complete set.  */
 
-static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
-{
-stl_be_p(p, v);
-}
-
 static inline void cpu_to_be64wu(uint64_t *p, uint64_t v)
 {
 stq_be_p(p, v);
-- 
1.7.9.5

[Qemu-devel] [PATCH v2 0/9] Remove legacy unaligned bswap functions

[Peter Maydell]

This is a simple resend of a patchset which has been
on the list reviewed but unapplied for nine weeks, since
it's probably fallen out of Anthony's patches cache.


The bswap.h header includes a set of "legacy unaligned functions"
that (since commit c732a52d3 at the beginning of this year) are
just wrappers for underlying {ld,st} functions. The legacy
functions aren't used in many places, so just replace all their
uses with uses of the new-style {ld,st} functions; this lets us
remove the legacy wrappers altogether.

Since we know the {ld,st}* routines are definitely functions,
we can in the process remove some casts which were left over
from when the legacy unaligned functions were previously macros.

The patchset is divided up by function being removed, rather
than by which device/subsystem is being fixed; I think this way
round is easier to review since you only have to keep one
substitution in your head when reading a patch.

Peter Maydell (9):
  bswap.h: Remove cpu_to_le16wu()
  bswap.h: Remove cpu_to_le32wu()
  bswap.h: Remove le16_to_cpupu()
  bswap.h: Remove le32_to_cpupu()
  bswap.h: Remove be32_to_cpupu()
  bswap.h: Remove cpu_to_be16wu()
  bswap.h: Remove cpu_to_be32wu()
  bswap.h: Remove cpu_to_be64wu()
  bswap.h: Remove cpu_to_32wu()

 block/qcow2-cluster.c |2 +-
 hw/acpi/core.c|3 +--
 hw/block/cdrom.c  |   10 +-
 hw/display/vga_template.h |   14 --
 hw/ide/atapi.c|   16 +++
 hw/net/e1000.c|   22 +
 hw/net/ne2000.c   |4 ++--
 hw/pci/pcie_aer.c |4 ++--
 include/hw/pci/pci.h  |8 
 include/qemu/bswap.h  |   47 -
 10 files changed, 40 insertions(+), 90 deletions(-)

-- 
1.7.9.5

[Qemu-devel] [PATCH v2 1/9] bswap.h: Remove cpu_to_le16wu()

[Peter Maydell]

Replace the legacy cpu_to_le16wu() with stw_le_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 hw/acpi/core.c   |4 ++--
 include/hw/pci/pci.h |2 +-
 include/qemu/bswap.h |5 -
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index d8dff5b..246ade3 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -170,8 +170,8 @@ static void acpi_table_install(const char unsigned *blob, 
size_t bloblen,
 }
 
 /* increase number of tables */
-cpu_to_le16wu((uint16_t *)acpi_tables,
-  le16_to_cpupu((uint16_t *)acpi_tables) + 1u);
+stw_le_p(acpi_tables,
+ le16_to_cpupu((uint16_t *)acpi_tables) + 1u);
 
 /* Update the header fields. The strings need not be NUL-terminated. */
 changed_fields = 0;
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 37ffa53..fae2170 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -421,7 +421,7 @@ pci_get_byte(const uint8_t *config)
 static inline void
 pci_set_word(uint8_t *config, uint16_t val)
 {
-cpu_to_le16wu((uint16_t *)config, val);
+stw_le_p(config, val);
 }
 
 static inline uint16_t
diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h
index 14a5f65..ada1084 100644
--- a/include/qemu/bswap.h
+++ b/include/qemu/bswap.h
@@ -412,11 +412,6 @@ static inline void stfq_be_p(void *ptr, float64 v)
 
 /* Legacy unaligned versions.  Note that we never had a complete set.  */
 
-static inline void cpu_to_le16wu(uint16_t *p, uint16_t v)
-{
-stw_le_p(p, v);
-}
-
 static inline void cpu_to_le32wu(uint32_t *p, uint32_t v)
 {
 stl_le_p(p, v);
-- 
1.7.9.5

[Qemu-devel] [Bug 685096] Re: USB Passthrough not working for Windows 7 guest

[Jens Frederich]

Hi Serge,

for your information. I sent a mail to the devel mailing list. See
below.

I've tried to passthrough special Vector automotive usb in house devices.
Look here: http://vector.com/vi_vn1600_en.html.

What do you mean with "what commands you've tried"?

I've tried three QEMU versions:

1. Ubuntu 13.04 64-bit prebuild qemu-kvm package (qemu 1.4.0)
2. Ubuntu 13.10 64-bit prebuild qemu-kvm package (qemu 1.5.0)
3. Hand builded QEMU 1.6.1 with standard configure call
$ ./configure --prefix=/opt/kvm && make -j

Next, I want to build qemu from git?

I use virt-manager or virsh to start/stop my guest. The QEMU command
line is:

qemu-system-x86_64 -machine accel=kvm:tcg -name VRTP1_win -S -M pc-
i440fx-1.4 -cpu SandyBridge -m 3072 -smp 2,sockets=1,cores=2,threads=1
-uuid 8ee5add7-f1a9-d697-9c18-2c1b4967c00e -no-user-config -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/VRTP1_win.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
-no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
-device ahci,id=ahci0,bus=pci.0,addr=0x6 -drive
file=/var/lib/libvirt/images/VN8912_Development_0.9.2.bin,if=none,id
=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-
sata0-0-0,id=sata0-0-0,bootindex=1 -netdev
tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-
pci,netdev=hostnet0,id=net0,mac=52:54:00:71:f5:45,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device isa-
serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc
127.0.0.1:0 -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-
host,hostbus=3,hostaddr=18,id=hostdev0 -device virtio-balloon-
pci,id=balloon0,bus=pci.0,addr=0x5


Mail to devel list:

Hi all,

we're currently evaluating different RTOS systems (Windows CE, Intime, RTX, 
etc.).
One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all
works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one QEMU 
bug
breaks my measurement setup and evaluation.

I've some usb devices for the Windows 7 guest. I configure them as USB 
passthrough.
The devices appears in the device manager of Windows 7, but with
"Error code 10": device cannot start". The Windows driver fails on USB set 
configuration.
The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL 
fails with
invalid parameter.

driver log:
0009  0.65470564  vnCDrvUsbControlRequestSetConfiguration, 
WdfUsbTargetDeviceSelectConfig single interface failed 0xc00d  
0010  0.65472370  vnCDrvUsbIFPrepareHardwareState, 
vnCDrvUsbControlRequestSetConfiguration failed: 0xc00d 
0011  0.65473646  vnCDrvDevConPrepareHardware, 
vnCDrvUsbIFPrepareHardwareState failed 0xc00d  
0012  0.65474838  vnCDrvEvtDevicePrepareHardware, 
vnCDrvDevConPrepareHardware failed 0xc001 
0013  0.6547

This bug breaks my latency measurement setup and Linux RT is out of the 
evaluationg
race. Windows CE should not win :-), it there anyway workaround or hack to fix 
the issue?

My setup:

Ubuntu 64-bit
Windows 7 Embedded Guest
Linux Kernel: 3.10.10-rt7
QEMU: 1.4.0, 1.6.1

thanks,
Jens

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/685096

Title:
  USB Passthrough not working for Windows 7 guest

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  USB Passthrough from host to guest is not working for a 32-bit Windows
  7 guest, while it works perfectly for a 32-bit Windows XP guest.

  The device appears in the device manager of Windows 7, but with "Error
  code 10: device cannot start". I have tried this with numerous USB
  thumbdrives and a USB wireless NIC, all with the same result. The
  device name and functionality is recognized, so at least some USB
  negotiation is taking place.

  I am trying this with the latest git-pull of QEMU-KVM.

  The command line to launch qemu-kvm for win7 is:
  sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 
-smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice 
tablet -usbdevice host:0781:5150

  The command line to launch qemu-kvm for winxp is:
  sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 
-smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet 
-usbdevice host:0781:5150

  Any help is appreciated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/685096/+subscriptions

[Qemu-devel] [PATCH v2 6/9] bswap.h: Remove cpu_to_be16wu()

[Peter Maydell]

Replace the legacy cpu_to_be16wu() with stw_be_p().

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
---
 hw/block/cdrom.c |4 ++--
 hw/ide/atapi.c   |   16 
 hw/net/e1000.c   |   19 ---
 include/qemu/bswap.h |5 -
 4 files changed, 18 insertions(+), 26 deletions(-)

diff --git a/hw/block/cdrom.c b/hw/block/cdrom.c
index 38469fa..5c69f34 100644
--- a/hw/block/cdrom.c
+++ b/hw/block/cdrom.c
@@ -77,7 +77,7 @@ int cdrom_read_toc(int nb_sectors, uint8_t *buf, int msf, int 
start_track)
 q += 4;
 }
 len = q - buf;
-cpu_to_be16wu((uint16_t *)buf, len - 2);
+stw_be_p(buf, len - 2);
 return len;
 }
 
@@ -150,6 +150,6 @@ int cdrom_read_toc_raw(int nb_sectors, uint8_t *buf, int 
msf, int session_num)
 }
 
 len = q - buf;
-cpu_to_be16wu((uint16_t *)buf, len - 2);
+stw_be_p(buf, len - 2);
 return len;
 }
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 05e60b1..f7d2009 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -437,7 +437,7 @@ static int ide_dvd_read_structure(IDEState *s, int format,
 cpu_to_ube32(buf + 16, total_sectors - 1); /* l0 end sector */
 
 /* Size of buffer, not including 2 byte size field */
-cpu_to_be16wu((uint16_t *)buf, 2048 + 2);
+stw_be_p(buf, 2048 + 2);
 
 /* 2k data + 4 byte header */
 return (2048 + 4);
@@ -448,7 +448,7 @@ static int ide_dvd_read_structure(IDEState *s, int format,
 buf[5] = 0; /* no region restrictions */
 
 /* Size of buffer, not including 2 byte size field */
-cpu_to_be16wu((uint16_t *)buf, 4 + 2);
+stw_be_p(buf, 4 + 2);
 
 /* 4 byte header + 4 byte data */
 return (4 + 4);
@@ -458,7 +458,7 @@ static int ide_dvd_read_structure(IDEState *s, int format,
 
 case 0x04: /* DVD disc manufacturing information */
 /* Size of buffer, not including 2 byte size field */
-cpu_to_be16wu((uint16_t *)buf, 2048 + 2);
+stw_be_p(buf, 2048 + 2);
 
 /* 2k data + 4 byte header */
 return (2048 + 4);
@@ -471,22 +471,22 @@ static int ide_dvd_read_structure(IDEState *s, int format,
 
 buf[4] = 0x00; /* Physical format */
 buf[5] = 0x40; /* Not writable, is readable */
-cpu_to_be16wu((uint16_t *)(buf + 6), 2048 + 4);
+stw_be_p(buf + 6, 2048 + 4);
 
 buf[8] = 0x01; /* Copyright info */
 buf[9] = 0x40; /* Not writable, is readable */
-cpu_to_be16wu((uint16_t *)(buf + 10), 4 + 4);
+stw_be_p(buf + 10, 4 + 4);
 
 buf[12] = 0x03; /* BCA info */
 buf[13] = 0x40; /* Not writable, is readable */
-cpu_to_be16wu((uint16_t *)(buf + 14), 188 + 4);
+stw_be_p(buf + 14, 188 + 4);
 
 buf[16] = 0x04; /* Manufacturing info */
 buf[17] = 0x40; /* Not writable, is readable */
-cpu_to_be16wu((uint16_t *)(buf + 18), 2048 + 4);
+stw_be_p(buf + 18, 2048 + 4);
 
 /* Size of buffer, not including 2 byte size field */
-cpu_to_be16wu((uint16_t *)buf, 16 + 2);
+stw_be_p(buf, 16 + 2);
 
 /* data written + 4 byte header */
 return (16 + 4);
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index a5fb8fc..34ac625 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -528,8 +528,7 @@ putsum(uint8_t *data, uint32_t n, uint32_t sloc, uint32_t 
css, uint32_t cse)
 n = cse + 1;
 if (sloc < n-1) {
 sum = net_checksum_add(n-css, data+css);
-cpu_to_be16wu((uint16_t *)(data + sloc),
-  net_checksum_finish(sum));
+stw_be_p(data + sloc, net_checksum_finish(sum));
 }
 }
 
@@ -590,13 +589,11 @@ xmit_seg(E1000State *s)
 DBGOUT(TXSUM, "frames %d size %d ipcss %d\n",
frames, tp->size, css);
 if (tp->ip) {  // IPv4
-cpu_to_be16wu((uint16_t *)(tp->data+css+2),
-  tp->size - css);
-cpu_to_be16wu((uint16_t *)(tp->data+css+4),
+stw_be_p(tp->data+css+2, tp->size - css);
+stw_be_p(tp->data+css+4,
   be16_to_cpup((uint16_t *)(tp->data+css+4))+frames);
 } else // IPv6
-cpu_to_be16wu((uint16_t *)(tp->data+css+4),
-  tp->size - css);
+stw_be_p(tp->data+css+4, tp->size - css);
 css = tp->tucss;
 len = tp->size - css;
 DBGOUT(TXSUM, "tcp %d tucss %d len %d\n", tp->tcp, css, len);
@@ -607,14 +604,14 @@ xmit_seg(E1000State *s)
 if (tp->paylen - sofar > tp->mss)
 tp->data[css + 13] &= ~9;  // PSH, FIN
 } else // UDP
-cpu_to_be16wu((uint16_t *)(tp->data+css+4), len);
+stw_be_p(tp->d

Re: [Qemu-devel] [libvirt] [PATCH RFC] blockdev: copy legacy and common opts to qemu_drive_opts

[Amos Kong]

Hi Kevin,

On Mon, Nov 04, 2013 at 12:27:10PM +0100, Kevin Wolf wrote:
> Am 04.11.2013 um 08:01 hat Amos Kong geschrieben:
> > Currently we have three QemuOptsList (qemu_common_drive_opts,
> > qemu_legacy_drive_opts, and qemu_drive_opts), only qemu_drive_opts
> > is added to vm_config_groups[].
> > 
> > We query commandline options by checking information in
> > vm_config_groups[], so we can only get a NULL parameter list now.
> > 
> > This patch copied desc items of qemu_legacy_drive_opts and
> > qemu_common_drive_opts to qemu_drive_opts.
> > 
> > Signed-off-by: Amos Kong 
> 
> This breaks driver-specific options because they aren't (and cannot be)
> listed in the QemuOptsList.
> 
> For example:
> 
> $ x86_64-softmmu/qemu-system-x86_64 -drive file.driver=nbd,file.host=localhost
> qemu-system-x86_64: -drive file.driver=nbd,file.host=localhost: Invalid 
> parameter 'file.driver'
> 
> query-command-line-options isn't an appropriate API to query the -drive
> capabilities in the blockdev-add world. You really want to have
> introspection for that.
> 
> For compatibility, we might want to at least expose part of the provided
> options there. In this case you should modify the monitor command to
> access the local QemuOptsLists of drive_init() and blockdev_init() for
> option="drive".

It's to access the local QemuOptsLists of drive_init() and
blockdev_init() for option="drive".

I saw there are two repeat items ("copy-on-read", "read-only")
I will merge the two desc lists together, remove the repeat items,
and output once.

Attached my draft patch, I can use it to compile qemu binary, but
touched following error, any note?


[amos@amosk qemu]$ make
  CCutil/qemu-config.o
  ARlibqemuutil.a
  LINK  qemu-ga
  LINK  qemu-nbd
  LINK  qemu-img
  LINK  qemu-io
libqemuutil.a(qemu-config.o): In function `qmp_query_command_line_options':
/home/devel/qemu/util/qemu-config.c:141: undefined reference to 
`qemu_legacy_drive_opts'
/home/devel/qemu/util/qemu-config.c:142: undefined reference to 
`qemu_common_drive_opts'
/home/devel/qemu/util/qemu-config.c:144: undefined reference to 
`qemu_drive_opts'
collect2: error: ld returned 1 exit status
make: *** [qemu-nbd] Error 1
make: *** Waiting for unfinished jobs
libqemuutil.a(qemu-config.o): In function `qmp_query_command_line_options':
/home/devel/qemu/util/qemu-config.c:141: undefined reference to 
`qemu_legacy_drive_opts'
/home/devel/qemu/util/qemu-config.c:142: undefined reference to 
`qemu_common_drive_opts'
/home/devel/qemu/util/qemu-config.c:144: undefined reference to 
`qemu_drive_opts'
collect2: error: ld returned 1 exit status
make: *** [qemu-img] Error 1
libqemuutil.a(qemu-config.o): In function `qmp_query_command_line_options':
/home/devel/qemu/util/qemu-config.c:141: undefined reference to 
`qemu_legacy_drive_opts'
/home/devel/qemu/util/qemu-config.c:142: undefined reference to 
`qemu_common_drive_opts'
/home/devel/qemu/util/qemu-config.c:144: undefined reference to 
`qemu_drive_opts'
collect2: error: ld returned 1 exit status
make: *** [qemu-io] Error 1
  LINK  x86_64-softmmu/qemu-system-x86_64


-- 
Amos.
>From c95a05bde835481e861853c4365c768be26335e1 Mon Sep 17 00:00:00 2001
From: Amos Kong 
Date: Tue, 5 Nov 2013 17:59:13 +0800
Subject: [PATCH] qmp: access the local QemuOptsLists for drive option

Currently we have three QemuOptsList (qemu_common_drive_opts,
qemu_legacy_drive_opts, and qemu_drive_opts), only qemu_drive_opts
is added to vm_config_groups[].

This patch changes query-command-line-options to access three list,
and merge the result together.

Signed-off-by: Amos Kong 
---
 blockdev.c  |  1 -
 include/sysemu/sysemu.h |  2 ++
 util/qemu-config.c  | 61 -
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index b260477..f09f991 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -47,7 +47,6 @@
 #include "sysemu/arch_init.h"
 
 static QTAILQ_HEAD(drivelist, DriveInfo) drives = 
QTAILQ_HEAD_INITIALIZER(drives);
-extern QemuOptsList qemu_common_drive_opts;
 
 static const char *const if_name[IF_COUNT] = {
 [IF_NONE] = "none",
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index cd5791e..495dae8 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -193,6 +193,8 @@ QemuOpts *qemu_get_machine_opts(void);
 
 bool usb_enabled(bool default_usb);
 
+extern QemuOptsList qemu_legacy_drive_opts;
+extern QemuOptsList qemu_common_drive_opts;
 extern QemuOptsList qemu_drive_opts;
 extern QemuOptsList qemu_chardev_opts;
 extern QemuOptsList qemu_device_opts;
diff --git a/util/qemu-config.c b/util/qemu-config.c
index a59568d..573c5ad 100644
--- a/util/qemu-config.c
+++ b/util/qemu-config.c
@@ -6,6 +6,7 @@
 #include "hw/qdev.h"
 #include "qapi/error.h"
 #include "qmp-commands.h"
+#include "sysemu/sysemu.h"
 
 static QemuOptsList *vm_config_groups[32];
 
@@ -77,19 +78,77 @@ static Command

Re: [Qemu-devel] [PATCH] integrator/cp: add support for REFCNTregisterr

[Peter Maydell]

On 5 November 2013 16:18, Alex Bennée  wrote:
> I suspect it would be worth updating the QEMU wiki pages and building a
> simple vexpress image (or showing simple steps for the Linaro vexpress
> builds).

It's painful because of GPL issues if you just provide the
binary...

-- PMM

Re: [Qemu-devel] [PATCH] RFC: powerpc: add PVR compatibility check

[Alexander Graf]

On 05.11.2013, at 17:16, Andreas Färber  wrote:

> Am 05.11.2013 07:05, schrieb Alexander Graf:
>> 
>> 
>> Am 05.11.2013 um 05:00 schrieb Paul Mackerras :
>> 
>>> On Mon, Nov 04, 2013 at 10:05:58AM +0100, Alexander Graf wrote:
 
 Yeah, we really need to check that guest vpcu == host vcpu for HV KVM.
>>> 
>>> In general I agree, but the one difficulty I see is that a check for
>>> exact equality will interact badly with qemu's habit of picking a
>>> specific processor version when the user specifies something general
>>> like "POWER7".  So if the user does -cpu POWER7 on a machine with
>>> (for example) a POWER7 v2.1 processor, but qemu arbitrarily picks the
>>> PVR for POWER7 v2.3, then it will fail, which will be completely
>>> puzzling to the user -- "I asked for POWER7, and it is a POWER7,
>>> what's the problem??".
>>> 
>>> Maybe if the user asks for a non-specific processor type, and the
>>> host's PVR matches the request, then qemu should take the host's PVR
>>> rather than just picking some arbitrary processor version.
>> 
>> Yup.
> 
> But then it's no longer generally reproducible: "POWER7" won't be
> "POWER7" on another machine.
> 
> One thing I original did iirc was to hide the aliases from QMP. You can
> always do stupid things on the command line and then we can blame you,
> but if libvirt and upper layers don't offer "POWER7" to the end user
> then we don't need to worry about the average user misinterpreting its
> semantics.

We could also just be nice and error out with a sane error message:

  Your selected CPU POWER7_v10 is not compatible with the host's CPU POWER7_20
  with your currently selected KVM mode. Please use the latter or -cpu host.


Alex

Re: [Qemu-devel] [PATCH] integrator/cp: add support for REFCNTregisterr

[Alex Bennée]

peter.mayd...@linaro.org writes:

> On 5 November 2013 14:44, Jan Petrouš  wrote:
>> Hehe, duno, but when I started learning QEMU the Integrator devboard
>> looked for me the nice start-up point = very simple to understand
>> and only very basic, but still core, device list.
>
> QEMU's integrator model is really very minimally maintained.
> A lot of its code is still using out of date ways of doing
> things and hasn't been updated in years; my only test case
> for it is an ancient 2.6.17 kernel. vexpress is rather
> more maintained and I do at least occasionally test with
> new kernels.


I suspect it would be worth updating the QEMU wiki pages and building a
simple vexpress image (or showing simple steps for the Linaro vexpress
builds). I suspect Jan's choice was also influenced as mine by the fact
it's the test ARM image mentioned on the wiki page.

Of course the first time I ran it I found it had regressed also ;-)

-- 
Alex Bennée

Re: [Qemu-devel] [Bug 1248168] [NEW] MIPS, self-modifying code and uncached memory

[Antony Pavlov]

On Tue, 05 Nov 2013 12:47:13 -
Nikita Kanunnikov  wrote:

Could you please provide some additional information for error reproducing?
(qemu version, necessary binary files, qemu cmdline etc)

Par exemple I have tried to reproduce your error on qemu-1.6.1.

I use qemu-system-mips (so it's big-endian) and the "-M malta -m 256" options.

I have put your code starting at 0xa000 (kseg1 first address).

Here is a part of my gdb log:

=> 0xa390:   00 00 50 25movet2,zero
(gdb) stepi
=> 0xa394:   34 0b 00 02li  t3,0x2
(gdb) stepi
=> 0xa398:   01 4b 50 23subut2,t2,t3
(gdb) stepi
=> 0xa39c:   0b 3c 00 e9j   0xacf003a4
(gdb)

In fact there is no problem with 0xacf003a4 address. It is normal KSEG1 RAM 
address
on Malta with 256M RAM! May be it contains some rational code.

Could you describe step-by-step what you have done exactly to reproduce the 
error?

> Public bug reported:
> 
> Self-modifying code does not work properly in MIPS in uncached and
> unmapped kseg1 memory region.
> 
> For example, when running this code I get unexpected behavior:
> 
>0: e310b   0x390
>4: nop
>   ...
>  380: 00701f40mfc0ra,c0_epc
>  384: 0400e0bbswr zero,4(ra)
>  388: 1842eret
>  38c: nop
>  390: 2550movet2,zero
>  394: 02000b34li  t3,0x2
>  398: 23504b01subut2,t2,t3
>  39c: e9003c0bj   0xcf003a4
>  3a0: 0a004a21addit2,t2,10
>  3a4: 0010b   0x3a4
>  3a8: nop
>  3ac: nop
> 
>   I expect that swr instruction in line 384 would change `addi
> t2,t2,1`0 to `nop`
> This should work because no cache is used for this memory region.
> 
> ** Affects: qemu
>  Importance: Undecided
>  Status: New
> 
> -- 
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1248168
> 
> Title:
>   MIPS, self-modifying code and uncached memory
> 
> Status in QEMU:
>   New
> 
> Bug description:
>   Self-modifying code does not work properly in MIPS in uncached and
>   unmapped kseg1 memory region.
> 
>   For example, when running this code I get unexpected behavior:
> 
>  0:   e310b   0x390
>  4:   nop
>   ...
>380:   00701f40mfc0ra,c0_epc
>384:   0400e0bbswr zero,4(ra)
>388:   1842eret
>38c:   nop
>390:   2550movet2,zero
>394:   02000b34li  t3,0x2
>398:   23504b01subut2,t2,t3
>39c:   e9003c0bj   0xcf003a4
>3a0:   0a004a21addit2,t2,10
>3a4:   0010b   0x3a4
>3a8:   nop
>3ac:   nop
> 
> I expect that swr instruction in line 384 would change `addi  
> t2,t2,1`0 to `nop`
>   This should work because no cache is used for this memory region.
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1248168/+subscriptions
> 


-- 
-- 
Best regards,
  Antony Pavlov

Re: [Qemu-devel] [PATCH] RFC: powerpc: add PVR compatibility check

[Andreas Färber]

Am 05.11.2013 07:05, schrieb Alexander Graf:
> 
> 
> Am 05.11.2013 um 05:00 schrieb Paul Mackerras :
> 
>> On Mon, Nov 04, 2013 at 10:05:58AM +0100, Alexander Graf wrote:
>>>
>>> Yeah, we really need to check that guest vpcu == host vcpu for HV KVM.
>>
>> In general I agree, but the one difficulty I see is that a check for
>> exact equality will interact badly with qemu's habit of picking a
>> specific processor version when the user specifies something general
>> like "POWER7".  So if the user does -cpu POWER7 on a machine with
>> (for example) a POWER7 v2.1 processor, but qemu arbitrarily picks the
>> PVR for POWER7 v2.3, then it will fail, which will be completely
>> puzzling to the user -- "I asked for POWER7, and it is a POWER7,
>> what's the problem??".
>>
>> Maybe if the user asks for a non-specific processor type, and the
>> host's PVR matches the request, then qemu should take the host's PVR
>> rather than just picking some arbitrary processor version.
> 
> Yup.

But then it's no longer generally reproducible: "POWER7" won't be
"POWER7" on another machine.

One thing I original did iirc was to hide the aliases from QMP. You can
always do stupid things on the command line and then we can blame you,
but if libvirt and upper layers don't offer "POWER7" to the end user
then we don't need to worry about the average user misinterpreting its
semantics.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[Qemu-devel] [Bug 685096] Re: USB Passthrough not working for Windows 7 guest

[Serge Hallyn]

Hi Jens,

could you tell us exactly what you are trying to pass through, what
commands you've tried, and with what version of qemu (and, if hand-
built, which options were passed to configure).

1.5 came with a new passthrough implementation, but alongside the old.
So I wonder whether choosing the libusb based implementation would help.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/685096

Title:
  USB Passthrough not working for Windows 7 guest

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  USB Passthrough from host to guest is not working for a 32-bit Windows
  7 guest, while it works perfectly for a 32-bit Windows XP guest.

  The device appears in the device manager of Windows 7, but with "Error
  code 10: device cannot start". I have tried this with numerous USB
  thumbdrives and a USB wireless NIC, all with the same result. The
  device name and functionality is recognized, so at least some USB
  negotiation is taking place.

  I am trying this with the latest git-pull of QEMU-KVM.

  The command line to launch qemu-kvm for win7 is:
  sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 
-smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice 
tablet -usbdevice host:0781:5150

  The command line to launch qemu-kvm for winxp is:
  sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 
-smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet 
-usbdevice host:0781:5150

  Any help is appreciated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/685096/+subscriptions

Re: [Qemu-devel] [PATCH 00/20] Add an IPMI device to QEMU

[Andreas Färber]

Hi,

Am 05.11.2013 14:56, schrieb Michael S. Tsirkin:
> On Wed, May 29, 2013 at 05:07:56PM -0500, miny...@acm.org wrote:
>> I have finally gotten some time to work on this, this series of
>> patches adds an IPMI interface to qemu.  The changes are roughly:
>>
>> patches 01-05 - Add the capability to have a chardev reconnect if
>> the connections fails.  This way, if using an external BMC, qemu
>> will detect the failure and periodically attempt to reconnect.
>> This also adds ways for the device code to get an event on a
>> disconnect and connect so it can handle it properly.  This is
>> probably useful for things besides IPMI.  There are also a few
>> small bugfixes in this.
>>
>> patches 06-14 - Add the IPMI device itself, with an ISA interface
>> for now (PCI and others can also be added easily).
>>
>> patches 15-18 - Add a way to dynamically add content to the ACPI
>> tables, and add the capability to add the IPMI information to the
>> table.
>>
>> Patches 19-20 - Add a way to dynamically add content to the SMBIOS
>> tables, and add an IPMI entry to the table.
>>
> 
> I was pointed at these patches as an example of useful
> functionality that's out of qemu merely for lack of review
> resources. I'd like to help.
> 
> Now that we have code to generate ACPI tables
> directly in qemu, this series can be rebased on top of
> that, with no need for new FW CFG entries or bios changes.
> 
> If you have the time, pls Cc me on patches and I'll try to
> help shepherd them upstream.

Me too, I have IPMI on my radar for 1.8/2.0.

Our use case would be using IPMI tools to boot/reboot/shutdown a guest
and to access its serial console as done for the physical hosts; we had
discussed in the past where to locate such a TCP server component,
whether in QEMU or libvirt - am I interpreting correctly that patch 11
is preparing an interface to have that as external process now? Or is it
hidden somewhere in patch 10 or is this unimplemented in this version?

Also, some of the IPMI acronyms in the commit messages (KCS, BT, ...)
could use some explanation in the next version. ;)

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg