Re: [Qemu-devel] [PATCH v3 3/4] char: remove the right fd been watched in qemu_chr_fe_set_handlers()

[Marc-André Lureau]

Hi

- Original Message -
> We can call qemu_chr_fe_set_handlers() to add/remove fd been watched
> in 'context' which can be either default main context or other explicit
> context. But the original logic is not correct, we didn't remove
> the right fd because we call g_main_context_find_source_by_id(NULL, tag)
> which always try to find the Gsource from default context.
> 
> Fix it by passing the right context to g_main_context_find_source_by_id().
> 
> Cc: Paolo Bonzini 
> Cc: Marc-André Lureau 
> Signed-off-by: zhanghailiang 

Reviewed-by: Marc-André Lureau 

> ---
>  chardev/char-fd.c | 6 +++---
>  chardev/char-io.c | 8 
>  chardev/char-io.h | 2 +-
>  chardev/char-pty.c| 2 +-
>  chardev/char-socket.c | 4 ++--
>  chardev/char-udp.c| 6 +++---
>  chardev/char.c| 2 +-
>  7 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/chardev/char-fd.c b/chardev/char-fd.c
> index fb51ab4..548dd4c 100644
> --- a/chardev/char-fd.c
> +++ b/chardev/char-fd.c
> @@ -58,7 +58,7 @@ static gboolean fd_chr_read(QIOChannel *chan, GIOCondition
> cond, void *opaque)
>  ret = qio_channel_read(
>  chan, (gchar *)buf, len, NULL);
>  if (ret == 0) {
> -remove_fd_in_watch(chr);
> +remove_fd_in_watch(chr, NULL);
>  qemu_chr_be_event(chr, CHR_EVENT_CLOSED);
>  return FALSE;
>  }
> @@ -89,7 +89,7 @@ static void fd_chr_update_read_handler(Chardev *chr,
>  {
>  FDChardev *s = FD_CHARDEV(chr);
>  
> -remove_fd_in_watch(chr);
> +remove_fd_in_watch(chr, NULL);
>  if (s->ioc_in) {
>  chr->fd_in_tag = io_add_watch_poll(chr, s->ioc_in,
> fd_chr_read_poll,
> @@ -103,7 +103,7 @@ static void char_fd_finalize(Object *obj)
>  Chardev *chr = CHARDEV(obj);
>  FDChardev *s = FD_CHARDEV(obj);
>  
> -remove_fd_in_watch(chr);
> +remove_fd_in_watch(chr, NULL);
>  if (s->ioc_in) {
>  object_unref(OBJECT(s->ioc_in));
>  }
> diff --git a/chardev/char-io.c b/chardev/char-io.c
> index 7dfc3f2..b4bb094 100644
> --- a/chardev/char-io.c
> +++ b/chardev/char-io.c
> @@ -127,14 +127,14 @@ guint io_add_watch_poll(Chardev *chr,
>  return tag;
>  }
>  
> -static void io_remove_watch_poll(guint tag)
> +static void io_remove_watch_poll(guint tag, GMainContext *context)
>  {
>  GSource *source;
>  IOWatchPoll *iwp;
>  
>  g_return_if_fail(tag > 0);
>  
> -source = g_main_context_find_source_by_id(NULL, tag);
> +source = g_main_context_find_source_by_id(context, tag);
>  g_return_if_fail(source != NULL);
>  
>  iwp = io_watch_poll_from_source(source);
> @@ -146,10 +146,10 @@ static void io_remove_watch_poll(guint tag)
>  g_source_destroy(>parent);
>  }
>  
> -void remove_fd_in_watch(Chardev *chr)
> +void remove_fd_in_watch(Chardev *chr, GMainContext *context)
>  {
>  if (chr->fd_in_tag) {
> -io_remove_watch_poll(chr->fd_in_tag);
> +io_remove_watch_poll(chr->fd_in_tag, context);
>  chr->fd_in_tag = 0;
>  }
>  }
> diff --git a/chardev/char-io.h b/chardev/char-io.h
> index d7ae5f1..842be56 100644
> --- a/chardev/char-io.h
> +++ b/chardev/char-io.h
> @@ -36,7 +36,7 @@ guint io_add_watch_poll(Chardev *chr,
>  gpointer user_data,
>  GMainContext *context);
>  
> -void remove_fd_in_watch(Chardev *chr);
> +void remove_fd_in_watch(Chardev *chr, GMainContext *context);
>  
>  int io_channel_send(QIOChannel *ioc, const void *buf, size_t len);
>  
> diff --git a/chardev/char-pty.c b/chardev/char-pty.c
> index ecf2c7a..a6337be 100644
> --- a/chardev/char-pty.c
> +++ b/chardev/char-pty.c
> @@ -199,7 +199,7 @@ static void pty_chr_state(Chardev *chr, int connected)
>  g_source_remove(s->open_tag);
>  s->open_tag = 0;
>  }
> -remove_fd_in_watch(chr);
> +remove_fd_in_watch(chr, NULL);
>  s->connected = 0;
>  /* (re-)connect poll interval for idle guests: once per second.
>   * We check more frequently in case the guests sends data to
> diff --git a/chardev/char-socket.c b/chardev/char-socket.c
> index 865c527..d7e92e1 100644
> --- a/chardev/char-socket.c
> +++ b/chardev/char-socket.c
> @@ -328,7 +328,7 @@ static void tcp_chr_free_connection(Chardev *chr)
>  }
>  
>  tcp_set_msgfds(chr, NULL, 0);
> -remove_fd_in_watch(chr);
> +remove_fd_in_watch(chr, NULL);
>  object_unref(OBJECT(s->sioc));
>  s->sioc = NULL;
>  object_unref(OBJECT(s->ioc));
> @@ -498,7 +498,7 @@ static void tcp_chr_update_read_handler(Chardev *chr,
>  return;
>  }
>  
> -remove_fd_in_watch(chr);
> +remove_fd_in_watch(chr, NULL);
>  if (s->ioc) {
>  chr->fd_in_tag = io_add_watch_poll(chr, s->ioc,
> tcp_chr_read_poll,
> diff 

Re: [Qemu-devel] [PATCH] iotests: Fix another race in 030

[Fam Zheng]

On Thu, 02/16 17:00, John Snow wrote:
> We can't rely on a non-paused job to be present and running for us.
> Assume that if the job is not present that it completed already.
> 
> Signed-off-by: John Snow 
> ---
>  tests/qemu-iotests/030 | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
> index 54db54a..0d472d5 100755
> --- a/tests/qemu-iotests/030
> +++ b/tests/qemu-iotests/030
> @@ -547,11 +547,14 @@ class TestEIO(TestErrors):
>  while not completed:
>  for event in self.vm.get_qmp_events(wait=True):
>  if event['event'] == 'BLOCK_JOB_ERROR':
> +error = True
>  self.assert_qmp(event, 'data/device', 'drive0')
>  self.assert_qmp(event, 'data/operation', 'read')
>  result = self.vm.qmp('query-block-jobs')
> +if result == {'return': []}:
> +# Job finished too quickly
> +continue
>  self.assert_qmp(result, 'return[0]/paused', False)
> -error = True
>  elif event['event'] == 'BLOCK_JOB_COMPLETED':
>  self.assertTrue(error, 'job completed unexpectedly')
>  self.assert_qmp(event, 'data/type', 'stream')
> -- 
> 2.9.3
> 
> 

Looks fine.

Reviewed-by: Fam Zheng 

Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb descriptor

[Peter Xu]

On Fri, Feb 17, 2017 at 06:36:41AM +, Liu, Yi L wrote:
> > -Original Message-
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Friday, February 17, 2017 11:26 AM
> > To: Liu, Yi L 
> > Cc: Michael S. Tsirkin ; qemu-devel@nongnu.org; Peter
> > Maydell ; Eduardo Habkost
> > ; Jason Wang ; Paolo Bonzini
> > ; Richard Henderson ; Tian, Kevin
> > ; Lan, Tianyu 
> > Subject: Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
> > descriptor
> > 
> > On Thu, Feb 16, 2017 at 05:36:06AM +, Liu, Yi L wrote:
> > > > -Original Message-
> > > > From: Qemu-devel
> > > > [mailto:qemu-devel-bounces+yi.l.liu=intel@nongnu.org]
> > > > On Behalf Of Michael S. Tsirkin
> > > > Sent: Tuesday, January 10, 2017 1:40 PM
> > > > To: qemu-devel@nongnu.org
> > > > Cc: Peter Maydell ; Eduardo Habkost
> > > > ; Jason Wang ; Peter Xu
> > > > ; Paolo Bonzini ; Richard
> > > > Henderson 
> > > > Subject: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
> > > > descriptor
> > > >
> > > > From: Jason Wang 
> > > >
> > > > This patch enables device IOTLB support for intel iommu. The major
> > > > work is to implement QI device IOTLB descriptor processing and
> > > > notify the device through iommu notifier.
> > > >
> > > Hi Jason/Michael,
> > >
> > > Recently Peter Xu's patch also touched intel-iommu emulation. His
> > > patch shadows second-level page table by capturing iotlb flush from
> > > guest. It would result in page table updating in host. Does this patch
> > > also use the same map/umap API provided by VFIO? If it is, then I think it
> > would also update page table in host.
> > 
> > I haven't considered complex scenarios, but if simply we have a VM with one
> > vhost device and one vfio-pci device, imho that should not be a problem -
> > device iotlb is targeting SID rather than DOMAIN. So device iotlb 
> > invalidations
> > for vhost will be sent to vhost device only.
> 
> Peter, I think for assigned device, all guest iotlb flush should be 
> translated to
> be targeting device in the scope of host. Besides the scenario which has vhost
> and vfio-pci device at the same time, how about only having vfio-pci device
> and this device has ATS support. Then there should be device-iotlb flushing.
> With this patch and your patch, it would also introduce two flushing.

Hmm possibly. I'm still not quite familiar with ATS, but here what we
need to do may be that we forward these device-iotlb invalidations to
the hardware below, instead of sending UNMAP notifies, right?

> 
> > However, vhost may receive two invalidations here, but it won't matter much
> > since vhost is just flushing caches twice.
> 
> yeah, so far I didn’t see functional issue, may just reduce performance^_^
> 
> > > It looks to be
> > > a duplicate update. Pls refer to the following snapshot captured from
> > > section 6.5.2.5 of vtd spec.
> > >
> > > "Since translation requests from a device may be serviced by hardware
> > > from the IOTLB, software must always request IOTLB invalidation
> > > (iotlb_inv_dsc) before requesting corresponding Device-TLB
> > > (dev_tlb_inv_dsc) invalidation."
> > >
> > > Maybe for device-iotlb, we need a separate API which just pass down
> > > the invalidate info without updating page table. Any thoughts?
> > 
> > Now imho I slightly prefer just use the current UNMAP notifier type even for
> > device iotlb device. But, we may need to do one more check that we skip
> > sending general iotlb invalidations to ATS enabled devices like vhost, to 
> > avoid
> > duplicated cache flushing. From virt-svm side, do we have specific 
> > requirement
> > to introduce a new flag for it?
> I think it is a practical solution to do such a check to avoid duplicate 
> flushing.
> 
> For virt-svm, requirement is a little bit different since it's not shadowing 
> any guest
> page table. It needs to shadow invalidate operations. So virt-svm will not use
> MAP/UNMAP notifier. Instead, it may require notifier which passdown invalidate
> info and then submit invalidation directly.(no page table updating in host). 

Again, just want to know whether my above understanding is correct. If
so, instead of introducing a new flag, maybe we just need to enhance
current vtd_process_device_iotlb_desc() to behave differently
depending on which device the SID belongs to. E.g.:

(1) for emulated devices (virtio-pci/vhost is one of them), we pass
down using a UNMAP, or say, do a cache flush

(2) for assigned devices, we pass it down to hardware by some way

I don't know whether there'll be a (3) though. Also, I don't know the
best way to achieve (2) (new vfio driver interface?).

Thanks,

Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems.

[Fam Zheng]

On Thu, 02/16 12:47, Chad Joan wrote:
> I am glad others are chiming in and might provide better solutions.
> 
> Honestly, following the instructions at
> http://wiki.qemu-project.org/Contribute/SubmitAPatch to-the-letter is quite
> daunting to me, just to get one line of code changed.  It might help if
> that page had some kind of dead-simple example for trivial patches;
> something like:
> $ cd 
> $ git format-patch blah blah blah
> $ maybe-some-other-command
> $ # Now copy the contents of file xyz.patch into your email client and send
> to qemu-devel@nongnu.org and qemu-triv...@nongnu.org

Makes sense in general except for the sending part - email clients tend to
damage the patch when you copy and paste by wrapping long lines or messing up
other things. But your point is taken, we should make the first (or a one-shot)
contribution as easy as possible.

Fam

Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb descriptor

[Jason Wang]

On 2017年02月17日 14:18, Liu, Yi L wrote:

-Original Message-
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Thursday, February 16, 2017 1:44 PM
To: Liu, Yi L ; Michael S. Tsirkin ; qemu-
de...@nongnu.org
Cc: Peter Maydell ; Eduardo Habkost
; Peter Xu ; Paolo Bonzini
; Richard Henderson ; Tian, Kevin
; Lan, Tianyu ; Alex Williamson

Subject: Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
descriptor



On 2017年02月16日 13:36, Liu, Yi L wrote:

-Original Message-
From: Qemu-devel
[mailto:qemu-devel-bounces+yi.l.liu=intel@nongnu.org]
On Behalf Of Michael S. Tsirkin
Sent: Tuesday, January 10, 2017 1:40 PM
To: qemu-devel@nongnu.org
Cc: Peter Maydell ; Eduardo Habkost
; Jason Wang ; Peter Xu
; Paolo Bonzini ; Richard
Henderson 
Subject: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
descriptor

From: Jason Wang 

This patch enables device IOTLB support for intel iommu. The major
work is to implement QI device IOTLB descriptor processing and notify
the device through iommu notifier.


Hi Jason/Michael,

Recently Peter Xu's patch also touched intel-iommu emulation. His
patch shadows second-level page table by capturing iotlb flush from
guest. It would result in page table updating in host. Does this patch
also use the same map/umap API provided by VFIO?

Yes, it depends on the iommu notifier too.


If it is, then I think it would also update page table in host. It
looks to be a duplicate update. Pls refer to the following snapshot
captured from section 6.5.2.5 of vtd spec.

"Since translation requests from a device may be serviced by hardware
from the IOTLB, software must always request IOTLB invalidation
(iotlb_inv_dsc) before requesting corresponding Device-TLB
(dev_tlb_inv_dsc) invalidation."

Maybe for device-iotlb, we need a separate API which just pass down
the invalidate info without updating page table. Any thoughts?

cc Alex.

If we want ATS to be visible for guest (but I'm not sure if VFIO support this), 
we
probably need another notifier or a new flag.

Jason, for assigned device, I think guest could see ATS if the assigned device
supports ATS. I can see it when passthru iGPU.

Regards,
Yi L


Good to know this.

If I understand your suggestion correctly, you want a dedicated API to 
flush a hardware device IOTLB. I'm not sure this is really needed.


There's some discussion of similar issue in the past (when ATS is used 
for virtio-net/vhost), looks like we could solve this by not trigger the 
UNMAP notifier unless it was device IOTLB inv desc if ATS is enabled for 
the device? With this remote IOMMU/IOTLB can only get invalidation 
request once. For VFIO, the under layer IOMMU can deal with hardware 
device IOTLB without any extra efforts.


Does this make sense?

Thanks

Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb descriptor

[Liu, Yi L]

> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Friday, February 17, 2017 11:26 AM
> To: Liu, Yi L 
> Cc: Michael S. Tsirkin ; qemu-devel@nongnu.org; Peter
> Maydell ; Eduardo Habkost
> ; Jason Wang ; Paolo Bonzini
> ; Richard Henderson ; Tian, Kevin
> ; Lan, Tianyu 
> Subject: Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
> descriptor
> 
> On Thu, Feb 16, 2017 at 05:36:06AM +, Liu, Yi L wrote:
> > > -Original Message-
> > > From: Qemu-devel
> > > [mailto:qemu-devel-bounces+yi.l.liu=intel@nongnu.org]
> > > On Behalf Of Michael S. Tsirkin
> > > Sent: Tuesday, January 10, 2017 1:40 PM
> > > To: qemu-devel@nongnu.org
> > > Cc: Peter Maydell ; Eduardo Habkost
> > > ; Jason Wang ; Peter Xu
> > > ; Paolo Bonzini ; Richard
> > > Henderson 
> > > Subject: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
> > > descriptor
> > >
> > > From: Jason Wang 
> > >
> > > This patch enables device IOTLB support for intel iommu. The major
> > > work is to implement QI device IOTLB descriptor processing and
> > > notify the device through iommu notifier.
> > >
> > Hi Jason/Michael,
> >
> > Recently Peter Xu's patch also touched intel-iommu emulation. His
> > patch shadows second-level page table by capturing iotlb flush from
> > guest. It would result in page table updating in host. Does this patch
> > also use the same map/umap API provided by VFIO? If it is, then I think it
> would also update page table in host.
> 
> I haven't considered complex scenarios, but if simply we have a VM with one
> vhost device and one vfio-pci device, imho that should not be a problem -
> device iotlb is targeting SID rather than DOMAIN. So device iotlb 
> invalidations
> for vhost will be sent to vhost device only.

Peter, I think for assigned device, all guest iotlb flush should be translated 
to
be targeting device in the scope of host. Besides the scenario which has vhost
and vfio-pci device at the same time, how about only having vfio-pci device
and this device has ATS support. Then there should be device-iotlb flushing.
With this patch and your patch, it would also introduce two flushing.

> However, vhost may receive two invalidations here, but it won't matter much
> since vhost is just flushing caches twice.

yeah, so far I didn’t see functional issue, may just reduce performance^_^

> > It looks to be
> > a duplicate update. Pls refer to the following snapshot captured from
> > section 6.5.2.5 of vtd spec.
> >
> > "Since translation requests from a device may be serviced by hardware
> > from the IOTLB, software must always request IOTLB invalidation
> > (iotlb_inv_dsc) before requesting corresponding Device-TLB
> > (dev_tlb_inv_dsc) invalidation."
> >
> > Maybe for device-iotlb, we need a separate API which just pass down
> > the invalidate info without updating page table. Any thoughts?
> 
> Now imho I slightly prefer just use the current UNMAP notifier type even for
> device iotlb device. But, we may need to do one more check that we skip
> sending general iotlb invalidations to ATS enabled devices like vhost, to 
> avoid
> duplicated cache flushing. From virt-svm side, do we have specific requirement
> to introduce a new flag for it?
I think it is a practical solution to do such a check to avoid duplicate 
flushing.

For virt-svm, requirement is a little bit different since it's not shadowing 
any guest
page table. It needs to shadow invalidate operations. So virt-svm will not use
MAP/UNMAP notifier. Instead, it may require notifier which passdown invalidate
info and then submit invalidation directly.(no page table updating in host). 

Regards,
Yi L

[Qemu-devel] [PATCH v8 3/5] hw/intc/arm_gicv3_kvm: Implement get/put functions

[vijay . kilari]

From: Vijaya Kumar K 

This actually implements pre_save and post_load methods for in-kernel
vGICv3.

Signed-off-by: Pavel Fedin 
Signed-off-by: Peter Maydell 
[PMM:
 * use decimal, not 0bnnn
 * fixed typo in names of ICC_APR0R_EL1 and ICC_AP1R_EL1
 * completely rearranged the get and put functions to read and write
   the state in a natural order, rather than mixing distributor and
   redistributor state together]
Signed-off-by: Vijaya Kumar K 
[Vijay:
 * Update macro KVM_VGIC_ATTR
 * Use 32 bit access for gicd and gicr
 * GICD_IROUTER, GICD_TYPER, GICR_PROPBASER and GICR_PENDBASER reg
   access  are changed from 64-bit to 32-bit access
 * Add ICC_SRE_EL1 save and restore
 * Dropped translate_fn mechanism and coded functions to handle
   save and restore of edge_trigger and priority
 * Number of APnR register saved/restored based on number of
   priority bits supported]
Reviewed-by: Peter Maydell 
---
---
 hw/intc/arm_gicv3_kvm.c  | 573 +--
 hw/intc/gicv3_internal.h |   1 +
 2 files changed, 558 insertions(+), 16 deletions(-)

diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c
index d69dc47..cda1af4 100644
--- a/hw/intc/arm_gicv3_kvm.c
+++ b/hw/intc/arm_gicv3_kvm.c
@@ -23,8 +23,10 @@
 #include "qapi/error.h"
 #include "hw/intc/arm_gicv3_common.h"
 #include "hw/sysbus.h"
+#include "qemu/error-report.h"
 #include "sysemu/kvm.h"
 #include "kvm_arm.h"
+#include "gicv3_internal.h"
 #include "vgic_common.h"
 #include "migration/migration.h"
 
@@ -44,6 +46,32 @@
 #define KVM_ARM_GICV3_GET_CLASS(obj) \
  OBJECT_GET_CLASS(KVMARMGICv3Class, (obj), TYPE_KVM_ARM_GICV3)
 
+#define   KVM_DEV_ARM_VGIC_SYSREG(op0, op1, crn, crm, op2) \
+ (ARM64_SYS_REG_SHIFT_MASK(op0, OP0) | \
+  ARM64_SYS_REG_SHIFT_MASK(op1, OP1) | \
+  ARM64_SYS_REG_SHIFT_MASK(crn, CRN) | \
+  ARM64_SYS_REG_SHIFT_MASK(crm, CRM) | \
+  ARM64_SYS_REG_SHIFT_MASK(op2, OP2))
+
+#define ICC_PMR_EL1 \
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 4, 6, 0)
+#define ICC_BPR0_EL1\
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 12, 8, 3)
+#define ICC_AP0R_EL1(n) \
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 12, 8, 4 | n)
+#define ICC_AP1R_EL1(n) \
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 12, 9, n)
+#define ICC_BPR1_EL1\
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 12, 12, 3)
+#define ICC_CTLR_EL1\
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 12, 12, 4)
+#define ICC_SRE_EL1 \
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 12, 12, 5)
+#define ICC_IGRPEN0_EL1 \
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 12, 12, 6)
+#define ICC_IGRPEN1_EL1 \
+KVM_DEV_ARM_VGIC_SYSREG(3, 0, 12, 12, 7)
+
 typedef struct KVMARMGICv3Class {
 ARMGICv3CommonClass parent_class;
 DeviceRealize parent_realize;
@@ -57,16 +85,523 @@ static void kvm_arm_gicv3_set_irq(void *opaque, int irq, 
int level)
 kvm_arm_gic_set_irq(s->num_irq, irq, level);
 }
 
+#define KVM_VGIC_ATTR(reg, typer) \
+((typer & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) | (reg))
+
+static inline void kvm_gicd_access(GICv3State *s, int offset,
+   uint32_t *val, bool write)
+{
+kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_DIST_REGS,
+  KVM_VGIC_ATTR(offset, 0),
+  val, write);
+}
+
+static inline void kvm_gicr_access(GICv3State *s, int offset, int cpu,
+   uint32_t *val, bool write)
+{
+kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_REDIST_REGS,
+  KVM_VGIC_ATTR(offset, s->cpu[cpu].gicr_typer),
+  val, write);
+}
+
+static inline void kvm_gicc_access(GICv3State *s, uint64_t reg, int cpu,
+   uint64_t *val, bool write)
+{
+kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS,
+  KVM_VGIC_ATTR(reg, s->cpu[cpu].gicr_typer),
+  val, write);
+}
+
+static inline void kvm_gic_line_level_access(GICv3State *s, int irq, int cpu,
+ uint32_t *val, bool write)
+{
+kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO,
+  KVM_VGIC_ATTR(irq, s->cpu[cpu].gicr_typer) |
+  (VGIC_LEVEL_INFO_LINE_LEVEL <<
+   KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT),
+  val, write);
+}
+
+/* Loop through each distributor IRQ related register; since bits
+ * corresponding to SPIs and PPIs are RAZ/WI when affinity routing
+ * is enabled, we skip those.
+ */
+#define for_each_dist_irq_reg(_irq, _max, _field_width) \
+for (_irq = GIC_INTERNAL; _irq < _max; _irq += (32 / _field_width))
+
+static void kvm_dist_get_priority(GICv3State *s, uint32_t offset, uint8_t *bmp)
+{
+uint32_t reg, *field;
+int irq;
+
+

[Qemu-devel] [PATCH v8 4/5] target-arm: Add GICv3CPUState in CPUARMState struct

[vijay . kilari]

From: Vijaya Kumar K 

Add gicv3state void pointer to CPUARMState struct
to store GICv3CPUState.

In case of usecase like CPU reset, we need to reset
GICv3CPUState of the CPU. In such scenario, this pointer
becomes handy.

This patch take care of only GICv3.

Signed-off-by: Vijaya Kumar K 
---
 hw/intc/arm_gicv3_common.c | 2 ++
 hw/intc/arm_gicv3_cpuif.c  | 8 
 hw/intc/gicv3_internal.h   | 2 ++
 target/arm/cpu.h   | 2 ++
 4 files changed, 14 insertions(+)

diff --git a/hw/intc/arm_gicv3_common.c b/hw/intc/arm_gicv3_common.c
index e62480e..79a5bd9 100644
--- a/hw/intc/arm_gicv3_common.c
+++ b/hw/intc/arm_gicv3_common.c
@@ -248,6 +248,8 @@ static void arm_gicv3_common_realize(DeviceState *dev, 
Error **errp)
 
 s->cpu[i].cpu = cpu;
 s->cpu[i].gic = s;
+/* Store GICv3CPUState in CPUARMState gicv3state pointer */
+gicv3_set_gicv3state(cpu, >cpu[i]);
 
 /* Pre-construct the GICR_TYPER:
  * For our implementation:
diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
index c25ee03..7849783 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/intc/arm_gicv3_cpuif.c
@@ -18,6 +18,14 @@
 #include "gicv3_internal.h"
 #include "cpu.h"
 
+void gicv3_set_gicv3state(CPUState *cpu, GICv3CPUState *s)
+{
+ARMCPU *arm_cpu = ARM_CPU(cpu);
+CPUARMState *env = _cpu->env;
+
+env->gicv3state = (void *)s;
+};
+
 static GICv3CPUState *icc_cs_from_env(CPUARMState *env)
 {
 /* Given the CPU, find the right GICv3CPUState struct.
diff --git a/hw/intc/gicv3_internal.h b/hw/intc/gicv3_internal.h
index 457118e..05303a5 100644
--- a/hw/intc/gicv3_internal.h
+++ b/hw/intc/gicv3_internal.h
@@ -408,4 +408,6 @@ static inline void 
gicv3_cache_all_target_cpustates(GICv3State *s)
 }
 }
 
+void gicv3_set_gicv3state(CPUState *cpu, GICv3CPUState *s);
+
 #endif /* QEMU_ARM_GICV3_INTERNAL_H */
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 0956a54..d2eb7bf 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -517,6 +517,8 @@ typedef struct CPUARMState {
 
 void *nvic;
 const struct arm_boot_info *boot_info;
+/* Store GICv3CPUState to access from this struct */
+void *gicv3state;
 } CPUARMState;
 
 /**
-- 
1.9.1

[Qemu-devel] [PATCH v8 1/5] kernel: Add definitions for GICv3 attributes

[vijay . kilari]

From: Vijaya Kumar K 

This temporary patch adds kernel API definitions.
Use proper header update procedure after these features
are released.

Signed-off-by: Pavel Fedin 
Signed-off-by: Vijaya Kumar K 
---
 linux-headers/asm-arm/kvm.h   | 12 
 linux-headers/asm-arm64/kvm.h | 12 
 2 files changed, 24 insertions(+)

diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index 2fb7859..1798c93 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -179,10 +179,22 @@ struct kvm_arch_memory_slot {
 #define KVM_DEV_ARM_VGIC_GRP_CPU_REGS  2
 #define   KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
 #define   KVM_DEV_ARM_VGIC_CPUID_MASK  (0xffULL << 
KVM_DEV_ARM_VGIC_CPUID_SHIFT)
+#define   KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT 32
+#define   KVM_DEV_ARM_VGIC_V3_MPIDR_MASK \
+   (0xULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
 #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT0
 #define   KVM_DEV_ARM_VGIC_OFFSET_MASK (0xULL << 
KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
+#define   KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0x)
 #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS   3
 #define KVM_DEV_ARM_VGIC_GRP_CTRL   4
+#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
+#define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
+#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO  7
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT 10
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
+   (0x3fULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK 0x3ff
+#define VGIC_LEVEL_INFO_LINE_LEVEL 0
 #define   KVM_DEV_ARM_VGIC_CTRL_INIT0
 
 /* KVM_IRQ_LINE irq field index values */
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index fd5a276..b3f02ce 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -201,10 +201,22 @@ struct kvm_arch_memory_slot {
 #define KVM_DEV_ARM_VGIC_GRP_CPU_REGS  2
 #define   KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
 #define   KVM_DEV_ARM_VGIC_CPUID_MASK  (0xffULL << 
KVM_DEV_ARM_VGIC_CPUID_SHIFT)
+#define   KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT 32
+#define   KVM_DEV_ARM_VGIC_V3_MPIDR_MASK \
+   (0xULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
 #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT0
 #define   KVM_DEV_ARM_VGIC_OFFSET_MASK (0xULL << 
KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
+#define   KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0x)
 #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS   3
 #define KVM_DEV_ARM_VGIC_GRP_CTRL  4
+#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
+#define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
+#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO  7
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT 10
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
+   (0x3fULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK 0x3ff
+#define VGIC_LEVEL_INFO_LINE_LEVEL 0
 #define   KVM_DEV_ARM_VGIC_CTRL_INIT   0
 
 /* Device Control API on vcpu fd */
-- 
1.9.1

[Qemu-devel] [PATCH v8 5/5] hw/intc/arm_gicv3_kvm: Reset GICv3 cpu interface registers

[vijay . kilari]

From: Vijaya Kumar K 

Reset CPU interface registers of GICv3 when CPU is reset.
For this, ARMCPRegInfo struct is registered with one ICC
register whose resetfn is called when cpu is reset.

All the ICC registers are reset under one single register
reset function instead of calling resetfn for each ICC
register.

Signed-off-by: Vijaya Kumar K 
---
 hw/intc/arm_gicv3_kvm.c | 58 +
 1 file changed, 58 insertions(+)

diff --git a/hw/intc/arm_gicv3_kvm.c b/hw/intc/arm_gicv3_kvm.c
index cda1af4..6377dc3 100644
--- a/hw/intc/arm_gicv3_kvm.c
+++ b/hw/intc/arm_gicv3_kvm.c
@@ -604,6 +604,34 @@ static void kvm_arm_gicv3_get(GICv3State *s)
 }
 }
 
+static void arm_gicv3_icc_reset(CPUARMState *env, const ARMCPRegInfo *ri)
+{
+ARMCPU *cpu;
+GICv3State *s;
+GICv3CPUState *c;
+
+c = (GICv3CPUState *)env->gicv3state;
+assert(!(!c || !c->cpu || !c->gic));
+
+s = c->gic;
+cpu = ARM_CPU(c->cpu);
+
+/* Initialize to actual HW supported configuration */
+kvm_device_access(s->dev_fd, KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS,
+  KVM_VGIC_ATTR(ICC_CTLR_EL1, cpu->mp_affinity),
+  >icc_ctlr_el1[GICV3_NS], false);
+
+c->icc_ctlr_el1[GICV3_S] = c->icc_ctlr_el1[GICV3_NS];
+c->icc_pmr_el1 = 0;
+c->icc_bpr[GICV3_G0] = GIC_MIN_BPR;
+c->icc_bpr[GICV3_G1] = GIC_MIN_BPR;
+c->icc_bpr[GICV3_G1NS] = GIC_MIN_BPR;
+
+c->icc_sre_el1 = 0x7;
+memset(c->icc_apr, 0, sizeof(c->icc_apr));
+memset(c->icc_igrpen, 0, sizeof(c->icc_igrpen));
+}
+
 static void kvm_arm_gicv3_reset(DeviceState *dev)
 {
 GICv3State *s = ARM_GICV3_COMMON(dev);
@@ -621,6 +649,30 @@ static void kvm_arm_gicv3_reset(DeviceState *dev)
 kvm_arm_gicv3_put(s);
 }
 
+/*
+ * CPU interface registers of GIC needs to be reset on CPU reset.
+ * For the calling arm_gicv3_icc_reset() on CPU reset, we register
+ * below ARMCPRegInfo. As we reset the whole cpu interface under single
+ * register reset, we define only one register of CPU interface instead
+ * of defining all the registers.
+ */
+static const ARMCPRegInfo gicv3_cpuif_reginfo[] = {
+{ .name = "ICC_CTLR_EL1", .state = ARM_CP_STATE_BOTH,
+  .opc0 = 3, .opc1 = 0, .crn = 12, .crm = 12, .opc2 = 4,
+  .type = ARM_CP_NO_RAW,
+  .access = PL1_RW,
+  .readfn = arm_cp_read_zero,
+  .writefn = arm_cp_write_ignore,
+  /*
+   * We hang the whole cpu interface reset routine off here
+   * rather than parcelling it out into one little function
+   * per register
+   */
+  .resetfn = arm_gicv3_icc_reset,
+},
+REGINFO_SENTINEL
+};
+
 static void kvm_arm_gicv3_realize(DeviceState *dev, Error **errp)
 {
 GICv3State *s = KVM_ARM_GICV3(dev);
@@ -644,6 +696,12 @@ static void kvm_arm_gicv3_realize(DeviceState *dev, Error 
**errp)
 
 gicv3_init_irqs_and_mmio(s, kvm_arm_gicv3_set_irq, NULL);
 
+for (i = 0; i < s->num_cpu; i++) {
+ARMCPU *cpu = ARM_CPU(qemu_get_cpu(i));
+
+define_arm_cp_regs(cpu, gicv3_cpuif_reginfo);
+}
+
 /* Try to create the device via the device control API */
 s->dev_fd = kvm_create_device(kvm_state, KVM_DEV_TYPE_ARM_VGIC_V3, false);
 if (s->dev_fd < 0) {
-- 
1.9.1

[Qemu-devel] [PATCH v8 2/5] hw/intc/arm_gicv3_kvm: Add ICC_SRE_EL1 register to vmstate

[vijay . kilari]

From: Vijaya Kumar K 

To Save and Restore ICC_SRE_EL1 register introduce vmstate
subsection and load only if non-zero.
Also initialize icc_sre_el1 with to 0x7 in pre_load
function.

Signed-off-by: Vijaya Kumar K 
---
 hw/intc/arm_gicv3_common.c | 32 
 include/hw/intc/arm_gicv3_common.h |  1 +
 2 files changed, 33 insertions(+)

diff --git a/hw/intc/arm_gicv3_common.c b/hw/intc/arm_gicv3_common.c
index 16b9b0f..e62480e 100644
--- a/hw/intc/arm_gicv3_common.c
+++ b/hw/intc/arm_gicv3_common.c
@@ -70,6 +70,34 @@ static const VMStateDescription vmstate_gicv3_cpu_virt = {
 }
 };
 
+static int icc_sre_el1_reg_pre_load(void *opaque)
+{
+GICv3CPUState *cs = opaque;
+
+/* By default enable SRE and disable IRQ & FIQ bypass. */
+cs->icc_sre_el1 = 0x7;
+return 0;
+}
+
+static bool icc_sre_el1_reg_needed(void *opaque)
+{
+GICv3CPUState *cs = opaque;
+
+return cs->icc_sre_el1 != 0;
+}
+
+const VMStateDescription vmstate_gicv3_cpu_sre_el1 = {
+.name = "arm_gicv3_cpu/sre_el1",
+.version_id = 1,
+.minimum_version_id = 1,
+.pre_load = icc_sre_el1_reg_pre_load,
+.needed = icc_sre_el1_reg_needed,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(icc_sre_el1, GICv3CPUState),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static const VMStateDescription vmstate_gicv3_cpu = {
 .name = "arm_gicv3_cpu",
 .version_id = 1,
@@ -100,6 +128,10 @@ static const VMStateDescription vmstate_gicv3_cpu = {
 .subsections = (const VMStateDescription * []) {
 _gicv3_cpu_virt,
 NULL
+},
+.subsections = (const VMStateDescription * []) {
+_gicv3_cpu_sre_el1,
+NULL
 }
 };
 
diff --git a/include/hw/intc/arm_gicv3_common.h 
b/include/hw/intc/arm_gicv3_common.h
index 4156051..bccdfe1 100644
--- a/include/hw/intc/arm_gicv3_common.h
+++ b/include/hw/intc/arm_gicv3_common.h
@@ -172,6 +172,7 @@ struct GICv3CPUState {
 uint8_t gicr_ipriorityr[GIC_INTERNAL];
 
 /* CPU interface */
+uint64_t icc_sre_el1;
 uint64_t icc_ctlr_el1[2];
 uint64_t icc_pmr_el1;
 uint64_t icc_bpr[3];
-- 
1.9.1

[Qemu-devel] [PATCH v8 0/5] GICv3 live migration support

[vijay . kilari]

From: Vijaya Kumar K 

This series introduces support for GICv3 live migration with
new VGIC implementation in 4.7-rc3 kernel.
In this series, patch 1 of the previous implementation
are ported.
https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05284.html

Patch 2, is based on below implementation.
http://patchwork.ozlabs.org/patch/626746/

Latest kernel patches
https://www.spinics.net/lists/arm-kernel/msg558046.html

This API definition is as per version of VGICv3 specification
in linux kernel Documentation/virtual/kvm/devices/arm-vgic-v3.txt

Tested Live migration of Idle VM running with 4 VCPUs and 8GB RAM.

v7 => v8:
 - Introduced vmstate subsection to add icc_ctrl_el1 register to
   VMStateDescription
 - Introduced new function gicv3_set_gicv3state() in arm_gicv3_cpuif.c
   to update gicv3state variable in CPUARMState struct.
 - Used arm_cp_read_zero & arm_cp_write_ignore for ARMCPRegInfo[].

v6 => v7:
 - Rebased on top of v2.8.0-rc4 release.
 - Added patch to add icc_ctrl_el1 to vmstruct before live migration
   patch.
 - Added patch to add gicv3state variable to CPUARMState struct to
   store GICv3CPUState pointer.
 - Added patch to register ARMCPRegInfo[] struct and reset on CPU reset.

v5 => v6:
 - Added separate patch for Reseting ICC* register
 - Added seperate patch for save and restore of ICC_CTLR_EL1
 - Dropped translate_fn mechanism and coded open functions
   for edge_trigger and priority save and restore.
 - Save and Restore APnR registers based on ICC_CTLR_EL1.PRIBITS

v4 => v5:
 - Initialized ICC registers before reset.

v3 => v4:
 - Reintroduced offset GICR_SGI_OFFSET
 - Implement save and restore of ICC_SRE_EL1
 - Updated kvm.h header file in sync with KVM v4 patches

v2 => v3:
 - Dropped offset GICR_SGI_OFFSET
 - Implement save/restore of irq line level using
   KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO
 - Fixed bug with save/restore of edge_trigger
Vijaya Kumar K (5):
  kernel: Add definitions for GICv3 attributes
  hw/intc/arm_gicv3_kvm: Add ICC_SRE_EL1 register to vmstate
  hw/intc/arm_gicv3_kvm: Implement get/put functions
  target-arm: Add GICv3CPUState in CPUARMState struct
  hw/intc/arm_gicv3_kvm: Reset GICv3 cpu interface registers

 hw/intc/arm_gicv3_common.c |  34 ++
 hw/intc/arm_gicv3_cpuif.c  |   8 +
 hw/intc/arm_gicv3_kvm.c| 627 -
 hw/intc/gicv3_internal.h   |   3 +
 include/hw/intc/arm_gicv3_common.h |   1 +
 linux-headers/asm-arm/kvm.h|  12 +
 linux-headers/asm-arm64/kvm.h  |  12 +
 target/arm/cpu.h   |   2 +
 8 files changed, 685 insertions(+), 14 deletions(-)

-- 
1.9.1

Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb descriptor

[Liu, Yi L]

> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Thursday, February 16, 2017 1:44 PM
> To: Liu, Yi L ; Michael S. Tsirkin ; 
> qemu-
> de...@nongnu.org
> Cc: Peter Maydell ; Eduardo Habkost
> ; Peter Xu ; Paolo Bonzini
> ; Richard Henderson ; Tian, Kevin
> ; Lan, Tianyu ; Alex Williamson
> 
> Subject: Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
> descriptor
> 
> 
> 
> On 2017年02月16日 13:36, Liu, Yi L wrote:
> >> -Original Message-
> >> From: Qemu-devel
> >> [mailto:qemu-devel-bounces+yi.l.liu=intel@nongnu.org]
> >> On Behalf Of Michael S. Tsirkin
> >> Sent: Tuesday, January 10, 2017 1:40 PM
> >> To: qemu-devel@nongnu.org
> >> Cc: Peter Maydell ; Eduardo Habkost
> >> ; Jason Wang ; Peter Xu
> >> ; Paolo Bonzini ; Richard
> >> Henderson 
> >> Subject: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
> >> descriptor
> >>
> >> From: Jason Wang 
> >>
> >> This patch enables device IOTLB support for intel iommu. The major
> >> work is to implement QI device IOTLB descriptor processing and notify
> >> the device through iommu notifier.
> >>
> > Hi Jason/Michael,
> >
> > Recently Peter Xu's patch also touched intel-iommu emulation. His
> > patch shadows second-level page table by capturing iotlb flush from
> > guest. It would result in page table updating in host. Does this patch
> > also use the same map/umap API provided by VFIO?
> 
> Yes, it depends on the iommu notifier too.
> 
> > If it is, then I think it would also update page table in host. It
> > looks to be a duplicate update. Pls refer to the following snapshot
> > captured from section 6.5.2.5 of vtd spec.
> >
> > "Since translation requests from a device may be serviced by hardware
> > from the IOTLB, software must always request IOTLB invalidation
> > (iotlb_inv_dsc) before requesting corresponding Device-TLB
> > (dev_tlb_inv_dsc) invalidation."
> >
> > Maybe for device-iotlb, we need a separate API which just pass down
> > the invalidate info without updating page table. Any thoughts?
> 
> cc Alex.
> 
> If we want ATS to be visible for guest (but I'm not sure if VFIO support 
> this), we
> probably need another notifier or a new flag.

Jason, for assigned device, I think guest could see ATS if the assigned device
supports ATS. I can see it when passthru iGPU.

Regards,
Yi L

Re: [Qemu-devel] [PATCH 0/5] A few VLAN-related bugfixes for RX packet abstraction

[Dmitry Fleytman]

> On 17 Feb 2017, at 5:05, Jason Wang  wrote:
> 
> 
> 
>> On 2017年02月16日 20:39, Peter Maydell wrote:
>>> On 16 February 2017 at 12:29, Dmitry Fleytman  wrote:
>>> This series fix a few issues related
>>> to processing of RX packets with VLAN headers.
>>> 
>>> See commit messages of specific patches
>>> for information regarding affected devices.
>> I think at least the "fix buffer overrun" parts of this
>> patchset should be cc:stable ?
>> 
>> thanks
>> -- PMM
> 
> Yes, I add cc:stable to patch 1 - 4.

Thanks, Jason!

> 
> Thanks

Re: [Qemu-devel] [PATCH 5/6] target-ppc: support for 32-bit carry and overflow

[Nikunj A Dadhania]

Richard Henderson  writes:

> On 02/16/2017 04:08 PM, Nikunj A Dadhania wrote:
>> Richard Henderson  writes:
>>
>>> On 02/14/2017 02:05 PM, Nikunj A Dadhania wrote:
 Yes, you are right. I had a discussion with Paul Mackerras yesterday, he
 explained to me in detail about the bits. I am working on the revised
 implementation. Will detail it in the commit message.
>>>
>>> As you're working on this, consider changing the definition of cpu_ov such 
>>> that
>>> the MSB is OV and bit 31 is OV32.
>>>
>>> E.g.
>>>
>>>
>>>   static inline void gen_op_arith_compute_ov(DisasContext *ctx, TCGv arg0,
>>>  TCGv arg1, TCGv arg2, int sub)
>>>   {
>>>   TCGv t0 = tcg_temp_new();
>>>
>>>   tcg_gen_xor_tl(cpu_ov, arg0, arg2);
>>>   tcg_gen_xor_tl(t0, arg1, arg2);
>>>   if (sub) {
>>>   tcg_gen_and_tl(cpu_ov, cpu_ov, t0);
>>>   } else {
>>>   tcg_gen_andc_tl(cpu_ov, cpu_ov, t0);
>>>   }
>>>   tcg_temp_free(t0);
>>>   if (NARROW_MODE(ctx)) {
>>>   tcg_gen_ext32s_tl(cpu_ov, cpu_ov);
>>>   }
>>> -tcg_gen_shri_tl(cpu_ov, cpu_ov, TARGET_LONG_BITS - 1);
>>>   tcg_gen_or_tl(cpu_so, cpu_so, cpu_ov);
>>>   }
>>>
>>>
>>> is all that is required for arithmetic to compute OV and OV32 into those 
>>> two bits.
>>
>> How about the below?
>>
>> @@ -809,10 +809,11 @@ static inline void 
>> gen_op_arith_compute_ov(DisasContext *ctx, TCGv arg0,
>>  tcg_gen_andc_tl(cpu_ov, cpu_ov, t0);
>>  }
>>  tcg_temp_free(t0);
>> +tcg_gen_extract_tl(cpu_ov32, cpu_ov, 31, 1);
>> +tcg_gen_extract_tl(cpu_ov, cpu_ov, 63, 1);
>>  if (NARROW_MODE(ctx)) {
>> -tcg_gen_ext32s_tl(cpu_ov, cpu_ov);
>> +tcg_gen_mov_tl(cpu_ov, cpu_ov32);
>>  }
>> -tcg_gen_shri_tl(cpu_ov, cpu_ov, TARGET_LONG_BITS - 1);
>>  tcg_gen_or_tl(cpu_so, cpu_so, cpu_ov);
>>  }
>
> Why do you want to extract these bits?

Convinient to copy that to XER later.

Regards
Nikunj

Re: [Qemu-devel] [PATCH v3 4/4] colo-compare: Fix removing fds been watched incorrectly in finalization

[Zhang Chen]

On 02/17/2017 10:53 AM, zhanghailiang wrote:

We will catch the bellow error report while try to delete compare object
by qmp command:
chardev/char-io.c:91: io_watch_poll_finalize: Assertion `iwp->src == ((void 
*)0)' failed.

This is caused by failing to remove the right fd been watched while
call qemu_chr_fe_set_handlers();

Fix it by pass the worker_context parameter to qemu_chr_fe_set_handlers().

Signed-off-by: zhanghailiang


Reviewed-by: Zhang Chen 


---
  net/colo-compare.c | 20 +++-
  1 file changed, 11 insertions(+), 9 deletions(-)


--
Thanks
Zhang Chen

Re: [Qemu-devel] [PATCH v3 2/4] colo-compare: kick compare thread to exit after some cleanup in finalization

[Zhang Chen]

On 02/17/2017 10:53 AM, zhanghailiang wrote:

We should call g_main_loop_quit() to notify colo compare thread to
exit, Or it will run in g_main_loop_run() forever.

Besides, the finalizing process can't happen in context of colo thread,
it is reasonable to remove the 'if (qemu_thread_is_self(>thread))'
branch.

Before compare thead exits, some cleanup works need to be
done,  All unhandled packets need to be released and connection_track_table
needs to be freed, or there will be memory leak.

Signed-off-by: zhanghailiang 


Reviewed-by: Zhang Chen 


---
  net/colo-compare.c | 39 +--
  1 file changed, 29 insertions(+), 10 deletions(-)


--
Thanks
Zhang Chen

Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb descriptor

[Peter Xu]

On Thu, Feb 16, 2017 at 05:36:06AM +, Liu, Yi L wrote:
> > -Original Message-
> > From: Qemu-devel [mailto:qemu-devel-bounces+yi.l.liu=intel@nongnu.org]
> > On Behalf Of Michael S. Tsirkin
> > Sent: Tuesday, January 10, 2017 1:40 PM
> > To: qemu-devel@nongnu.org
> > Cc: Peter Maydell ; Eduardo Habkost
> > ; Jason Wang ; Peter Xu
> > ; Paolo Bonzini ; Richard
> > Henderson 
> > Subject: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb
> > descriptor
> > 
> > From: Jason Wang 
> > 
> > This patch enables device IOTLB support for intel iommu. The major work is 
> > to
> > implement QI device IOTLB descriptor processing and notify the device 
> > through
> > iommu notifier.
> >
> Hi Jason/Michael,
>   
> Recently Peter Xu's patch also touched intel-iommu emulation. His patch 
> shadows
> second-level page table by capturing iotlb flush from guest. It would result 
> in page
> table updating in host. Does this patch also use the same map/umap API 
> provided
> by VFIO? If it is, then I think it would also update page table in host.

I haven't considered complex scenarios, but if simply we have a VM
with one vhost device and one vfio-pci device, imho that should not be
a problem - device iotlb is targeting SID rather than DOMAIN. So
device iotlb invalidations for vhost will be sent to vhost device
only.

However, vhost may receive two invalidations here, but it won't matter
much since vhost is just flushing caches twice.

> It looks to be
> a duplicate update. Pls refer to the following snapshot captured from section 
> 6.5.2.5
> of vtd spec. 
> 
> "Since translation requests from a device may be serviced by hardware from 
> the IOTLB, software must
> always request IOTLB invalidation (iotlb_inv_dsc) before requesting 
> corresponding Device-TLB
> (dev_tlb_inv_dsc) invalidation."
> 
> Maybe for device-iotlb, we need a separate API which just pass down the 
> invalidate
> info without updating page table. Any thoughts?

Now imho I slightly prefer just use the current UNMAP notifier type
even for device iotlb device. But, we may need to do one more check
that we skip sending general iotlb invalidations to ATS enabled
devices like vhost, to avoid duplicated cache flushing. From virt-svm
side, do we have specific requirement to introduce a new flag for it?

Thanks,

-- peterx

Re: [Qemu-devel] [PATCH 0/5] A few VLAN-related bugfixes for RX packet abstraction

[Jason Wang]

On 2017年02月16日 20:39, Peter Maydell wrote:

On 16 February 2017 at 12:29, Dmitry Fleytman  wrote:

This series fix a few issues related
to processing of RX packets with VLAN headers.

See commit messages of specific patches
for information regarding affected devices.

I think at least the "fix buffer overrun" parts of this
patchset should be cc:stable ?

thanks
-- PMM


Yes, I add cc:stable to patch 1 - 4.

Thanks

Re: [Qemu-devel] [PATCH 0/5] A few VLAN-related bugfixes for RX packet abstraction

[Jason Wang]

On 2017年02月16日 20:29, Dmitry Fleytman wrote:

This series fix a few issues related
to processing of RX packets with VLAN headers.

See commit messages of specific patches
for information regarding affected devices.

Dmitry Fleytman (5):
   eth: Extend vlan stripping functions
   NetRxPkt: Fix memory corruption on VLAN header stripping
   NetRxPkt: Do not try to pull more data than present
   NetRxPkt: Account buffer with ETH header in IOV length
   NetRxPkt: Remove code duplication in net_rx_pkt_pull_data()

  hw/net/net_rx_pkt.c | 40 +---
  include/net/eth.h   |  4 ++--
  net/eth.c   | 25 ++---
  3 files changed, 37 insertions(+), 32 deletions(-)



Applied. Thanks

[Qemu-devel] [PATCH v3 3/4] char: remove the right fd been watched in qemu_chr_fe_set_handlers()

[zhanghailiang]

We can call qemu_chr_fe_set_handlers() to add/remove fd been watched
in 'context' which can be either default main context or other explicit
context. But the original logic is not correct, we didn't remove
the right fd because we call g_main_context_find_source_by_id(NULL, tag)
which always try to find the Gsource from default context.

Fix it by passing the right context to g_main_context_find_source_by_id().

Cc: Paolo Bonzini 
Cc: Marc-André Lureau 
Signed-off-by: zhanghailiang 
---
 chardev/char-fd.c | 6 +++---
 chardev/char-io.c | 8 
 chardev/char-io.h | 2 +-
 chardev/char-pty.c| 2 +-
 chardev/char-socket.c | 4 ++--
 chardev/char-udp.c| 6 +++---
 chardev/char.c| 2 +-
 7 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/chardev/char-fd.c b/chardev/char-fd.c
index fb51ab4..548dd4c 100644
--- a/chardev/char-fd.c
+++ b/chardev/char-fd.c
@@ -58,7 +58,7 @@ static gboolean fd_chr_read(QIOChannel *chan, GIOCondition 
cond, void *opaque)
 ret = qio_channel_read(
 chan, (gchar *)buf, len, NULL);
 if (ret == 0) {
-remove_fd_in_watch(chr);
+remove_fd_in_watch(chr, NULL);
 qemu_chr_be_event(chr, CHR_EVENT_CLOSED);
 return FALSE;
 }
@@ -89,7 +89,7 @@ static void fd_chr_update_read_handler(Chardev *chr,
 {
 FDChardev *s = FD_CHARDEV(chr);
 
-remove_fd_in_watch(chr);
+remove_fd_in_watch(chr, NULL);
 if (s->ioc_in) {
 chr->fd_in_tag = io_add_watch_poll(chr, s->ioc_in,
fd_chr_read_poll,
@@ -103,7 +103,7 @@ static void char_fd_finalize(Object *obj)
 Chardev *chr = CHARDEV(obj);
 FDChardev *s = FD_CHARDEV(obj);
 
-remove_fd_in_watch(chr);
+remove_fd_in_watch(chr, NULL);
 if (s->ioc_in) {
 object_unref(OBJECT(s->ioc_in));
 }
diff --git a/chardev/char-io.c b/chardev/char-io.c
index 7dfc3f2..b4bb094 100644
--- a/chardev/char-io.c
+++ b/chardev/char-io.c
@@ -127,14 +127,14 @@ guint io_add_watch_poll(Chardev *chr,
 return tag;
 }
 
-static void io_remove_watch_poll(guint tag)
+static void io_remove_watch_poll(guint tag, GMainContext *context)
 {
 GSource *source;
 IOWatchPoll *iwp;
 
 g_return_if_fail(tag > 0);
 
-source = g_main_context_find_source_by_id(NULL, tag);
+source = g_main_context_find_source_by_id(context, tag);
 g_return_if_fail(source != NULL);
 
 iwp = io_watch_poll_from_source(source);
@@ -146,10 +146,10 @@ static void io_remove_watch_poll(guint tag)
 g_source_destroy(>parent);
 }
 
-void remove_fd_in_watch(Chardev *chr)
+void remove_fd_in_watch(Chardev *chr, GMainContext *context)
 {
 if (chr->fd_in_tag) {
-io_remove_watch_poll(chr->fd_in_tag);
+io_remove_watch_poll(chr->fd_in_tag, context);
 chr->fd_in_tag = 0;
 }
 }
diff --git a/chardev/char-io.h b/chardev/char-io.h
index d7ae5f1..842be56 100644
--- a/chardev/char-io.h
+++ b/chardev/char-io.h
@@ -36,7 +36,7 @@ guint io_add_watch_poll(Chardev *chr,
 gpointer user_data,
 GMainContext *context);
 
-void remove_fd_in_watch(Chardev *chr);
+void remove_fd_in_watch(Chardev *chr, GMainContext *context);
 
 int io_channel_send(QIOChannel *ioc, const void *buf, size_t len);
 
diff --git a/chardev/char-pty.c b/chardev/char-pty.c
index ecf2c7a..a6337be 100644
--- a/chardev/char-pty.c
+++ b/chardev/char-pty.c
@@ -199,7 +199,7 @@ static void pty_chr_state(Chardev *chr, int connected)
 g_source_remove(s->open_tag);
 s->open_tag = 0;
 }
-remove_fd_in_watch(chr);
+remove_fd_in_watch(chr, NULL);
 s->connected = 0;
 /* (re-)connect poll interval for idle guests: once per second.
  * We check more frequently in case the guests sends data to
diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index 865c527..d7e92e1 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -328,7 +328,7 @@ static void tcp_chr_free_connection(Chardev *chr)
 }
 
 tcp_set_msgfds(chr, NULL, 0);
-remove_fd_in_watch(chr);
+remove_fd_in_watch(chr, NULL);
 object_unref(OBJECT(s->sioc));
 s->sioc = NULL;
 object_unref(OBJECT(s->ioc));
@@ -498,7 +498,7 @@ static void tcp_chr_update_read_handler(Chardev *chr,
 return;
 }
 
-remove_fd_in_watch(chr);
+remove_fd_in_watch(chr, NULL);
 if (s->ioc) {
 chr->fd_in_tag = io_add_watch_poll(chr, s->ioc,
tcp_chr_read_poll,
diff --git a/chardev/char-udp.c b/chardev/char-udp.c
index 2c6c7dd..804bd22 100644
--- a/chardev/char-udp.c
+++ b/chardev/char-udp.c
@@ -81,7 +81,7 @@ static gboolean udp_chr_read(QIOChannel *chan, GIOCondition 
cond, void *opaque)
 ret = qio_channel_read(
 s->ioc, (char *)s->buf, sizeof(s->buf), NULL);
 if (ret <= 0) {
-remove_fd_in_watch(chr);

[Qemu-devel] [PATCH v3 1/4] colo-compare: use g_timeout_source_new() to process the stale packets

[zhanghailiang]

Instead of using qemu timer to process the stale packets,
We re-use the colo compare thread to process these packets
by creating a new timeout coroutine.

Besides, since we process all the same vNIC's net connection/packets
in one thread, it is safe to remove the timer_check_lock.

Signed-off-by: zhanghailiang 
---
 net/colo-compare.c | 62 +++---
 1 file changed, 22 insertions(+), 40 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 162fd6a..fdde788 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -83,9 +83,6 @@ typedef struct CompareState {
 GHashTable *connection_track_table;
 /* compare thread, a thread for each NIC */
 QemuThread thread;
-/* Timer used on the primary to find packets that are never matched */
-QEMUTimer *timer;
-QemuMutex timer_check_lock;
 } CompareState;
 
 typedef struct CompareClass {
@@ -374,9 +371,7 @@ static void colo_compare_connection(void *opaque, void 
*user_data)
 
 while (!g_queue_is_empty(>primary_list) &&
!g_queue_is_empty(>secondary_list)) {
-qemu_mutex_lock(>timer_check_lock);
 pkt = g_queue_pop_tail(>primary_list);
-qemu_mutex_unlock(>timer_check_lock);
 switch (conn->ip_proto) {
 case IPPROTO_TCP:
 result = g_queue_find_custom(>secondary_list,
@@ -411,9 +406,7 @@ static void colo_compare_connection(void *opaque, void 
*user_data)
  * until next comparison.
  */
 trace_colo_compare_main("packet different");
-qemu_mutex_lock(>timer_check_lock);
 g_queue_push_tail(>primary_list, pkt);
-qemu_mutex_unlock(>timer_check_lock);
 /* TODO: colo_notify_checkpoint();*/
 break;
 }
@@ -486,11 +479,26 @@ static void compare_sec_chr_in(void *opaque, const 
uint8_t *buf, int size)
 }
 }
 
+/*
+ * Check old packet regularly so it can watch for any packets
+ * that the secondary hasn't produced equivalents of.
+ */
+static gboolean check_old_packet_regular(void *opaque)
+{
+CompareState *s = opaque;
+
+/* if have old packet we will notify checkpoint */
+colo_old_packet_check(s);
+
+return TRUE;
+}
+
 static void *colo_compare_thread(void *opaque)
 {
 GMainContext *worker_context;
 GMainLoop *compare_loop;
 CompareState *s = opaque;
+GSource *timeout_source;
 
 worker_context = g_main_context_new();
 
@@ -501,8 +509,15 @@ static void *colo_compare_thread(void *opaque)
 
 compare_loop = g_main_loop_new(worker_context, FALSE);
 
+/* To kick any packets that the secondary doesn't match */
+timeout_source = g_timeout_source_new(REGULAR_PACKET_CHECK_MS);
+g_source_set_callback(timeout_source,
+  (GSourceFunc)check_old_packet_regular, s, NULL);
+g_source_attach(timeout_source, worker_context);
+
 g_main_loop_run(compare_loop);
 
+g_source_unref(timeout_source);
 g_main_loop_unref(compare_loop);
 g_main_context_unref(worker_context);
 return NULL;
@@ -604,26 +619,6 @@ static int find_and_check_chardev(Chardev **chr,
 }
 
 /*
- * Check old packet regularly so it can watch for any packets
- * that the secondary hasn't produced equivalents of.
- */
-static void check_old_packet_regular(void *opaque)
-{
-CompareState *s = opaque;
-
-timer_mod(s->timer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
-  REGULAR_PACKET_CHECK_MS);
-/* if have old packet we will notify checkpoint */
-/*
- * TODO: Make timer handler run in compare thread
- * like qemu_chr_add_handlers_full.
- */
-qemu_mutex_lock(>timer_check_lock);
-colo_old_packet_check(s);
-qemu_mutex_unlock(>timer_check_lock);
-}
-
-/*
  * Called from the main thread on the primary
  * to setup colo-compare.
  */
@@ -665,7 +660,6 @@ static void colo_compare_complete(UserCreatable *uc, Error 
**errp)
 net_socket_rs_init(>sec_rs, compare_sec_rs_finalize);
 
 g_queue_init(>conn_list);
-qemu_mutex_init(>timer_check_lock);
 
 s->connection_track_table = g_hash_table_new_full(connection_key_hash,
   connection_key_equal,
@@ -678,12 +672,6 @@ static void colo_compare_complete(UserCreatable *uc, Error 
**errp)
QEMU_THREAD_JOINABLE);
 compare_id++;
 
-/* A regular timer to kick any packets that the secondary doesn't match */
-s->timer = timer_new_ms(QEMU_CLOCK_VIRTUAL, /* Only when guest runs */
-check_old_packet_regular, s);
-timer_mod(s->timer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
-REGULAR_PACKET_CHECK_MS);
-
 return;
 }
 
@@ -723,12 +711,6 @@ static void colo_compare_finalize(Object *obj)
 qemu_thread_join(>thread);
 }
 
-if (s->timer) {
-timer_del(s->timer);
-}
-
-qemu_mutex_destroy(>timer_check_lock);
-
 

[Qemu-devel] [PATCH v3 0/4] colo-compare: fix some bugs

[zhanghailiang]

This series includes two parts: codes optimization and bug fix.
patch 1 tries to move timer process into colo compare thread as 
a new coroutine.
patch 2 ~ 4 fixe some bugs of colo compare.

v2->v3:
 - change the definition of remove_fd_in_watch() instead of
   introducing a function (Marc-Andr?? Lureau's suggestion)
v1->v2:
 - Squash patch 3 of last version into patch 2. (ZhangChen's suggestion)

zhanghailiang (4):
  colo-compare: use g_timeout_source_new() to process the stale packets
  colo-compare: kick compare thread to exit after some cleanup in
finalization
  char: remove the right fd been watched in qemu_chr_fe_set_handlers()
  colo-compare: Fix removing fds been watched incorrectly in
finalization

 chardev/char-fd.c |   6 +--
 chardev/char-io.c |   8 ++--
 chardev/char-io.h |   2 +-
 chardev/char-pty.c|   2 +-
 chardev/char-socket.c |   4 +-
 chardev/char-udp.c|   6 +--
 chardev/char.c|   2 +-
 net/colo-compare.c| 115 ++
 8 files changed, 74 insertions(+), 71 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH v3 4/4] colo-compare: Fix removing fds been watched incorrectly in finalization

[zhanghailiang]

We will catch the bellow error report while try to delete compare object
by qmp command:
chardev/char-io.c:91: io_watch_poll_finalize: Assertion `iwp->src == ((void 
*)0)' failed.

This is caused by failing to remove the right fd been watched while
call qemu_chr_fe_set_handlers();

Fix it by pass the worker_context parameter to qemu_chr_fe_set_handlers().

Signed-off-by: zhanghailiang 
---
 net/colo-compare.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 37ce75c..a6fc2ff 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -84,6 +84,7 @@ typedef struct CompareState {
 /* compare thread, a thread for each NIC */
 QemuThread thread;
 
+GMainContext *worker_context;
 GMainLoop *compare_loop;
 } CompareState;
 
@@ -497,30 +498,29 @@ static gboolean check_old_packet_regular(void *opaque)
 
 static void *colo_compare_thread(void *opaque)
 {
-GMainContext *worker_context;
 CompareState *s = opaque;
 GSource *timeout_source;
 
-worker_context = g_main_context_new();
+s->worker_context = g_main_context_new();
 
 qemu_chr_fe_set_handlers(>chr_pri_in, compare_chr_can_read,
- compare_pri_chr_in, NULL, s, worker_context, 
true);
+  compare_pri_chr_in, NULL, s, s->worker_context, 
true);
 qemu_chr_fe_set_handlers(>chr_sec_in, compare_chr_can_read,
- compare_sec_chr_in, NULL, s, worker_context, 
true);
+  compare_sec_chr_in, NULL, s, s->worker_context, 
true);
 
-s->compare_loop = g_main_loop_new(worker_context, FALSE);
+s->compare_loop = g_main_loop_new(s->worker_context, FALSE);
 
 /* To kick any packets that the secondary doesn't match */
 timeout_source = g_timeout_source_new(REGULAR_PACKET_CHECK_MS);
 g_source_set_callback(timeout_source,
   (GSourceFunc)check_old_packet_regular, s, NULL);
-g_source_attach(timeout_source, worker_context);
+g_source_attach(timeout_source, s->worker_context);
 
 g_main_loop_run(s->compare_loop);
 
 g_source_unref(timeout_source);
 g_main_loop_unref(s->compare_loop);
-g_main_context_unref(worker_context);
+g_main_context_unref(s->worker_context);
 return NULL;
 }
 
@@ -717,8 +717,10 @@ static void colo_compare_finalize(Object *obj)
 {
 CompareState *s = COLO_COMPARE(obj);
 
-qemu_chr_fe_deinit(>chr_pri_in);
-qemu_chr_fe_deinit(>chr_sec_in);
+qemu_chr_fe_set_handlers(>chr_pri_in, NULL, NULL, NULL, NULL,
+ s->worker_context, true);
+qemu_chr_fe_set_handlers(>chr_sec_in, NULL, NULL, NULL, NULL,
+ s->worker_context, true);
 qemu_chr_fe_deinit(>chr_out);
 
 g_main_loop_quit(s->compare_loop);
-- 
1.8.3.1

[Qemu-devel] [PATCH v3 2/4] colo-compare: kick compare thread to exit after some cleanup in finalization

[zhanghailiang]

We should call g_main_loop_quit() to notify colo compare thread to
exit, Or it will run in g_main_loop_run() forever.

Besides, the finalizing process can't happen in context of colo thread,
it is reasonable to remove the 'if (qemu_thread_is_self(>thread))'
branch.

Before compare thead exits, some cleanup works need to be
done,  All unhandled packets need to be released and connection_track_table
needs to be freed, or there will be memory leak.

Signed-off-by: zhanghailiang 
---
 net/colo-compare.c | 39 +--
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index fdde788..37ce75c 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -83,6 +83,8 @@ typedef struct CompareState {
 GHashTable *connection_track_table;
 /* compare thread, a thread for each NIC */
 QemuThread thread;
+
+GMainLoop *compare_loop;
 } CompareState;
 
 typedef struct CompareClass {
@@ -496,7 +498,6 @@ static gboolean check_old_packet_regular(void *opaque)
 static void *colo_compare_thread(void *opaque)
 {
 GMainContext *worker_context;
-GMainLoop *compare_loop;
 CompareState *s = opaque;
 GSource *timeout_source;
 
@@ -507,7 +508,7 @@ static void *colo_compare_thread(void *opaque)
 qemu_chr_fe_set_handlers(>chr_sec_in, compare_chr_can_read,
  compare_sec_chr_in, NULL, s, worker_context, 
true);
 
-compare_loop = g_main_loop_new(worker_context, FALSE);
+s->compare_loop = g_main_loop_new(worker_context, FALSE);
 
 /* To kick any packets that the secondary doesn't match */
 timeout_source = g_timeout_source_new(REGULAR_PACKET_CHECK_MS);
@@ -515,10 +516,10 @@ static void *colo_compare_thread(void *opaque)
   (GSourceFunc)check_old_packet_regular, s, NULL);
 g_source_attach(timeout_source, worker_context);
 
-g_main_loop_run(compare_loop);
+g_main_loop_run(s->compare_loop);
 
 g_source_unref(timeout_source);
-g_main_loop_unref(compare_loop);
+g_main_loop_unref(s->compare_loop);
 g_main_context_unref(worker_context);
 return NULL;
 }
@@ -675,6 +676,23 @@ static void colo_compare_complete(UserCreatable *uc, Error 
**errp)
 return;
 }
 
+static void colo_flush_packets(void *opaque, void *user_data)
+{
+CompareState *s = user_data;
+Connection *conn = opaque;
+Packet *pkt = NULL;
+
+while (!g_queue_is_empty(>primary_list)) {
+pkt = g_queue_pop_head(>primary_list);
+compare_chr_send(>chr_out, pkt->data, pkt->size);
+packet_destroy(pkt, NULL);
+}
+while (!g_queue_is_empty(>secondary_list)) {
+pkt = g_queue_pop_head(>secondary_list);
+packet_destroy(pkt, NULL);
+}
+}
+
 static void colo_compare_class_init(ObjectClass *oc, void *data)
 {
 UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
@@ -703,14 +721,15 @@ static void colo_compare_finalize(Object *obj)
 qemu_chr_fe_deinit(>chr_sec_in);
 qemu_chr_fe_deinit(>chr_out);
 
-g_queue_free(>conn_list);
+g_main_loop_quit(s->compare_loop);
+qemu_thread_join(>thread);
 
-if (qemu_thread_is_self(>thread)) {
-/* compare connection */
-g_queue_foreach(>conn_list, colo_compare_connection, s);
-qemu_thread_join(>thread);
-}
+/* Release all unhandled packets after compare thead exited */
+g_queue_foreach(>conn_list, colo_flush_packets, s);
+
+g_queue_free(>conn_list);
 
+g_hash_table_destroy(s->connection_track_table);
 g_free(s->pri_indev);
 g_free(s->sec_indev);
 g_free(s->outdev);
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH] net: Remove useless local var pkt

[Jason Wang]

On 2017年02月15日 16:58, Dmitry Fleytman wrote:

Reviewed-by: Dmitry Fleytman 

This patch also fixes compilation with NET_RX_PKT_DEBUG defined.


On 15 Feb 2017, at 10:31 AM, Fam Zheng  wrote:

This has been pointless since commit 605d52e62, which was a
search-and-replace, overlooked the redundancy.

Signed-off-by: Fam Zheng 
---
hw/net/net_rx_pkt.c | 1 -
1 file changed, 1 deletion(-)

diff --git a/hw/net/net_rx_pkt.c b/hw/net/net_rx_pkt.c
index 1019b50..7f928d7 100644
--- a/hw/net/net_rx_pkt.c
+++ b/hw/net/net_rx_pkt.c
@@ -159,7 +159,6 @@ void net_rx_pkt_attach_iovec_ex(struct NetRxPkt *pkt,
void net_rx_pkt_dump(struct NetRxPkt *pkt)
{
#ifdef NET_RX_PKT_DEBUG
-NetRxPkt *pkt = (NetRxPkt *)pkt;
 assert(pkt);

 printf("RX PKT: tot_len: %d, vlan_stripped: %d, vlan_tag: %d\n",
--
2.9.3



Applied, thanks.

Re: [Qemu-devel] [PATCH RFC v2 03/12] s390x/css: add s390-map-css machine option

[Dong Jia Shi]

* Dong Jia Shi  [2017-01-12 08:25:04 +0100]:

> From: Xiao Feng Ren 
> 
> We want to support real (i.e. not virtual) channel devices
> even for guests that do not support MCSS-E (where guests may
> see devices from any channel subsystem image at once). As all
> virtio-ccw devices are in css 0xfe (and show up in the default
> css 0 for guests not activating MCSS-E), we need an option to
> map e.g. passed-through subchannels from their real css (0-3,
> or 0 for hosts not activating MCSS-E) into the default css.
> This will be exploited in a later patch.

After some brainstorming, we decided to change this interface a bit.

The first thing is that, we agreed that "s390-squash-mcss" is a better
name than "s390-map-css". The new name denotes that it is trying to
accommodate the devices from multiple channel subsystems into a
non-mcsse-e system, and the word "suqash" is more accurate about what
is happening internally.

The second thing is, we should never map/squash a vfio-ccw device into
css 0xfe, which is reserved for virtio device only. So when squashing,
we need to do it the other way around (i.e. have virtio devices at
0.x. instead of fe.x. to accommodate non-mcsse-e).

> 
> Signed-off-by: Xiao Feng Ren 
[...]

-- 
Dong Jia

Re: [Qemu-devel] [PATCH 1/2] Update README to accomodate markdown format

[Nir Soffer]

On Fri, Feb 17, 2017 at 2:54 AM, Pranith Kumar  wrote:
> Signed-off-by: Pranith Kumar 
> ---
>  README | 44 +---
>  1 file changed, 21 insertions(+), 23 deletions(-)
>
> diff --git a/README b/README
> index cb60d05bee..225afd6be7 100644
> --- a/README
> +++ b/README
> @@ -1,5 +1,5 @@
> - QEMU README
> - ===
> +QEMU
> +
>
>  QEMU is a generic and open source machine & userspace emulator and
>  virtualizer.
> @@ -31,22 +31,22 @@ version 2. For full licensing details, consult the 
> LICENSE file.
>
>
>  Building
> -
> +
>
>  QEMU is multi-platform software intended to be buildable on all modern
>  Linux platforms, OS-X, Win32 (via the Mingw64 toolchain) and a variety
>  of other UNIX targets. The simple steps to build QEMU are:
>
> -  mkdir build
> -  cd build
> -  ../configure
> -  make
> +mkdir build
> +cd build
> +../configure
> +make
>
>  Additional information can also be found online via the QEMU website:
>
> -  http://qemu-project.org/Hosts/Linux
> -  http://qemu-project.org/Hosts/Mac
> -  http://qemu-project.org/Hosts/W32
> +  - http://qemu-project.org/Hosts/Linux
> +  - http://qemu-project.org/Hosts/Mac
> +  - http://qemu-project.org/Hosts/W32
>
>
>  Submitting patches

You missed this title

> @@ -54,7 +54,7 @@ Submitting patches
>
>  The QEMU source code is maintained under the GIT version control system.
>
> -   git clone git://git.qemu-project.org/qemu.git
> +git clone git://git.qemu-project.org/qemu.git
>
>  When submitting patches, the preferred approach is to use 'git
>  format-patch' and/or 'git send-email' to format & send the mail to the
> @@ -65,18 +65,18 @@ guidelines set out in the HACKING and CODING_STYLE files.
>  Additional information on submitting patches can be found online via
>  the QEMU website
>
> -  http://qemu-project.org/Contribute/SubmitAPatch
> -  http://qemu-project.org/Contribute/TrivialPatches
> +  - http://qemu-project.org/Contribute/SubmitAPatch
> +  - http://qemu-project.org/Contribute/TrivialPatches
>
>
>  Bug reporting
> -=
> +-
>
>  The QEMU project uses Launchpad as its primary upstream bug tracker. Bugs
>  found when running code built from QEMU git or upstream released sources
>  should be reported via:
>
> -  https://bugs.launchpad.net/qemu/
> +  - https://bugs.launchpad.net/qemu/
>
>  If using QEMU via an operating system vendor pre-built binary package, it
>  is preferable to report bugs to the vendor's own bug tracker first. If
> @@ -85,22 +85,20 @@ reported via launchpad.
>
>  For additional information on bug reporting consult:
>
> -  http://qemu-project.org/Contribute/ReportABug
> +  - http://qemu-project.org/Contribute/ReportABug
>
>
>  Contact
> -===
> +---
>
>  The QEMU community can be contacted in a number of ways, with the two
>  main methods being email and IRC
>
> - - qemu-devel@nongnu.org
> -   http://lists.nongnu.org/mailman/listinfo/qemu-devel
> - - #qemu on irc.oftc.net
> + - Mailing List: qemu-devel@nongnu.org
> + - Archives: http://lists.nongnu.org/mailman/listinfo/qemu-devel
> + - IRC: #qemu on irc.oftc.net
>
>  Information on additional methods of contacting the community can be
>  found online via the QEMU website:
>
> -  http://qemu-project.org/Contribute/StartHere
> -
> --- End
> +  - http://qemu-project.org/Contribute/StartHere

Much nicer now!

Nir

[Qemu-devel] [PATCH 2/2] Create README.md as a symlink to README

[Pranith Kumar]

Signed-off-by: Pranith Kumar 
---
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 12 README.md

diff --git a/README.md b/README.md
new file mode 12
index 00..100b93820a
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+README
\ No newline at end of file
-- 
2.11.0

[Qemu-devel] [PATCH 1/3] qemu-img: Add tests for raw image preallocation

[Nir Soffer]

Add tests for creating raw image with and without the preallocation
option.

Signed-off-by: Nir Soffer 
---
 tests/qemu-iotests/175 | 61 ++
 tests/qemu-iotests/175.out | 18 ++
 tests/qemu-iotests/group   |  1 +
 3 files changed, 80 insertions(+)
 create mode 100755 tests/qemu-iotests/175
 create mode 100644 tests/qemu-iotests/175.out

diff --git a/tests/qemu-iotests/175 b/tests/qemu-iotests/175
new file mode 100755
index 000..ca56e82
--- /dev/null
+++ b/tests/qemu-iotests/175
@@ -0,0 +1,61 @@
+#!/bin/bash
+#
+# Test creating raw image preallocation mode
+#
+# Copyright (C) 2017 Nir Soffer 
+#
+# 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=nir...@gmail.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+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 raw
+_supported_proto file
+_supported_os Linux
+
+size=1m
+
+echo
+echo "== creating image with default preallocation =="
+_make_test_img $size | _filter_imgfmt
+stat -c "size=%s, blocks=%b" $TEST_IMG
+
+for mode in off full falloc; do
+echo
+echo "== creating image with preallocation $mode =="
+IMGOPTS=preallocation=$mode _make_test_img $size | _filter_imgfmt
+stat -c "size=%s, blocks=%b" $TEST_IMG
+done
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/175.out b/tests/qemu-iotests/175.out
new file mode 100644
index 000..76c02c6
--- /dev/null
+++ b/tests/qemu-iotests/175.out
@@ -0,0 +1,18 @@
+QA output created by 175
+
+== creating image with default preallocation ==
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576
+size=1048576, blocks=0
+
+== creating image with preallocation off ==
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 preallocation=off
+size=1048576, blocks=0
+
+== creating image with preallocation full ==
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 preallocation=full
+size=1048576, blocks=2048
+
+== creating image with preallocation falloc ==
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 preallocation=falloc
+size=1048576, blocks=2048
+ *** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 985b9a6..1f4bf03 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -167,3 +167,4 @@
 172 auto
 173 rw auto
 174 auto
+175 auto quick
-- 
2.9.3

[Qemu-devel] [PATCH 1/2] Update README to accomodate markdown format

[Pranith Kumar]

Signed-off-by: Pranith Kumar 
---
 README | 44 +---
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/README b/README
index cb60d05bee..225afd6be7 100644
--- a/README
+++ b/README
@@ -1,5 +1,5 @@
- QEMU README
- ===
+QEMU
+
 
 QEMU is a generic and open source machine & userspace emulator and
 virtualizer.
@@ -31,22 +31,22 @@ version 2. For full licensing details, consult the LICENSE 
file.
 
 
 Building
-
+
 
 QEMU is multi-platform software intended to be buildable on all modern
 Linux platforms, OS-X, Win32 (via the Mingw64 toolchain) and a variety
 of other UNIX targets. The simple steps to build QEMU are:
 
-  mkdir build
-  cd build
-  ../configure
-  make
+mkdir build
+cd build
+../configure
+make
 
 Additional information can also be found online via the QEMU website:
 
-  http://qemu-project.org/Hosts/Linux
-  http://qemu-project.org/Hosts/Mac
-  http://qemu-project.org/Hosts/W32
+  - http://qemu-project.org/Hosts/Linux
+  - http://qemu-project.org/Hosts/Mac
+  - http://qemu-project.org/Hosts/W32
 
 
 Submitting patches
@@ -54,7 +54,7 @@ Submitting patches
 
 The QEMU source code is maintained under the GIT version control system.
 
-   git clone git://git.qemu-project.org/qemu.git
+git clone git://git.qemu-project.org/qemu.git
 
 When submitting patches, the preferred approach is to use 'git
 format-patch' and/or 'git send-email' to format & send the mail to the
@@ -65,18 +65,18 @@ guidelines set out in the HACKING and CODING_STYLE files.
 Additional information on submitting patches can be found online via
 the QEMU website
 
-  http://qemu-project.org/Contribute/SubmitAPatch
-  http://qemu-project.org/Contribute/TrivialPatches
+  - http://qemu-project.org/Contribute/SubmitAPatch
+  - http://qemu-project.org/Contribute/TrivialPatches
 
 
 Bug reporting
-=
+-
 
 The QEMU project uses Launchpad as its primary upstream bug tracker. Bugs
 found when running code built from QEMU git or upstream released sources
 should be reported via:
 
-  https://bugs.launchpad.net/qemu/
+  - https://bugs.launchpad.net/qemu/
 
 If using QEMU via an operating system vendor pre-built binary package, it
 is preferable to report bugs to the vendor's own bug tracker first. If
@@ -85,22 +85,20 @@ reported via launchpad.
 
 For additional information on bug reporting consult:
 
-  http://qemu-project.org/Contribute/ReportABug
+  - http://qemu-project.org/Contribute/ReportABug
 
 
 Contact
-===
+---
 
 The QEMU community can be contacted in a number of ways, with the two
 main methods being email and IRC
 
- - qemu-devel@nongnu.org
-   http://lists.nongnu.org/mailman/listinfo/qemu-devel
- - #qemu on irc.oftc.net
+ - Mailing List: qemu-devel@nongnu.org
+ - Archives: http://lists.nongnu.org/mailman/listinfo/qemu-devel
+ - IRC: #qemu on irc.oftc.net
 
 Information on additional methods of contacting the community can be
 found online via the QEMU website:
 
-  http://qemu-project.org/Contribute/StartHere
-
--- End
+  - http://qemu-project.org/Contribute/StartHere
-- 
2.11.0

[Qemu-devel] [PATCH 3/3] qemu-img: Improve documentation for PREALLOC_MODE_FALLOC

[Nir Soffer]

Now that we are truncating the file in both PREALLOC_MODE_FULL and
PREALLOC_MODE_OFF, not truncating in PREALLOC_MODE_FALLOC looks odd.
Add a comment explaining why we do not truncate in this case.

Signed-off-by: Nir Soffer 
---
 block/file-posix.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index d24e34b..20a261f 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1594,9 +1594,14 @@ static int raw_create(const char *filename, QemuOpts 
*opts, Error **errp)
 switch (prealloc) {
 #ifdef CONFIG_POSIX_FALLOCATE
 case PREALLOC_MODE_FALLOC:
-/* posix_fallocate() doesn't set errno. */
+/*
+ * Truncating before posix_fallocate() makes it about twice slower on
+ * file systems that do not support fallocate(), trying to check if a
+ * block is allocated before allocating it.
+ */
 result = -posix_fallocate(fd, 0, total_size);
 if (result != 0) {
+/* posix_fallocate() doesn't set errno. */
 error_setg_errno(errp, -result,
  "Could not preallocate data for the new file");
 }
-- 
2.9.3

[Qemu-devel] [PATCH 0/2] Add mardown formatting to README

[Pranith Kumar]

Also create README.md as a symlink to README so that github displays
markdown.

Update the README file to markdown so that it makes the github page
look prettier. I know that github repo is a mirror and not the
official repo, but I think it doesn't hurt to have it in markdown
format.

The last time we tried, it caused issues for building installers and
the check patch. Creating a symlink will hopefully avoid those.

To compare, you can take a look at the following links:

old: https://github.com/pranith/qemu/
new: https://github.com/pranith/qemu/tree/readme

Pranith Kumar (2):
  Update README to accomodate markdown format
  Create README.md as a symlink to README

 README| 44 +---
 README.md |  1 +
 2 files changed, 22 insertions(+), 23 deletions(-)
 create mode 12 README.md

-- 
2.11.0

[Qemu-devel] [PATCH 0/3] qemu-img raw preallocation

[Nir Soffer]

This series add missing tests for raw image preallocation, refine
preallocation=full and improve documentation.

Create on top of the commit 10ddfe7b6044 (qemu-img: Do not truncate
before preallocation) from Kevin block branch.

Nir Soffer (3):
  qemu-img: Add tests for raw image preallocation
  qemu-img: Truncate before full preallocation
  qemu-img: Improve documentation for PREALLOC_MODE_FALLOC

 block/file-posix.c | 19 ++-
 tests/qemu-iotests/175 | 61 ++
 tests/qemu-iotests/175.out | 18 ++
 tests/qemu-iotests/group   |  1 +
 4 files changed, 98 insertions(+), 1 deletion(-)
 create mode 100755 tests/qemu-iotests/175
 create mode 100644 tests/qemu-iotests/175.out

-- 
2.9.3

[Qemu-devel] [PATCH 2/3] qemu-img: Truncate before full preallocation

[Nir Soffer]

In commit 10ddfe7b6044 (qemu-img: Do not truncate before preallocation)
we moved truncate to the PREALLOC_MODE_OFF branch to avoid slowdown in
posix_fallocate().

However this change is not optimal when using PREALLOC_MODE_FULL, since
knowing the final size from the beginning could allow the file system
driver to do less allocations and possibly avoid fragmentation of the
file.

Now we truncate also before doing full preallocation.

Signed-off-by: Nir Soffer 
---
 block/file-posix.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/block/file-posix.c b/block/file-posix.c
index 442f080..d24e34b 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1604,6 +1604,17 @@ static int raw_create(const char *filename, QemuOpts 
*opts, Error **errp)
 #endif
 case PREALLOC_MODE_FULL:
 {
+/*
+ * Knowing the final size from the beginning could allow the file
+ * system driver to do less allocations and possibly avoid
+ * fragmentation of the file.
+ */
+if (ftruncate(fd, total_size) != 0) {
+result = -errno;
+error_setg_errno(errp, -result, "Could not resize file");
+goto out_close;
+}
+
 int64_t num = 0, left = total_size;
 buf = g_malloc0(65536);
 
@@ -1642,6 +1653,7 @@ static int raw_create(const char *filename, QemuOpts 
*opts, Error **errp)
 break;
 }
 
+out_close:
 if (qemu_close(fd) != 0 && result == 0) {
 result = -errno;
 error_setg_errno(errp, -result, "Could not close the new file");
-- 
2.9.3

Re: [Qemu-devel] [PATCH] syscall: fixed mincore(2) not failing with ENOMEM

[Fam Zheng]

On Thu, 02/16 08:58, Franklin Snaipe Mathieu wrote:
> +p = lock_user_string(arg3)
> +if (!p) {

Please compile test at least, even if it is a trivial patch.

Fam

Re: [Qemu-devel] Fix build break during configuration on musl-libc based system

[Felix Janda]

Defining _GNU_SOURCE causes musl to define everything including
everything protected by _XOPEN_SOURCE. However it does not cause
musl to define _XOPEN_SOURCE.

On the other hand, the ncurses header specifically checks for
_XOPEN_SOURCE or _XOPEN_SOURCE_EXTENDED.

So it is not completely clear where this should be fixed.

-- Felix

[Qemu-devel] [PATCH v8 4/8] ACPI: Add Virtual Machine Generation ID support

[ben]

From: Ben Warren 

This implements the VM Generation ID feature by passing a 128-bit
GUID to the guest via a fw_cfg blob.
Any time the GUID changes, an ACPI notify event is sent to the guest

The user interface is a simple device with one parameter:
 - guid (string, must be "auto" or in UUID format
   ----)

Signed-off-by: Ben Warren 
Reviewed-by: Igor Mammedov 
Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 
---
 default-configs/i386-softmmu.mak |   1 +
 default-configs/x86_64-softmmu.mak   |   1 +
 hw/acpi/Makefile.objs|   1 +
 hw/acpi/vmgenid.c| 242 +++
 hw/i386/acpi-build.c |  16 +++
 include/hw/acpi/acpi_dev_interface.h |   1 +
 include/hw/acpi/vmgenid.h|  35 +
 7 files changed, 297 insertions(+)
 create mode 100644 hw/acpi/vmgenid.c
 create mode 100644 include/hw/acpi/vmgenid.h

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 48b07a4..029e952 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -59,3 +59,4 @@ CONFIG_I82801B11=y
 CONFIG_SMBIOS=y
 CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
 CONFIG_PXB=y
+CONFIG_ACPI_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index fd96345..d1d7432 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -59,3 +59,4 @@ CONFIG_I82801B11=y
 CONFIG_SMBIOS=y
 CONFIG_HYPERV_TESTDEV=$(CONFIG_KVM)
 CONFIG_PXB=y
+CONFIG_ACPI_VMGENID=y
diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index 6acf798..11c35bc 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -5,6 +5,7 @@ common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu_hotplug.o
 common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o
 common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu.o
 common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
+common-obj-$(CONFIG_ACPI_VMGENID) += vmgenid.o
 common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
 
 common-obj-y += acpi_interface.o
diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
new file mode 100644
index 000..c8465df
--- /dev/null
+++ b/hw/acpi/vmgenid.c
@@ -0,0 +1,242 @@
+/*
+ *  Virtual Machine Generation ID Device
+ *
+ *  Copyright (C) 2017 Skyport Systems.
+ *
+ *  Author: Ben Warren 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qmp-commands.h"
+#include "hw/acpi/acpi.h"
+#include "hw/acpi/aml-build.h"
+#include "hw/acpi/vmgenid.h"
+#include "hw/nvram/fw_cfg.h"
+#include "sysemu/sysemu.h"
+
+void vmgenid_build_acpi(VmGenIdState *vms, GArray *table_data, GArray *guid,
+BIOSLinker *linker)
+{
+Aml *ssdt, *dev, *scope, *method, *addr, *if_ctx;
+uint32_t vgia_offset;
+QemuUUID guid_le;
+
+/* Fill in the GUID values.  These need to be converted to little-endian
+ * first, since that's what the guest expects
+ */
+g_array_set_size(guid, VMGENID_FW_CFG_SIZE - ARRAY_SIZE(guid_le.data));
+guid_le = vms->guid;
+qemu_uuid_bswap(_le);
+/* The GUID is written at a fixed offset into the fw_cfg file
+ * in order to implement the "OVMF SDT Header probe suppressor"
+ * see docs/specs/vmgenid.txt for more details
+ */
+g_array_insert_vals(guid, VMGENID_GUID_OFFSET, guid_le.data,
+ARRAY_SIZE(guid_le.data));
+
+/* Put this in a separate SSDT table */
+ssdt = init_aml_allocator();
+
+/* Reserve space for header */
+acpi_data_push(ssdt->buf, sizeof(AcpiTableHeader));
+
+/* Storage for the GUID address */
+vgia_offset = table_data->len +
+build_append_named_dword(ssdt->buf, "VGIA");
+scope = aml_scope("\\_SB");
+dev = aml_device("VGEN");
+aml_append(dev, aml_name_decl("_HID", aml_string("QEMUVGID")));
+aml_append(dev, aml_name_decl("_CID", aml_string("VM_Gen_Counter")));
+aml_append(dev, aml_name_decl("_DDN", aml_string("VM_Gen_Counter")));
+
+/* Simple status method to check that address is linked and non-zero */
+method = aml_method("_STA", 0, AML_NOTSERIALIZED);
+addr = aml_local(0);
+aml_append(method, aml_store(aml_int(0xf), addr));
+if_ctx = aml_if(aml_equal(aml_name("VGIA"), aml_int(0)));
+aml_append(if_ctx, aml_store(aml_int(0), addr));
+aml_append(method, if_ctx);
+aml_append(method, aml_return(addr));
+aml_append(dev, method);
+
+/* the ADDR method returns two 32-bit words representing the lower and
+ * upper halves * of the physical address of the fw_cfg blob
+ * (holding the GUID)
+ */
+method = aml_method("ADDR", 0, AML_NOTSERIALIZED);
+
+addr = aml_local(0);
+aml_append(method, 

[Qemu-devel] [PATCH v8 0/8] Add support for VM Generation ID

[ben]

From: Ben Warren 

This patch set adds support for passing a GUID to Windows guests.  It is a
re-implementation of previous patch sets written by Igor Mammedov et al, but
this time passing the GUID data as a fw_cfg blob.

This patch set has dependencies on new guest functionality, in particular the
support for a new linker-loader command and the ability to write back data
to QEMU over a DMA link.  Work is in flight in both SeaBIOS and OVMF to support 
this.

v7->v8:
- Rebased to top of tree.
- Fixed two small bugs in "write pointer" function
- minor re-ordering of data in patches
- Fixed unit test by adding delays/retries to reading RSDP table

v6->v7:
- Rebased to top of tree.
- Added 'src_offset' field to "write pointer" command
- Reworked unit tests based on feedback
- various minor changes based on feedback
- Added entries to MAINTAINERS file

v5->v6:
- Rebased to top of tree.
- Changed device from sysbus to a simple device.  This removed the need for
  adding dynamic sysbus support to pc_piix boards.
- Removed patch that introduced QWORD patching of AML.
- Removed ability to set GUID via QMP/HMP.
- Improved comments/documentation in code.

v4->v5:
- Added significantly more detail to the documentation.
- Replaced the previously-implemented linker-loader command with a new one:
  "write pointer".  This allows writing the guest address of a fw_cfg blob 
back
  to an arbitrary offset in a writeable fw_cfg file visible to QEMU.  This 
will
  require support in SeaBIOS and OVMF (ongoing).
- Fixed endianness issues throughout.
- Several styling cleanups.

v3->v4:
- Rebased to top of tree.
- Re-added document patch that was accidentally dropped from the last 
revision.
- Added VMState functionality so that VGIA is restored properly.
- Added Unit tests
v2->v3:
- Added second writeable fw_cfg for storing the VM Generaiton ID
  address.  This uses a new linker-loader command for instructing the
  guest to write back the allocated address.  A patch for SeaBIOS has been
  submitted 
(https://www.seabios.org/pipermail/seabios/2017-January/011079.html)
  and the resulting binary will need to be pulled into QEMU once accepted.
- Setting VM Generation ID by command line or qmp/hmp now accepts an "auto"
  value, whereby QEMU generates a random GUID.
- Incorporated review comments from v2 mainly around code styling and AML 
syntax
- Changed to use the E05 ACPI event instead of E00
v1->v2:
- Removed "changed" boolean parameter as it is unneeded
- Added ACPI Notify logic
- Style changes to pass checkpatch.pl
- Added support for dynamic sysbus to pc_piix boards


Ben Warren (7):
  linker-loader: Add new 'write pointer' command
  docs: VM Generation ID device description
  ACPI: Add vmgenid blob storage to the build tables
  ACPI: Add Virtual Machine Generation ID support
  tests: Move reusable ACPI code into a utility file
  tests: Add unit tests for the VM Generation ID feature
  MAINTAINERS: Add VM Generation ID entries

Igor Mammedov (1):
  qmp/hmp: add query-vm-generation-id and 'info vm-generation-id'
commands

 MAINTAINERS  |  11 ++
 default-configs/i386-softmmu.mak |   1 +
 default-configs/x86_64-softmmu.mak   |   1 +
 docs/specs/vmgenid.txt   | 245 +
 hmp-commands-info.hx |  14 ++
 hmp.c|   9 ++
 hmp.h|   1 +
 hw/acpi/Makefile.objs|   1 +
 hw/acpi/aml-build.c  |   2 +
 hw/acpi/bios-linker-loader.c |  66 -
 hw/acpi/vmgenid.c| 258 +++
 hw/i386/acpi-build.c |  16 +++
 include/hw/acpi/acpi_dev_interface.h |   1 +
 include/hw/acpi/aml-build.h  |   1 +
 include/hw/acpi/bios-linker-loader.h |   7 +
 include/hw/acpi/vmgenid.h|  35 +
 qapi-schema.json |  20 +++
 stubs/Makefile.objs  |   1 +
 stubs/vmgenid.c  |   9 ++
 tests/Makefile.include   |   4 +-
 tests/acpi-utils.c   |  65 +
 tests/acpi-utils.h   |  94 +
 tests/bios-tables-test.c | 132 ++
 tests/vmgenid-test.c | 200 +++
 24 files changed, 1073 insertions(+), 121 deletions(-)
 create mode 100644 docs/specs/vmgenid.txt
 create mode 100644 hw/acpi/vmgenid.c
 create mode 100644 include/hw/acpi/vmgenid.h
 create mode 100644 stubs/vmgenid.c
 create mode 100644 tests/acpi-utils.c
 create mode 100644 tests/acpi-utils.h
 create mode 100644 tests/vmgenid-test.c

-- 
2.7.4

[Qemu-devel] [PATCH v8 7/8] tests: Add unit tests for the VM Generation ID feature

[ben]

From: Ben Warren 

The following tests are implemented:
* test that a GUID passed in by command line is propagated to the guest.
  Read the GUID from guest memory
* test that the "auto" argument to the GUID generates a valid GUID, as
  seen by the guest.
* test that a GUID passed in can be queried from the monitor

  This patch is loosely based on a previous patch from:
  Gal Hammer   and Igor Mammedov 

Signed-off-by: Ben Warren 
---
 tests/Makefile.include |   2 +
 tests/vmgenid-test.c   | 200 +
 2 files changed, 202 insertions(+)
 create mode 100644 tests/vmgenid-test.c

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 143507e..8d36341 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -241,6 +241,7 @@ check-qtest-i386-y += tests/usb-hcd-xhci-test$(EXESUF)
 gcov-files-i386-y += hw/usb/hcd-xhci.c
 check-qtest-i386-y += tests/pc-cpu-test$(EXESUF)
 check-qtest-i386-y += tests/q35-test$(EXESUF)
+check-qtest-i386-y += tests/vmgenid-test$(EXESUF)
 gcov-files-i386-y += hw/pci-host/q35.c
 check-qtest-i386-$(CONFIG_VHOST_NET_TEST_i386) += 
tests/vhost-user-test$(EXESUF)
 ifeq ($(CONFIG_VHOST_NET_TEST_i386),)
@@ -726,6 +727,7 @@ tests/ivshmem-test$(EXESUF): tests/ivshmem-test.o 
contrib/ivshmem-server/ivshmem
 tests/vhost-user-bridge$(EXESUF): tests/vhost-user-bridge.o 
contrib/libvhost-user/libvhost-user.o $(test-util-obj-y)
 tests/test-uuid$(EXESUF): tests/test-uuid.o $(test-util-obj-y)
 tests/test-arm-mptimer$(EXESUF): tests/test-arm-mptimer.o
+tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o tests/acpi-utils.o
 
 tests/migration/stress$(EXESUF): tests/migration/stress.o
$(call quiet-command, $(LINKPROG) -static -O3 $(PTHREAD_LIB) -o $@ $< 
,"LINK","$(TARGET_DIR)$@")
diff --git a/tests/vmgenid-test.c b/tests/vmgenid-test.c
new file mode 100644
index 000..123beae
--- /dev/null
+++ b/tests/vmgenid-test.c
@@ -0,0 +1,200 @@
+/*
+ * QTest testcase for VM Generation ID
+ *
+ * Copyright (c) 2016 Red Hat, Inc.
+ * Copyright (c) 2017 Skyport Systems
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include 
+#include 
+#include 
+#include "qemu/osdep.h"
+#include "qemu/bitmap.h"
+#include "qemu/uuid.h"
+#include "hw/acpi/acpi-defs.h"
+#include "acpi-utils.h"
+#include "libqtest.h"
+
+#define VGID_GUID "324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87"
+#define VMGENID_GUID_OFFSET 40   /* allow space for
+  * OVMF SDT Header Probe Supressor
+  */
+#define RSDP_ADDR_INVALID 0x10 /* RSDP must be below this address */
+#define RSDP_SLEEP_US 10   /* Sleep for 100ms between tries */
+#define RSDP_TRIES_MAX100  /* Max total time is 10 seconds */
+
+typedef struct {
+AcpiTableHeader header;
+gchar name_op;
+gchar vgia[4];
+gchar val_op;
+uint32_t vgia_val;
+} QEMU_PACKED VgidTable;
+
+static uint32_t acpi_find_vgia(void)
+{
+uint32_t off;
+AcpiRsdpDescriptor rsdp_table;
+uint32_t rsdt;
+AcpiRsdtDescriptorRev1 rsdt_table;
+int tables_nr;
+uint32_t *tables;
+AcpiTableHeader ssdt_table;
+VgidTable vgid_table;
+int i;
+
+/* Tables may take a short time to be set up by the guest */
+for (i = 0; i < RSDP_TRIES_MAX; i++) {
+off = acpi_find_rsdp_address();
+if (off < RSDP_ADDR_INVALID) {
+break;
+}
+g_usleep(RSDP_SLEEP_US);
+}
+g_assert_cmphex(off, <, RSDP_ADDR_INVALID);
+
+acpi_parse_rsdp_table(off, _table);
+
+rsdt = rsdp_table.rsdt_physical_address;
+/* read the header */
+ACPI_READ_TABLE_HEADER(_table, rsdt);
+ACPI_ASSERT_CMP(rsdt_table.signature, "RSDT");
+
+/* compute the table entries in rsdt */
+tables_nr = (rsdt_table.length - sizeof(AcpiRsdtDescriptorRev1)) /
+sizeof(uint32_t);
+g_assert_cmpint(tables_nr, >, 0);
+
+/* get the addresses of the tables pointed by rsdt */
+tables = g_new0(uint32_t, tables_nr);
+ACPI_READ_ARRAY_PTR(tables, tables_nr, rsdt);
+
+for (i = 0; i < tables_nr; i++) {
+ACPI_READ_TABLE_HEADER(_table, tables[i]);
+if (!strncmp((char *)ssdt_table.oem_table_id, "VMGENID", 7)) {
+/* the first entry in the table should be VGIA
+ * That's all we need
+ */
+ACPI_READ_FIELD(vgid_table.name_op, tables[i]);
+g_assert(vgid_table.name_op == 0x08);  /* name */
+ACPI_READ_ARRAY(vgid_table.vgia, tables[i]);
+g_assert(memcmp(vgid_table.vgia, "VGIA", 4) == 0);
+ACPI_READ_FIELD(vgid_table.val_op, tables[i]);
+g_assert(vgid_table.val_op == 0x0C);  /* dword */
+ACPI_READ_FIELD(vgid_table.vgia_val, tables[i]);
+/* The GUID is written at a fixed offset into 

[Qemu-devel] [PATCH v8 6/8] tests: Move reusable ACPI code into a utility file

[ben]

From: Ben Warren 

Also usable by upcoming VM Generation ID tests

Signed-off-by: Ben Warren 
---
 MAINTAINERS  |   2 +
 tests/Makefile.include   |   2 +-
 tests/acpi-utils.c   |  65 +++
 tests/acpi-utils.h   |  94 +
 tests/bios-tables-test.c | 132 ++-
 5 files changed, 177 insertions(+), 118 deletions(-)
 create mode 100644 tests/acpi-utils.c
 create mode 100644 tests/acpi-utils.h

diff --git a/MAINTAINERS b/MAINTAINERS
index fb57d8e..81d4baf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -909,6 +909,8 @@ F: hw/acpi/*
 F: hw/smbios/*
 F: hw/i386/acpi-build.[hc]
 F: hw/arm/virt-acpi-build.c
+F: tests/bios-tables-test.c
+F: tests/acpi-utils.[hc]
 
 ppc4xx
 M: Alexander Graf 
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 634394a..143507e 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -667,7 +667,7 @@ tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o
 tests/boot-order-test$(EXESUF): tests/boot-order-test.o $(libqos-obj-y)
 tests/boot-serial-test$(EXESUF): tests/boot-serial-test.o $(libqos-obj-y)
 tests/bios-tables-test$(EXESUF): tests/bios-tables-test.o \
-   tests/boot-sector.o $(libqos-obj-y)
+   tests/boot-sector.o tests/acpi-utils.o $(libqos-obj-y)
 tests/pxe-test$(EXESUF): tests/pxe-test.o tests/boot-sector.o $(libqos-obj-y)
 tests/tmp105-test$(EXESUF): tests/tmp105-test.o $(libqos-omap-obj-y)
 tests/ds1338-test$(EXESUF): tests/ds1338-test.o $(libqos-imx-obj-y)
diff --git a/tests/acpi-utils.c b/tests/acpi-utils.c
new file mode 100644
index 000..41dc1ea
--- /dev/null
+++ b/tests/acpi-utils.c
@@ -0,0 +1,65 @@
+/*
+ * ACPI Utility Functions
+ *
+ * Copyright (c) 2013 Red Hat Inc.
+ * Copyright (c) 2017 Skyport Systems
+ *
+ * Authors:
+ *  Michael S. Tsirkin ,
+ *  Ben Warren 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include 
+#include "qemu-common.h"
+#include "hw/smbios/smbios.h"
+#include "qemu/bitmap.h"
+#include "acpi-utils.h"
+#include "boot-sector.h"
+
+uint8_t acpi_calc_checksum(const uint8_t *data, int len)
+{
+int i;
+uint8_t sum = 0;
+
+for (i = 0; i < len; i++) {
+sum += data[i];
+}
+
+return sum;
+}
+
+uint32_t acpi_find_rsdp_address(void)
+{
+uint32_t off;
+
+/* RSDP location can vary across a narrow range */
+for (off = 0xf; off < 0x10; off += 0x10) {
+uint8_t sig[] = "RSD PTR ";
+int i;
+
+for (i = 0; i < sizeof sig - 1; ++i) {
+sig[i] = readb(off + i);
+}
+
+if (!memcmp(sig, "RSD PTR ", sizeof sig)) {
+break;
+}
+}
+return off;
+}
+
+void acpi_parse_rsdp_table(uint32_t addr, AcpiRsdpDescriptor *rsdp_table)
+{
+ACPI_READ_FIELD(rsdp_table->signature, addr);
+ACPI_ASSERT_CMP64(rsdp_table->signature, "RSD PTR ");
+
+ACPI_READ_FIELD(rsdp_table->checksum, addr);
+ACPI_READ_ARRAY(rsdp_table->oem_id, addr);
+ACPI_READ_FIELD(rsdp_table->revision, addr);
+ACPI_READ_FIELD(rsdp_table->rsdt_physical_address, addr);
+ACPI_READ_FIELD(rsdp_table->length, addr);
+}
diff --git a/tests/acpi-utils.h b/tests/acpi-utils.h
new file mode 100644
index 000..9f9a2d5
--- /dev/null
+++ b/tests/acpi-utils.h
@@ -0,0 +1,94 @@
+/*
+ * Utilities for working with ACPI tables
+ *
+ * Copyright (c) 2013 Red Hat Inc.
+ *
+ * Authors:
+ *  Michael S. Tsirkin ,
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef TEST_ACPI_UTILS_H
+#define TEST_ACPI_UTILS_H
+
+#include "hw/acpi/acpi-defs.h"
+#include "libqtest.h"
+
+/* DSDT and SSDTs format */
+typedef struct {
+AcpiTableHeader header;
+gchar *aml;/* aml bytecode from guest */
+gsize aml_len;
+gchar *aml_file;
+gchar *asl;/* asl code generated from aml */
+gsize asl_len;
+gchar *asl_file;
+bool tmp_files_retain;   /* do not delete the temp asl/aml */
+} QEMU_PACKED AcpiSdtTable;
+
+#define ACPI_READ_FIELD(field, addr)   \
+do {   \
+switch (sizeof(field)) {   \
+case 1:\
+field = readb(addr);   \
+break; \
+case 2:\
+field = readw(addr);   \
+break; \
+case 4:\
+field = readl(addr);   \
+break; \
+case 8:\
+field = readq(addr);  

[Qemu-devel] [PATCH v8 1/8] linker-loader: Add new 'write pointer' command

[ben]

From: Ben Warren 

This is similar to the existing 'add pointer' functionality, but instead
of instructing the guest (BIOS or UEFI) to patch memory, it instructs
the guest to write the pointer back to QEMU via a writeable fw_cfg file.

Signed-off-by: Ben Warren 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Igor Mammedov 
Tested-by: Laszlo Ersek 
---
 hw/acpi/bios-linker-loader.c | 66 ++--
 include/hw/acpi/bios-linker-loader.h |  7 
 2 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/hw/acpi/bios-linker-loader.c b/hw/acpi/bios-linker-loader.c
index d963ebe..046183a 100644
--- a/hw/acpi/bios-linker-loader.c
+++ b/hw/acpi/bios-linker-loader.c
@@ -78,6 +78,21 @@ struct BiosLinkerLoaderEntry {
 uint32_t length;
 } cksum;
 
+/*
+ * COMMAND_WRITE_POINTER - write the fw_cfg file (originating from
+ * @dest_file) at @wr_pointer.offset, by adding a pointer to
+ * @src_offset within the table originating from @src_file.
+ * 1,2,4 or 8 byte unsigned addition is used depending on
+ * @wr_pointer.size.
+ */
+struct {
+char dest_file[BIOS_LINKER_LOADER_FILESZ];
+char src_file[BIOS_LINKER_LOADER_FILESZ];
+uint32_t dst_offset;
+uint32_t src_offset;
+uint8_t size;
+} wr_pointer;
+
 /* padding */
 char pad[124];
 };
@@ -85,9 +100,10 @@ struct BiosLinkerLoaderEntry {
 typedef struct BiosLinkerLoaderEntry BiosLinkerLoaderEntry;
 
 enum {
-BIOS_LINKER_LOADER_COMMAND_ALLOCATE = 0x1,
-BIOS_LINKER_LOADER_COMMAND_ADD_POINTER  = 0x2,
-BIOS_LINKER_LOADER_COMMAND_ADD_CHECKSUM = 0x3,
+BIOS_LINKER_LOADER_COMMAND_ALLOCATE  = 0x1,
+BIOS_LINKER_LOADER_COMMAND_ADD_POINTER   = 0x2,
+BIOS_LINKER_LOADER_COMMAND_ADD_CHECKSUM  = 0x3,
+BIOS_LINKER_LOADER_COMMAND_WRITE_POINTER = 0x4,
 };
 
 enum {
@@ -278,3 +294,47 @@ void bios_linker_loader_add_pointer(BIOSLinker *linker,
 
 g_array_append_vals(linker->cmd_blob, , sizeof entry);
 }
+
+/*
+ * bios_linker_loader_write_pointer: ask guest to write a pointer to the
+ * source file into the destination file, and write it back to QEMU via
+ * fw_cfg DMA.
+ *
+ * @linker: linker object instance
+ * @dest_file: destination file that must be written
+ * @dst_patched_offset: location within destination file blob to be patched
+ *  with the pointer to @src_file, in bytes
+ * @dst_patched_offset_size: size of the pointer to be patched
+ *  at @dst_patched_offset in @dest_file blob, in bytes
+ * @src_file: source file who's address must be taken
+ * @src_offset: location within source file blob to which
+ *  @dest_file+@dst_patched_offset will point to after
+ *  firmware's executed WRITE_POINTER command
+ */
+void bios_linker_loader_write_pointer(BIOSLinker *linker,
+const char *dest_file,
+uint32_t dst_patched_offset,
+uint8_t dst_patched_size,
+const char *src_file,
+uint32_t src_offset)
+{
+BiosLinkerLoaderEntry entry;
+const BiosLinkerFileEntry *source_file =
+bios_linker_find_file(linker, src_file);
+
+assert(source_file);
+assert(src_offset < source_file->blob->len);
+memset(, 0, sizeof entry);
+strncpy(entry.wr_pointer.dest_file, dest_file,
+sizeof entry.wr_pointer.dest_file - 1);
+strncpy(entry.wr_pointer.src_file, src_file,
+sizeof entry.wr_pointer.src_file - 1);
+entry.command = cpu_to_le32(BIOS_LINKER_LOADER_COMMAND_WRITE_POINTER);
+entry.wr_pointer.dst_offset = cpu_to_le32(dst_patched_offset);
+entry.wr_pointer.src_offset = cpu_to_le32(src_offset);
+entry.wr_pointer.size = dst_patched_size;
+assert(dst_patched_size == 1 || dst_patched_size == 2 ||
+   dst_patched_size == 4 || dst_patched_size == 8);
+
+g_array_append_vals(linker->cmd_blob, , sizeof entry);
+}
diff --git a/include/hw/acpi/bios-linker-loader.h 
b/include/hw/acpi/bios-linker-loader.h
index fa1e5d1..efe17b0 100644
--- a/include/hw/acpi/bios-linker-loader.h
+++ b/include/hw/acpi/bios-linker-loader.h
@@ -26,5 +26,12 @@ void bios_linker_loader_add_pointer(BIOSLinker *linker,
 const char *src_file,
 uint32_t src_offset);
 
+void bios_linker_loader_write_pointer(BIOSLinker *linker,
+  const char *dest_file,
+  uint32_t dst_patched_offset,
+  uint8_t dst_patched_size,
+  const char *src_file,
+

[Qemu-devel] [PATCH v8 5/8] qmp/hmp: add query-vm-generation-id and 'info vm-generation-id' commands

[ben]

From: Igor Mammedov 

Add commands to query Virtual Machine Generation ID counter.

QMP command example:
{ "execute": "query-vm-generation-id" }

HMP command example:
info vm-generation-id

Signed-off-by: Igor Mammedov 
Reviewed-by: Eric Blake 
Signed-off-by: Ben Warren 
Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 
---
 hmp-commands-info.hx | 14 ++
 hmp.c|  9 +
 hmp.h|  1 +
 hw/acpi/vmgenid.c| 16 
 qapi-schema.json | 20 
 stubs/Makefile.objs  |  1 +
 stubs/vmgenid.c  |  9 +
 7 files changed, 70 insertions(+)
 create mode 100644 stubs/vmgenid.c

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index b0f35e6..a53f105 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -802,6 +802,20 @@ Show information about hotpluggable CPUs
 ETEXI
 
 STEXI
+@item info vm-generation-id
+@findex vm-generation-id
+Show Virtual Machine Generation ID
+ETEXI
+
+{
+.name   = "vm-generation-id",
+.args_type  = "",
+.params = "",
+.help   = "Show Virtual Machine Generation ID",
+.cmd = hmp_info_vm_generation_id,
+},
+
+STEXI
 @end table
 ETEXI
 
diff --git a/hmp.c b/hmp.c
index 2bc4f06..535613d 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2565,3 +2565,12 @@ void hmp_hotpluggable_cpus(Monitor *mon, const QDict 
*qdict)
 
 qapi_free_HotpluggableCPUList(saved);
 }
+
+void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict)
+{
+GuidInfo *info = qmp_query_vm_generation_id(NULL);
+if (info) {
+monitor_printf(mon, "%s\n", info->guid);
+}
+qapi_free_GuidInfo(info);
+}
diff --git a/hmp.h b/hmp.h
index 05daf7c..799fd37 100644
--- a/hmp.h
+++ b/hmp.h
@@ -137,5 +137,6 @@ void hmp_rocker_of_dpa_flows(Monitor *mon, const QDict 
*qdict);
 void hmp_rocker_of_dpa_groups(Monitor *mon, const QDict *qdict);
 void hmp_info_dump(Monitor *mon, const QDict *qdict);
 void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict);
+void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
index c8465df..744f284 100644
--- a/hw/acpi/vmgenid.c
+++ b/hw/acpi/vmgenid.c
@@ -240,3 +240,19 @@ static void vmgenid_register_types(void)
 }
 
 type_init(vmgenid_register_types)
+
+GuidInfo *qmp_query_vm_generation_id(Error **errp)
+{
+GuidInfo *info;
+VmGenIdState *vms;
+Object *obj = find_vmgenid_dev();
+
+if (!obj) {
+return NULL;
+}
+vms = VMGENID(obj);
+
+info = g_malloc0(sizeof(*info));
+info->guid = qemu_uuid_unparse_strdup(>guid);
+return info;
+}
diff --git a/qapi-schema.json b/qapi-schema.json
index 5edb08d..396e49c 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -6056,3 +6056,23 @@
 #
 ##
 { 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }
+
+##
+# @GuidInfo:
+#
+# GUID information.
+#
+# @guid: the globally unique identifier
+#
+# Since: 2.9
+##
+{ 'struct': 'GuidInfo', 'data': {'guid': 'str'} }
+
+##
+# @query-vm-generation-id:
+#
+# Show Virtual Machine Generation ID
+#
+# Since 2.9
+##
+{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index a187295..0bffca6 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -35,3 +35,4 @@ stub-obj-y += qmp_pc_dimm_device_list.o
 stub-obj-y += target-monitor-defs.o
 stub-obj-y += target-get-monitor-def.o
 stub-obj-y += pc_madt_cpu_entry.o
+stub-obj-y += vmgenid.o
diff --git a/stubs/vmgenid.c b/stubs/vmgenid.c
new file mode 100644
index 000..c64eb7a
--- /dev/null
+++ b/stubs/vmgenid.c
@@ -0,0 +1,9 @@
+#include "qemu/osdep.h"
+#include "qmp-commands.h"
+#include "qapi/qmp/qerror.h"
+
+GuidInfo *qmp_query_vm_generation_id(Error **errp)
+{
+error_setg(errp, QERR_UNSUPPORTED);
+return NULL;
+}
-- 
2.7.4

[Qemu-devel] [PATCH v8 8/8] MAINTAINERS: Add VM Generation ID entries

[ben]

From: Ben Warren 

Signed-off-by: Ben Warren 
Reviewed-by: Laszlo Ersek 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 81d4baf..8f5dd35 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1125,6 +1125,15 @@ F: hw/nvram/chrp_nvram.c
 F: include/hw/nvram/chrp_nvram.h
 F: tests/prom-env-test.c
 
+VM Generation ID
+M: Ben Warren 
+S: Maintained
+F: hw/acpi/vmgenid.c
+F: include/hw/acpi/vmgenid.h
+F: docs/specs/vmgenid.txt
+F: tests/vmgenid-test.c
+F: stubs/vmgenid.c
+
 Subsystems
 --
 Audio
-- 
2.7.4

[Qemu-devel] [PATCH v8 3/8] ACPI: Add vmgenid blob storage to the build tables

[ben]

From: Ben Warren 

This allows them to be centrally initialized and destroyed

The "AcpiBuildTables.vmgenid" array will be used to construct the
"etc/vmgenid_guid" fw_cfg blob.

Its contents will be linked into fw_cfg after being built on the
pc_machine_done() -> acpi_setup() -> acpi_build() call path, and dropped
without use on the subsequent, guest triggered, acpi_build_update() ->
acpi_build() call path.

Signed-off-by: Ben Warren 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Igor Mammedov 
Tested-by: Laszlo Ersek 
---
 hw/acpi/aml-build.c | 2 ++
 include/hw/acpi/aml-build.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index b2a1e40..c6f2032 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -1559,6 +1559,7 @@ void acpi_build_tables_init(AcpiBuildTables *tables)
 tables->rsdp = g_array_new(false, true /* clear */, 1);
 tables->table_data = g_array_new(false, true /* clear */, 1);
 tables->tcpalog = g_array_new(false, true /* clear */, 1);
+tables->vmgenid = g_array_new(false, true /* clear */, 1);
 tables->linker = bios_linker_loader_init();
 }
 
@@ -1568,6 +1569,7 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, 
bool mfre)
 g_array_free(tables->rsdp, true);
 g_array_free(tables->table_data, true);
 g_array_free(tables->tcpalog, mfre);
+g_array_free(tables->vmgenid, mfre);
 }
 
 /* Build rsdt table */
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 559326c..00c21f1 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -210,6 +210,7 @@ struct AcpiBuildTables {
 GArray *table_data;
 GArray *rsdp;
 GArray *tcpalog;
+GArray *vmgenid;
 BIOSLinker *linker;
 } AcpiBuildTables;
 
-- 
2.7.4

[Qemu-devel] [PATCH v8 2/8] docs: VM Generation ID device description

[ben]

From: Ben Warren 

This patch is based off an earlier version by
Gal Hammer (gham...@redhat.com)

Requirements section, ASCII diagrams and overall help
provided by Laszlo Ersek (ler...@redhat.com)

Signed-off-by: Gal Hammer 
Signed-off-by: Ben Warren 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Igor Mammedov 
---
 docs/specs/vmgenid.txt | 245 +
 1 file changed, 245 insertions(+)
 create mode 100644 docs/specs/vmgenid.txt

diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt
new file mode 100644
index 000..aa9f518
--- /dev/null
+++ b/docs/specs/vmgenid.txt
@@ -0,0 +1,245 @@
+VIRTUAL MACHINE GENERATION ID
+=
+
+Copyright (C) 2016 Red Hat, Inc.
+Copyright (C) 2017 Skyport Systems, Inc.
+
+This work is licensed under the terms of the GNU GPL, version 2 or later.
+See the COPYING file in the top-level directory.
+
+===
+
+The VM generation ID (vmgenid) device is an emulated device which
+exposes a 128-bit, cryptographically random, integer value identifier,
+referred to as a Globally Unique Identifier, or GUID.
+
+This allows management applications (e.g. libvirt) to notify the guest
+operating system when the virtual machine is executed with a different
+configuration (e.g. snapshot execution or creation from a template).  The
+guest operating system notices the change, and is then able to react as
+appropriate by marking its copies of distributed databases as dirty,
+re-initializing its random number generator etc.
+
+
+Requirements
+
+
+These requirements are extracted from the "How to implement virtual machine
+generation ID support in a virtualization platform" section of the
+specification, dated August 1, 2012.
+
+
+The document may be found on the web at:
+  http://go.microsoft.com/fwlink/?LinkId=260709
+
+R1a. The generation ID shall live in an 8-byte aligned buffer.
+
+R1b. The buffer holding the generation ID shall be in guest RAM, ROM, or device
+ MMIO range.
+
+R1c. The buffer holding the generation ID shall be kept separate from areas
+ used by the operating system.
+
+R1d. The buffer shall not be covered by an AddressRangeMemory or
+ AddressRangeACPI entry in the E820 or UEFI memory map.
+
+R1e. The generation ID shall not live in a page frame that could be mapped with
+ caching disabled. (In other words, regardless of whether the generation ID
+ lives in RAM, ROM or MMIO, it shall only be mapped as cacheable.)
+
+R2 to R5. [These AML requirements are isolated well enough in the Microsoft
+  specification for us to simply refer to them here.]
+
+R6. The hypervisor shall expose a _HID (hardware identifier) object in the
+VMGenId device's scope that is unique to the hypervisor vendor.
+
+
+QEMU Implementation
+---
+
+The above-mentioned specification does not dictate which ACPI descriptor table
+will contain the VM Generation ID device.  Other implementations (Hyper-V and
+Xen) put it in the main descriptor table (Differentiated System Description
+Table or DSDT).  For ease of debugging and implementation, we have decided to
+put it in its own Secondary System Description Table, or SSDT.
+
+The following is a dump of the contents from a running system:
+
+# iasl -p ./SSDT -d /sys/firmware/acpi/tables/SSDT
+
+Intel ACPI Component Architecture
+ASL+ Optimizing Compiler version 20150717-64
+Copyright (c) 2000 - 2015 Intel Corporation
+
+Reading ACPI table from file /sys/firmware/acpi/tables/SSDT - Length
+0198 (0xC6)
+ACPI: SSDT 0x C6 (v01 BOCHS  VMGENID  0001 BXPC
+0001)
+Acpi table [SSDT] successfully installed and loaded
+Pass 1 parse of [SSDT]
+Pass 2 parse of [SSDT]
+Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
+
+Parsing completed
+Disassembly completed
+ASL Output:./SSDT.dsl - 1631 bytes
+# cat SSDT.dsl
+/*
+ * Intel ACPI Component Architecture
+ * AML/ASL+ Disassembler version 20150717-64
+ * Copyright (c) 2000 - 2015 Intel Corporation
+ *
+ * Disassembling to symbolic ASL+ operators
+ *
+ * Disassembly of /sys/firmware/acpi/tables/SSDT, Sun Feb  5 00:19:37 2017
+ *
+ * Original Table Header:
+ * Signature"SSDT"
+ * Length   0x00CA (202)
+ * Revision 0x01
+ * Checksum 0x4B
+ * OEM ID   "BOCHS "
+ * OEM Table ID "VMGENID"
+ * OEM Revision 0x0001 (1)
+ * Compiler ID  "BXPC"
+ * Compiler Version 0x0001 (1)
+ */
+DefinitionBlock ("/sys/firmware/acpi/tables/SSDT.aml", "SSDT", 1, "BOCHS ",
+"VMGENID", 0x0001)
+{
+Name (VGIA, 0x07FFF000)
+Scope (\_SB)
+{
+Device (VGEN)
+{
+Name (_HID, "QEMUVGID")  // _HID: Hardware ID
+Name (_CID, "VM_Gen_Counter")  // _CID: Compatible ID
+Name (_DDN, "VM_Gen_Counter")  // _DDN: DOS Device Name
+   

[Qemu-devel] [PATCH] qmp-events: fix GUEST_PANICKED description formatting

[Anton Nefedov]

also remove a useless NULL check in the event reporting code

Signed-off-by: Anton Nefedov 
---
 qapi/event.json |  4 ++--
 vl.c| 22 ++
 2 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/qapi/event.json b/qapi/event.json
index 970ff02..e02852c 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -488,9 +488,9 @@
 #
 # @action: action that has been taken, currently always "pause"
 #
-# @info: optional information about a panic
+# @info: #optional information about a panic (since 2.9)
 #
-# Since: 1.5 (@info since 2.9)
+# Since: 1.5
 #
 # Example:
 #
diff --git a/vl.c b/vl.c
index 903c46d..f410e03 100644
--- a/vl.c
+++ b/vl.c
@@ -1710,6 +1710,15 @@ void qemu_system_reset(bool report)
 void qemu_system_guest_panicked(GuestPanicInformation *info)
 {
 qemu_log_mask(LOG_GUEST_ERROR, "Guest crashed\n");
+if (info && info->type == GUEST_PANIC_INFORMATION_KIND_HYPER_V) {
+qemu_log_mask(LOG_GUEST_ERROR, "HV crash parameters: (%#"PRIx64
+  " %#"PRIx64" %#"PRIx64" %#"PRIx64" %#"PRIx64")\n",
+  info->u.hyper_v.data->arg1,
+  info->u.hyper_v.data->arg2,
+  info->u.hyper_v.data->arg3,
+  info->u.hyper_v.data->arg4,
+  info->u.hyper_v.data->arg5);
+}
 
 if (current_cpu) {
 current_cpu->crash_occurred = true;
@@ -1723,18 +1732,7 @@ void qemu_system_guest_panicked(GuestPanicInformation 
*info)
 qemu_system_shutdown_request();
 }
 
-if (info) {
-if (info->type == GUEST_PANIC_INFORMATION_KIND_HYPER_V) {
-qemu_log_mask(LOG_GUEST_ERROR, "HV crash parameters: (%#"PRIx64
-  " %#"PRIx64" %#"PRIx64" %#"PRIx64" %#"PRIx64")\n",
-  info->u.hyper_v.data->arg1,
-  info->u.hyper_v.data->arg2,
-  info->u.hyper_v.data->arg3,
-  info->u.hyper_v.data->arg4,
-  info->u.hyper_v.data->arg5);
-}
-qapi_free_GuestPanicInformation(info);
-}
+qapi_free_GuestPanicInformation(info);
 }
 
 void qemu_system_reset_request(void)
-- 
2.7.4

Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"

[ashish mittal]

Hi,

I am getting the following error with checkpatch.pl

ERROR: externs should be avoided in .c files
#78: FILE: block/vxhs.c:28:
+QemuUUID qemu_uuid __attribute__ ((weak));

Is there any way to get around this, or does it mean that I would have
to add a vxhs.h just for this one entry?

Thanks,
Ashish

[Qemu-devel] [Bug 1665389] Re: Nested kvm guest fails to start on a emulated Westmere CPU guest under a Broadwell CPU host

[Nadav Goldin]

Hi Dave, thanks for looking into this.

> Can you clarify what the host and L1 kernels are please?

Host - 4.8.15-200.fc24.x86_64
Guest - 3.10.0-514.2.2.el7.x86_64

Results of adding the debug messages and running a simpler command(with
master again - 5dae13):

[root@vm-el73 ~]# /usr/bin/qemu-custom -s -machine pc,accel=kvm,usb=off -cpu 
Westmere
kvm_msr_entry_add: @0 index=174 value=0
kvm_msr_entry_add: @1 index=175 value=0
kvm_msr_entry_add: @2 index=176 value=0
kvm_msr_entry_add: @3 index=277 value=7040600070406
kvm_msr_entry_add: @4 index=c081 value=0
kvm_msr_entry_add: @5 index=c0010117 value=0
kvm_msr_entry_add: @6 index=3b value=0
kvm_msr_entry_add: @7 index=1a0 value=1
kvm_msr_entry_add: @8 index=9e value=3
kvm_msr_entry_add: @9 index=d90 value=0
kvm_msr_entry_add: @10 index=c083 value=0
kvm_msr_entry_add: @11 index=c102 value=0
kvm_msr_entry_add: @12 index=c084 value=0
kvm_msr_entry_add: @13 index=c082 value=0
kvm_msr_entry_add: @14 index=10 value=0
kvm_msr_entry_add: @15 index=12 value=0
kvm_msr_entry_add: @16 index=11 value=0
kvm_msr_entry_add: @17 index=4b564d02 value=0
kvm_msr_entry_add: @18 index=4b564d04 value=0
kvm_msr_entry_add: @19 index=4b564d03 value=0
kvm_msr_entry_add: @20 index=2ff value=0
kvm_msr_entry_add: @21 index=250 value=0
kvm_msr_entry_add: @22 index=258 value=0
kvm_msr_entry_add: @23 index=259 value=0
kvm_msr_entry_add: @24 index=268 value=0
kvm_msr_entry_add: @25 index=269 value=0
kvm_msr_entry_add: @26 index=26a value=0
kvm_msr_entry_add: @27 index=26b value=0
kvm_msr_entry_add: @28 index=26c value=0
kvm_msr_entry_add: @29 index=26d value=0
kvm_msr_entry_add: @30 index=26e value=0
kvm_msr_entry_add: @31 index=26f value=0
kvm_msr_entry_add: @32 index=200 value=0
kvm_msr_entry_add: @33 index=201 value=0
kvm_msr_entry_add: @34 index=202 value=0
kvm_msr_entry_add: @35 index=203 value=0
kvm_msr_entry_add: @36 index=204 value=0
kvm_msr_entry_add: @37 index=205 value=0
kvm_msr_entry_add: @38 index=206 value=0
kvm_msr_entry_add: @39 index=207 value=0
kvm_msr_entry_add: @40 index=208 value=0
kvm_msr_entry_add: @41 index=209 value=0
kvm_msr_entry_add: @42 index=20a value=0
kvm_msr_entry_add: @43 index=20b value=0
kvm_msr_entry_add: @44 index=20c value=0
kvm_msr_entry_add: @45 index=20d value=0
kvm_msr_entry_add: @46 index=20e value=0
kvm_msr_entry_add: @47 index=20f value=0
kvm_msr_entry_add: @48 index=17a value=0
kvm_msr_entry_add: @49 index=17b value=
kvm_msr_entry_add: @50 index=400 value=
kvm_msr_entry_add: @51 index=401 value=0
kvm_msr_entry_add: @52 index=402 value=0
kvm_msr_entry_add: @53 index=403 value=0
kvm_msr_entry_add: @54 index=404 value=
kvm_msr_entry_add: @55 index=405 value=0
kvm_msr_entry_add: @56 index=406 value=0
kvm_msr_entry_add: @57 index=407 value=0
kvm_msr_entry_add: @58 index=408 value=
kvm_msr_entry_add: @59 index=409 value=0
kvm_msr_entry_add: @60 index=40a value=0
kvm_msr_entry_add: @61 index=40b value=0
kvm_msr_entry_add: @62 index=40c value=
kvm_msr_entry_add: @63 index=40d value=0
kvm_msr_entry_add: @64 index=40e value=0
kvm_msr_entry_add: @65 index=40f value=0
kvm_msr_entry_add: @66 index=410 value=
kvm_msr_entry_add: @67 index=411 value=0
kvm_msr_entry_add: @68 index=412 value=0
kvm_msr_entry_add: @69 index=413 value=0
kvm_msr_entry_add: @70 index=414 value=
kvm_msr_entry_add: @71 index=415 value=0
kvm_msr_entry_add: @72 index=416 value=0
kvm_msr_entry_add: @73 index=417 value=0
kvm_msr_entry_add: @74 index=418 value=
kvm_msr_entry_add: @75 index=419 value=0
kvm_msr_entry_add: @76 index=41a value=0
kvm_msr_entry_add: @77 index=41b value=0
kvm_msr_entry_add: @78 index=41c value=
kvm_msr_entry_add: @79 index=41d value=0
kvm_msr_entry_add: @80 index=41e value=0
kvm_msr_entry_add: @81 index=41f value=0
kvm_msr_entry_add: @82 index=420 value=
kvm_msr_entry_add: @83 index=421 value=0
kvm_msr_entry_add: @84 index=422 value=0
kvm_msr_entry_add: @85 index=423 value=0
kvm_msr_entry_add: @86 index=424 value=
kvm_msr_entry_add: @87 index=425 value=0
kvm_msr_entry_add: @88 index=426 value=0
kvm_msr_entry_add: @89 index=427 value=0
kvm_put_msrs: ret=9 expected=90
qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs: Assertion `ret == 
cpu->kvm_msr_buf->nmsrs' failed.
Aborted

> Also, does the problem go away if you remove the +x2apic on the top
level qemu?

Don't think so, I actually added it because I thought it would solve
something. I can re-try with out it if needed(with the debug messages).

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

Title:
  Nested kvm guest fails to start on a emulated Westmere CPU guest under
  a Broadwell CPU host

Status in QEMU:
  New

Bug description:
  Using latest master(5dae13), qemu fails to start any nested guest in 

[Qemu-devel] [PATCH] iotests: Fix another race in 030

[John Snow]

We can't rely on a non-paused job to be present and running for us.
Assume that if the job is not present that it completed already.

Signed-off-by: John Snow 
---
 tests/qemu-iotests/030 | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 54db54a..0d472d5 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -547,11 +547,14 @@ class TestEIO(TestErrors):
 while not completed:
 for event in self.vm.get_qmp_events(wait=True):
 if event['event'] == 'BLOCK_JOB_ERROR':
+error = True
 self.assert_qmp(event, 'data/device', 'drive0')
 self.assert_qmp(event, 'data/operation', 'read')
 result = self.vm.qmp('query-block-jobs')
+if result == {'return': []}:
+# Job finished too quickly
+continue
 self.assert_qmp(result, 'return[0]/paused', False)
-error = True
 elif event['event'] == 'BLOCK_JOB_COMPLETED':
 self.assertTrue(error, 'job completed unexpectedly')
 self.assert_qmp(event, 'data/type', 'stream')
-- 
2.9.3

Re: [Qemu-devel] [Qemu-block] [PATCH v3 7/8] blockdev: Make orphaned -drive fatal

[John Snow]

On 02/15/2017 05:05 AM, Markus Armbruster wrote:
> Block backends defined with "-drive if=T" with T other than "none" are
> meant to be picked up by machine initialization code: a suitable
> frontend gets created and wired up automatically.
> 
> If machine initialization code doesn't comply, the block backend
> remains unused.  This triggers a warning since commit a66c9dc, v2.2.0.
> Drives created by default are exempted; use -nodefaults to get rid of
> them.
> 
> Turn this warning into an error.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  blockdev.c| 14 +++---
>  include/sysemu/blockdev.h |  2 +-
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/blockdev.c b/blockdev.c
> index eb75f35..bbf9d4d 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -227,30 +227,30 @@ DriveInfo *drive_get(BlockInterfaceType type, int bus, 
> int unit)
>  return NULL;
>  }
>  
> -bool drive_check_orphaned(void)
> +void drive_check_orphaned(void)
>  {
>  BlockBackend *blk;
>  DriveInfo *dinfo;
>  Location loc;
> -bool rs = false;
> +bool orphans = false;
>  
>  for (blk = blk_next(NULL); blk; blk = blk_next(blk)) {
>  dinfo = blk_legacy_dinfo(blk);
> -/* If dinfo->bdrv->dev is NULL, it has no device attached. */
> -/* Unless this is a default drive, this may be an oversight. */
>  if (!blk_get_attached_dev(blk) && !dinfo->is_default &&
>  dinfo->type != IF_NONE) {
>  loc_push_none();
>  qemu_opts_loc_restore(dinfo->opts);
> -error_report("warning: machine type does not support"
> +error_report("machine type does not support"
>   " if=%s,bus=%d,unit=%d",
>   if_name[dinfo->type], dinfo->bus, dinfo->unit);
>  loc_pop();
> -rs = true;
> +orphans = true;
>  }
>  }
>  
> -return rs;
> +if (orphans) {
> +exit(1);
> +}
>  }
>  
>  DriveInfo *drive_get_by_index(BlockInterfaceType type, int index)
> diff --git a/include/sysemu/blockdev.h b/include/sysemu/blockdev.h
> index 351a039..ac22f2a 100644
> --- a/include/sysemu/blockdev.h
> +++ b/include/sysemu/blockdev.h
> @@ -48,7 +48,7 @@ BlockBackend *blk_by_legacy_dinfo(DriveInfo *dinfo);
>  void override_max_devs(BlockInterfaceType type, int max_devs);
>  
>  DriveInfo *drive_get(BlockInterfaceType type, int bus, int unit);
> -bool drive_check_orphaned(void);
> +void drive_check_orphaned(void);
>  DriveInfo *drive_get_by_index(BlockInterfaceType type, int index);
>  int drive_get_max_bus(BlockInterfaceType type);
>  int drive_get_max_devs(BlockInterfaceType type);
> 

6,7:

Reviewed-by: John Snow 

Re: [Qemu-devel] [PATCH v3 15/16] target-m68k: add more FPU instructions

[Richard Henderson]

On 02/16/2017 09:18 PM, Andreas Schwab wrote:

There is no guarantee that the host long double has the same range and
precision as floatx80.


Indeed not.  However, do you have another plan for implementing the 
trancendentals?  I'm quite happy using the host long double libm as an 
estimate.  Which is better than at least BasiliskII, which uses the host double.



r~

Re: [Qemu-devel] [PATCH v7 0/8] Add support for VM Generation ID

[Laszlo Ersek]

On 02/16/17 07:18, b...@skyportsystems.com wrote:
> From: Ben Warren 
> 
> This patch set adds support for passing a GUID to Windows guests.  It is a
> re-implementation of previous patch sets written by Igor Mammedov et al, but
> this time passing the GUID data as a fw_cfg blob.
> 
> This patch set has dependencies on new guest functionality, in particular the
> support for a new linker-loader command and the ability to write back data
> to QEMU over a DMA link.  Work is in flight in both SeaBIOS and OVMF to 
> support this.
> 
> v6->v7:
> - Rebased to top of tree.
> - Added 'src_offset' field to "write pointer" command
> - Reworked unit tests based on feedback
> - various minor changes based on feedback
> - Added entries to MAINTAINERS file

I posted the OVMF series:

  [edk2] [PATCH 0/5] OvmfPkg: support QEMU_LOADER_WRITE_POINTER
  Message-Id: <20170216204137.30221-1-ler...@redhat.com>
  https://lists.01.org/pipermail/edk2-devel/2017-February/007454.html

Thanks,
Laszlo

Re: [Qemu-devel] [PATCH] target-ppc: Add quad precision muladd instructions

[Richard Henderson]

On 02/16/2017 01:41 PM, Bharata B Rao wrote:

For some reason float128_mul implements
multipliction via multiplication and addition (mul128To256 & add128). There
is no equivalent to this in float64_muladd.


Yes, I don't understand that myself.  It really appears to be a bug.


r~

Re: [Qemu-devel] [PATCH 5/6] target-ppc: support for 32-bit carry and overflow

[Richard Henderson]

On 02/16/2017 04:08 PM, Nikunj A Dadhania wrote:

Richard Henderson  writes:


On 02/14/2017 02:05 PM, Nikunj A Dadhania wrote:

Yes, you are right. I had a discussion with Paul Mackerras yesterday, he
explained to me in detail about the bits. I am working on the revised
implementation. Will detail it in the commit message.


As you're working on this, consider changing the definition of cpu_ov such that
the MSB is OV and bit 31 is OV32.

E.g.


  static inline void gen_op_arith_compute_ov(DisasContext *ctx, TCGv arg0,
 TCGv arg1, TCGv arg2, int sub)
  {
  TCGv t0 = tcg_temp_new();

  tcg_gen_xor_tl(cpu_ov, arg0, arg2);
  tcg_gen_xor_tl(t0, arg1, arg2);
  if (sub) {
  tcg_gen_and_tl(cpu_ov, cpu_ov, t0);
  } else {
  tcg_gen_andc_tl(cpu_ov, cpu_ov, t0);
  }
  tcg_temp_free(t0);
  if (NARROW_MODE(ctx)) {
  tcg_gen_ext32s_tl(cpu_ov, cpu_ov);
  }
-tcg_gen_shri_tl(cpu_ov, cpu_ov, TARGET_LONG_BITS - 1);
  tcg_gen_or_tl(cpu_so, cpu_so, cpu_ov);
  }


is all that is required for arithmetic to compute OV and OV32 into those two 
bits.


How about the below?

@@ -809,10 +809,11 @@ static inline void gen_op_arith_compute_ov(DisasContext 
*ctx, TCGv arg0,
 tcg_gen_andc_tl(cpu_ov, cpu_ov, t0);
 }
 tcg_temp_free(t0);
+tcg_gen_extract_tl(cpu_ov32, cpu_ov, 31, 1);
+tcg_gen_extract_tl(cpu_ov, cpu_ov, 63, 1);
 if (NARROW_MODE(ctx)) {
-tcg_gen_ext32s_tl(cpu_ov, cpu_ov);
+tcg_gen_mov_tl(cpu_ov, cpu_ov32);
 }
-tcg_gen_shri_tl(cpu_ov, cpu_ov, TARGET_LONG_BITS - 1);
 tcg_gen_or_tl(cpu_so, cpu_so, cpu_ov);
 }


Why do you want to extract these bits?


r~

Re: [Qemu-devel] [Qemu-block] [PATCH v15 09/25] qcow2: add .bdrv_load_autoloading_dirty_bitmaps

[John Snow]

On 02/16/2017 07:47 AM, Kevin Wolf wrote:
> Can we make the whole thing a little less confusing by entirely removing
> sectors from the block dirty bitmap interfaces? I find it challenging
> enough to deal with just bytes, qcow2 clusters and bitmap clusters.

I'll take a look to see how easy that is to do. For now, it's the
dominant paradigm.

--js

Re: [Qemu-devel] [PATCH v4 3/4] .shippable.yml: new CI provider

[Alex Bennée]

Fam Zheng  writes:

> On Thu, 02/16 12:34, Alex Bennée wrote:
>> Ostensibly Shippable offers a similar set of services as Travis.
>> However they are focused on Docker container based work-flows so we
>> can use our existing containers to run a few extra builds - in this
>> case a bunch of cross-compiled targets on a Debian multiarch system.
>
> Out of curiosity, what are the forms of build report from shippable
> service?

It sends out emails and there is the web status page:

https://app.shippable.com/runs/58a596c4266ed80f003a9385/summary

There is also support for build badges a.la Travis.

>
>>
>> Signed-off-by: Alex Bennée 
>>
>> ---
>> v3
>>   - reduce matrix to armhf/arm64 which currently work
>>   - use the make docker-image-* build stanzas
>>   - add TARGET_LIST to each build
>> ---
>>  .shippable.yml | 21 +
>>  1 file changed, 21 insertions(+)
>>  create mode 100644 .shippable.yml
>>
>> diff --git a/.shippable.yml b/.shippable.yml
>> new file mode 100644
>> index 00..4de8daf341
>> --- /dev/null
>> +++ b/.shippable.yml
>> @@ -0,0 +1,21 @@
>> +language: c
>> +env:
>> +  matrix:
>> +- IMAGE=debian-armhf-cross
>> +  TARGET_LIST=arm-softmmu,arm-linux-user
>> +- IMAGE=debian-arm64-cross
>> +  TARGET_LIST=aarch64-softmmu,aarch64-linux-user
>> +- IMAGE=centos6
>> +  TARGET_LIST=i386-softmmu,x86_64-softmmu
>> +build:
>> +  pre_ci:
>> +- make docker-image-${IMAGE}
>> +  pre_ci_boot:
>> +image_name: qemu
>> +image_tag: ${IMAGE}
>> +pull: false
>> +options: "-e HOME=/root"
>> +  ci:
>> +- unset CC
>> +- ./configure ${QEMU_CONFIGURE_OPTS} --target-list=${TARGET_LIST}
>> +- make -j2
>
> It's a good surprise that our docker infrastructure fits in the shippable
> framework pretty nicely. :)
>
> Looks good to me without cross checking the shippable API:
>
> Reviewed-by: Fam Zheng 


--
Alex Bennée

Re: [Qemu-devel] [PATCH] qmp-events: fix GUEST_PANICKED description formatting

[Eric Blake]

On 02/16/2017 11:39 AM, Anton Nefedov wrote:
> also remove a useless NULL check in the event reporting code
> 
> Signed-off-by: Anton Nefedov 
> ---
>  qapi/event.json |  4 ++--
>  vl.c| 22 ++
>  2 files changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/qapi/event.json b/qapi/event.json
> index 970ff02..e02852c 100644
> --- a/qapi/event.json
> +++ b/qapi/event.json
> @@ -488,9 +488,9 @@
>  #
>  # @action: action that has been taken, currently always "pause"
>  #
> -# @info: optional information about a panic
> +# @info: #optional information about a panic (since 2.9)
>  #
> -# Since: 1.5 (@info since 2.9)
> +# Since: 1.5

This part's fine, but

> +++ b/vl.c
> @@ -1710,6 +1710,15 @@ void qemu_system_reset(bool report)
>  void qemu_system_guest_panicked(GuestPanicInformation *info)
>  {
>  qemu_log_mask(LOG_GUEST_ERROR, "Guest crashed\n");
> +if (info && info->type == GUEST_PANIC_INFORMATION_KIND_HYPER_V) {
> +qemu_log_mask(LOG_GUEST_ERROR, "HV crash parameters: (%#"PRIx64
> +  " %#"PRIx64" %#"PRIx64" %#"PRIx64" %#"PRIx64")\n",
> +  info->u.hyper_v.data->arg1,
> +  info->u.hyper_v.data->arg2,
> +  info->u.hyper_v.data->arg3,
> +  info->u.hyper_v.data->arg4,
> +  info->u.hyper_v.data->arg5);
> +}

This code motion doesn't seem to match up with the pull request...

>  
>  if (current_cpu) {
>  current_cpu->crash_occurred = true;
> @@ -1723,18 +1732,7 @@ void qemu_system_guest_panicked(GuestPanicInformation 
> *info)
>  qemu_system_shutdown_request();
>  }
>  
> -if (info) {
> -if (info->type == GUEST_PANIC_INFORMATION_KIND_HYPER_V) {
> -qemu_log_mask(LOG_GUEST_ERROR, "HV crash parameters: (%#"PRIx64
> -  " %#"PRIx64" %#"PRIx64" %#"PRIx64" %#"PRIx64")\n",
> -  info->u.hyper_v.data->arg1,
> -  info->u.hyper_v.data->arg2,
> -  info->u.hyper_v.data->arg3,
> -  info->u.hyper_v.data->arg4,
> -  info->u.hyper_v.data->arg5);
> -}
> -qapi_free_GuestPanicInformation(info);
> -}

The pull request for 21/23 just had:

+
+if (info) {
+qapi_free_GuestPanicInformation(info);
+}
 }

where did the qemu_log_mask() stuff come from?  Oh, I see now - it was
in 22/23.

On that grounds, you already need the 'if (info)' for more than just the
free, so this code motion is no longer quite as important.  But now I'm
noticing that it looks weird because you are freeing an input parameter.
 Generally, transfer semantics like that are screwy - it's probably
better if the caller of qemu_system_guest_panicked() is the one freeing
info, rather than requiring that the caller pass in malloc'd memory that
gets freed as a side effect and must not be referenced afterwards in the
caller.  In other words, I think the code motion is unnecessary, but
that the qapi_free_GuestPanicInformation() call is probably in the wrong
function to begin with.

Sorry for not noticing sooner (it shows that I didn't read the full pull
request, but just the one patch that caught my eye because of the .json
edit).

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-arm] [PATCH v2 00/13] Rewrite NVIC to not depend on the GIC

[Peter Maydell]

On 16 February 2017 at 16:35, Peter Maydell  wrote:
> This patchset is the revamp of the NVIC code from Michael
> Davidsaver's patchset of a year ago.
>
> Despite some superficial similarities of register layout, the
> M-profile NVIC is really very different from the A-profile GIC.  Our
> current attempt to reuse the GIC code means that we have significant
> bugs in our NVIC.  The series pulls the NVIC apart from the GIC code
> (fixing a few accidental bugs in the process), and then once it has a
> place to stand, implements a few minor cleanups, a key bugfix
> (getting priority calculations and masking right) and a missing
> feature (escalation to HardFault).
>
> For testing, I have used the Stellaris image I have to hand:
> http://people.linaro.org/~peter.maydell/stellaris.tgz
> and also a set of bare-metal test programs also written by
> Michael. You can find my slightly tweaked and cleand up
> version of those here (a README explains how to run them):
> https://git.linaro.org/people/peter.maydell/m-profile-tests.git

PS: git branch of this v2 patchset at
https://git.linaro.org/people/peter.maydell/qemu-arm.git nvic-rewrite
(includes squashed-in fix to patch 3).

thanks
-- PMM

Re: [Qemu-devel] [RFC] virtio-pci: Allow PCIe virtio devices on root bus

[Marcel Apfelbaum]

On 02/16/2017 05:28 AM, David Gibson wrote:

On Thu, Feb 16, 2017 at 01:48:42PM +1100, David Gibson wrote:

On Wed, Feb 15, 2017 at 04:59:33PM +0200, Marcel Apfelbaum wrote:

On 02/15/2017 03:45 AM, David Gibson wrote:

On Tue, Feb 14, 2017 at 02:53:08PM +0200, Marcel Apfelbaum wrote:

On 02/14/2017 06:15 AM, David Gibson wrote:

On Mon, Feb 13, 2017 at 12:14:23PM +0200, Marcel Apfelbaum wrote:

On 02/13/2017 06:33 AM, David Gibson wrote:

On Sun, Feb 12, 2017 at 09:05:46PM +0200, Marcel Apfelbaum wrote:

On 02/10/2017 02:37 AM, David Gibson wrote:

On Thu, Feb 09, 2017 at 10:04:47AM +0100, Laszlo Ersek wrote:

On 02/09/17 05:16, David Gibson wrote:

On Wed, Feb 08, 2017 at 11:40:50AM +0100, Laszlo Ersek wrote:

On 02/08/17 07:16, David Gibson wrote:

[snip]

  Which means that you can use it to

drive PCIe devices just fine.  "Bus level" PCIe extensions like AER
and PCIe standard hotplug won't work, but PAPR has its own mechanisms
for those (common between PCI and PCIe).

I did float the idea of having the pseries PCI bus remain plain PCI
but with a special flag to allow PCIe devices to be attached to it
anyway.  It wasn't greeted with much enthusiasm..



Can you point me to the discussion please? It seems similar to what I proposed 
above.


Sorry, I was misleading.  I think I just raised that idea with Andrea
and a few other people internally, not on one of the lists at large.


As you properly described it, is much closer to PCI then PCIe, even the only 
characteristic
that makes it "a little" PCIe, the Extended Configuration Space support,
is done with an alternative interface.

I agree the PAPR bus is not PCIe.


Ok, so if we take that direction, the question becomes how do we let
PCIe devices plug into this mostly-not-PCIe bus.  Maybe introduce a
"pci_bus_accepts_express()" function that will replace many, but not
all current uses of "pci_bus_is_express()"?



Sounds good and I think Eduardo is already working on exactly this
idea, however he is on PTO now. It is better to synchronize with him.


Ah, right.  Do you know when he'll be back?  This is semi-urgent for
Power.



Such a helper could maybe simplify the logic in virtio-pci (and XHCI?)
by returning false on an x86 root bus.



The rule would me more complicated. We don't want to completely remove the
possibility to have PCIe devices as part of Root Complex. it seems
like I am contradicting myself, but no).
This is why we have guidelines and  not hard-coded policies.
Also ,the QEMU way is to be more permissive. We provide guidelines and sane
defaults, but we let the user to chose.

Getting back to our problem, the rule would be:
hybrid devices should be PCI or PCIe for a bus?
PAPR bus should return 'PCIe' for hybrid devices.
X86 bus should return 'PCIe' if not root.


Ok.


Wait, actually.. we have two possible directions to go, both of which
have been mentioned in the thread, but I don't think we've settled on
one:

1) Have pseries create a PCIe bus (as my first cut draft does).

That should allow pure PCIe devices to appear either under a port or
(more usually for PAPR) as "integrated endpoints".  In addition we'd
need as suggested above a "pcie_hybrid_type()" function that would
tell hybrid devices to also appear as PCIe rather than PCI.

2) Have pseries create a vanilla PCI bus (or a special PAPR PCI
   variant)

Appearing as vanilla PCI would in a number of ways more closely match
the way PCI buses are handled on PAPR.  However, we still need to
connect PCIe devices to it.  So we'd need some 'bus_accepts_pcie()'
hook and use that (in place of pci_bus_is_express()) to determine both
whether we can attach pure PCIe devices and that hybrid devices should
appear as PCIe rather than plain PCI.


Based on the immediately preceding discussion, I was leaning towards
(2).  Is that your feeling as well?



On 02/16/2017 05:28 AM, David Gibson wrote:
> On Thu, Feb 16, 2017 at 01:48:42PM +1100, David Gibson wrote:
>> On Wed, Feb 15, 2017 at 04:59:33PM +0200, Marcel Apfelbaum wrote:
>>> On 02/15/2017 03:45 AM, David Gibson wrote:
 On Tue, Feb 14, 2017 at 02:53:08PM +0200, Marcel Apfelbaum wrote:
> On 02/14/2017 06:15 AM, David Gibson wrote:
>> On Mon, Feb 13, 2017 at 12:14:23PM +0200, Marcel Apfelbaum wrote:
>>> On 02/13/2017 06:33 AM, David Gibson wrote:
 On Sun, Feb 12, 2017 at 09:05:46PM +0200, Marcel Apfelbaum wrote:
> On 02/10/2017 02:37 AM, David Gibson wrote:
>> On Thu, Feb 09, 2017 at 10:04:47AM +0100, Laszlo Ersek wrote:
>>> On 02/09/17 05:16, David Gibson wrote:
 On Wed, Feb 08, 2017 at 11:40:50AM +0100, Laszlo Ersek wrote:
> On 02/08/17 07:16, David Gibson wrote:
> [snip]
>   Which means that you can use it to
>> drive PCIe devices just fine.  "Bus level" PCIe extensions like AER
>> and PCIe standard hotplug won't work, but PAPR has its own mechanisms
>> for those (common between PCI and PCIe).
>>
>> I did float the idea of having the pseries 

[Qemu-devel] [Bug 1665389] Re: Nested kvm guest fails to start on a emulated Westmere CPU guest under a Broadwell CPU host

[Dr. David Alan Gilbert]

Hi Nadav,
  Can you clarify what the host and L1 kernels are please?

This error means that qemu tried to write some msrs but one of the msr
writes failed; we need to figure out which one to understand what's
going on.

1) Edit kvm_msr_entry_add in target/i386/kvm.c to something like:

assert((void *)(entry + 1) <= limit);
fprintf(stderr,"kvm_msr_entry_add: @%d index=%x value=%lx\n", msrs->nmsrs, 
index, value);
entry->index = index;

2) edit kvm_put_msrs near the bottom:

fprintf(stderr,"kvm_put_msrs: ret=%d expected=%d\n", ret, 
cpu->kvm_msr_buf->nmsrs);
assert(ret == cpu->kvm_msr_buf->nmsrs);

Now with any luck the 'ret' value will tell you the entry which is bad, and you 
can match
that to the @%d value (or maybe it's the entry before that one which failed?) 
then we get the index, look it up in the intel docs and figure out which MSR 
it's complaining about.

Also, does the problem go away if you remove the +x2apic on the top
level qemu?

Dave

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

Title:
  Nested kvm guest fails to start on a emulated Westmere CPU guest under
  a Broadwell CPU host

Status in QEMU:
  New

Bug description:
  Using latest master(5dae13), qemu fails to start any nested guest in a
  Westmere emulated guest(layer 1), under a Broadwell host(layer 0),
  with the error:

  qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs:
  Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.

  The qemu command used(though other CPUs didn't work either):
  /usr/bin/qemu-custom -name guest=12ed9230-vm-el73,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-12ed9230-vm-el73/master-key.aes
 -machine pc-i440fx-2.9,accel=kvm,usb=off -cpu Westmere,+vmx -m 512 -realtime 
mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 
-uuid f4ce4eba-985f-42a3-94c4-6e4a8a530347 -nographic -no-user-config 
-nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-12ed9230-vm-el73/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-boot menu=off,strict=on -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive 
file=/root/lago/.lago/default/images/vm-el73_root.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,serial=1,discard=unmap
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:c0:a7:c8:02,bus=pci.0,addr=0x2 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-chardev 
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-12ed9230-vm-el73/org.qemu.guest_agent.0,server,nowait
 -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 -object rng-random,id=objrng0,filename=/dev/random -device 
virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x9 -msg timestamp=on
  2017-02-16T15:14:45.840412Z qemu-custom: -chardev pty,id=charserial0: char 
device redirected to /dev/pts/2 (label charserial0)
  qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs: Assertion `ret 
== cpu->kvm_msr_buf->nmsrs' failed.

  
  The CPU flags in the Westmere guest:
  flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc rep_good nopl 
pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm 
arat tpr_shadow vnmi flexpriority ept vpid

  The guest kernel is 3.10.0-514.2.2.el7.x86_64.

  The CPU flags of the host(Broadwell): 
  flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb 
intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle 
avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec 
xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp

  qemu command on the host - Broadwell(which works):
  /usr/bin/qemu-kvm -name 4ffcd448-vm-el73,debug-threads=on -S -machine 
pc-i440fx-2.6,accel=kvm,usb=off -cpu Westmere,+x2apic,+vmx,+vme -m 4096 
-realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object 
iothread,id=iothread1 -uuid 8cc0a2cf-d25a-4014-acdb-f159c376a532 -nographic 
-no-user-config -nodefaults -chardev 

Re: [Qemu-devel] [RFC] virtio-pci: Allow PCIe virtio devices on root bus

[Marcel Apfelbaum]

On 02/16/2017 04:48 AM, David Gibson wrote:

On Wed, Feb 15, 2017 at 04:59:33PM +0200, Marcel Apfelbaum wrote:


[...]



I did float the idea of having the pseries PCI bus remain plain PCI
but with a special flag to allow PCIe devices to be attached to it
anyway.  It wasn't greeted with much enthusiasm..



Can you point me to the discussion please? It seems similar to what I proposed 
above.


Sorry, I was misleading.  I think I just raised that idea with Andrea
and a few other people internally, not on one of the lists at large.


As you properly described it, is much closer to PCI then PCIe, even the only 
characteristic
that makes it "a little" PCIe, the Extended Configuration Space support,
is done with an alternative interface.

I agree the PAPR bus is not PCIe.


Ok, so if we take that direction, the question becomes how do we let
PCIe devices plug into this mostly-not-PCIe bus.  Maybe introduce a
"pci_bus_accepts_express()" function that will replace many, but not
all current uses of "pci_bus_is_express()"?



Sounds good and I think Eduardo is already working on exactly this
idea, however he is on PTO now. It is better to synchronize with him.


Ah, right.  Do you know when he'll be back?  This is semi-urgent for
Power.



In a week or so.





[...]



Ok.. I'm still missing something.  Are you saying that instead of the
legacy/modern status determining PCIe support, that PCIe status is
determining legacy/modern support by default?


Is more a guideline. We want QEMU to behave like this *by default*.
The modern spec does not require virtio 1.0 devices to be PCIe.


Ok.  But I'm trying to get a handle on how - even by default - the
linkage between PCI/PCIe and modern/legacy is created:  it's not
obvious to me.



There is no direct connection between modern/legacy <-> PCI/PCIe.
However the defaults work like that:
I440FX - (pc): devices are PCI, transitional
   created by: disable-legacy=auto,disable-modern=off
   - in virtio_pci_realize disable-legacy: auto => off
Q35 - on root bus - devices are PCI, transitional
- other buses - devices are PCIe, modern
   created by: disable-legacy=auto,disable-modern=off
   - in virtio_pci_dc_realize:
if disable-modern=off -> pcie
   - in virtio_pci_realize:
if on pcie root port -> disable-legacy: auto => on
otherwise ->disable-legacy: auto => off



  That would actually

seem to simplify things: whatever method we end up allowing PCIe
virtio on PAPR, that should automatically enable modern mode, which is
fine.



Agreed.


Although.. I do wonder about legacy/modern for PAPR in general.
Current kernels will support virtio 1.0 fine, but we have older
released versions which only support legacy.


So, do you want legacy virtio devices to be PCIe ?


TBH, we probably don't care one way or another.

I'm not clear here if you're making a distinction between legacy-only
and legacy+modern virtio instances.



Legacy devices and the modern ones are different devices (product ID).
I think the 'transitional' ones have the ID of the modern virtio.


I think we need to keep legacy support on for Power machines, because
we don't have the machine type switchover to let us handle it.  But we
certainly would like to enable modern support so that newer guests can
exploit it.



"transitional" is the right way to go.

Thanks,
Marcel


  Unlike PC we won't (I

hope) have a whole machine type switch to handle this.


Good for you!

  At this stage

I think we want virtio devices (whatever their bus type) on PAPR to
default to allowing both legacy and modern for the forseeable future.
How does that affect the matrix?



It adds a legacy virtio PCIe device to the matrix. For X86 we don't need
this combination because PC machines are PCI and Q35 machines are to be used
only on modern setups.

Since PARP does not have separate machines for PCi and PCIe, we need to live 
with it.



XHCI being PCIe on Root Complex is an unintended exception, but we want it 
connected to a
Root Port anyway, we don't have anything to gain from having it as Integrated 
Endpoint.
We only loose a slot that can be used by 8 Root Ports assembled into one 
multi-function device.

PAPR bus should not be considered PCIe and should have a different set of rules 
allowing PCIe
devices to be plugged into Root Complex.


Alright, I can work with that.  Michael, Andrea, how does this idea
seem to you?



We should definitely get more opinions.
Thanks,
Marcel

Re: [Qemu-devel] [PULL v2 00/23] Misc patches for 2017-02-16

[Peter Maydell]

On 16 February 2017 at 17:38, Paolo Bonzini  wrote:
> The following changes since commit 5dae13cd71f0755a1395b5a4cde635b8a6ee3f58:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-or-20170214' into 
> staging (2017-02-14 09:55:48 +)
>
> are available in the git repository at:
>
>
>   git://github.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 65c9d60a3ad3249784348824eca69acac455bc02:
>
>   target-i386: correctly propagate retaddr into SVM helpers (2017-02-16 
> 18:37:01 +0100)
>
> 
> * GUEST_PANICKED improvements (Anton)
> * vCont gdbstub rewrite (Claudio)
> * Fix CPU creation with -device (Liyang)
> * Logging fixes for pty chardevs (Ed)
> * Makefile "move if changed" fix (Lin)
> * First part of cpu_exec refactoring (me)
> * SVM emulation fix (me)
> * apic_delivered fix (Pavel)
> * "info ioapic" fix (Peter)
> * qemu-nbd socket activation (Richard)
> * QOMification of mcf_uart (Thomas)
>

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v7 4/8] ACPI: Add Virtual Machine Generation ID support

[Ben Warren]

> On Feb 16, 2017, at 11:03 AM, Laszlo Ersek  wrote:
> 
> On 02/16/17 19:32, Ben Warren wrote:
>> 
>>> On Feb 16, 2017, at 1:56 AM, Igor Mammedov  wrote:
>>> 
>>> On Wed, 15 Feb 2017 22:18:14 -0800
>>> b...@skyportsystems.com wrote:
>>> 
 From: Ben Warren 
 
 This implements the VM Generation ID feature by passing a 128-bit
 GUID to the guest via a fw_cfg blob.
 Any time the GUID changes, an ACPI notify event is sent to the guest
 
 The user interface is a simple device with one parameter:
 - guid (string, must be "auto" or in UUID format
  ----)
 
 Signed-off-by: Ben Warren 
>>> Reviewed-by: Igor Mammedov 
>>> 
>>> Thing to get fixed on top is to check
>>> that there isn't vmgenid device present already
>>> into realizefn() and fail gracefully is there is.
>>> 
>> I made the change as follows:
>> ===
>> 
>> diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
>> index c8465df..fa3de6d 100644
>> --- a/hw/acpi/vmgenid.c
>> +++ b/hw/acpi/vmgenid.c
>> @@ -207,8 +207,15 @@ static void vmgenid_handle_reset(void *opaque)
>> 
>> static void vmgenid_realize(DeviceState *dev, Error **errp)
>> {
>> +static bool is_realized = false;
>> VmGenIdState *vms = VMGENID(dev);
>> +
>> +if (is_realized) {
>> +error_setg(errp, "Device %s may only be specified once",
>> +   VMGENID_DEVICE);
>> +}
>> qemu_register_reset(vmgenid_handle_reset, vms);
>> +is_realized = true;
>> }
>> 
>> ===
>> Sample output:
>> $ ../workspace/qemu/x86_64-softmmu/qemu-system-x86_64 -nographic -bios 
>> ../workspace/seabios/out/bios.bin -machine type=q35 -hda 
>> beiwe-with-vmgenid-driver.qcow2 -qmp unix:./qmp-sock,server,nowait -device 
>> vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb66" -device 
>> vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb67"
>> qemu-system-x86_64: -device 
>> vmgenid,guid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb67: Device vmgenid may only 
>> be specified once
>> 
>> 
>> Good enough?  If so, I’ll roll it in.  Otherwise, it’ll be a supplemental 
>> patch.
> 
> Ehm, I'd say let's postpone that patch. Function (or even file) scope
> static variables that plaster over QOM shortcomings (or, well,
> "non-trivial QOM patterns") are strongly frowned upon. I've done it
> myself before (totally as a last resort, really -- not kidding!), and it
> was real hard to get into the tree.
> 
> This deserves more discussion, so please delay it.
> 
> (While at it, please remember my other recommendation for realize():
> enforcing that the running machine type / version provides the guest
> with the DMA interface for fw_cfg. For that, based on prior consensus,
> you'll need another device property, to be set in parallel to
> fw_cfg_mem's and fw_cfg_io's "dma-enabled" property. So I think it makes
> sense to address all of these things in a separate, followup series.)
> 
OK, makes sense.
> Thanks!
> Laszlo

—Ben



smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH v7 4/8] ACPI: Add Virtual Machine Generation ID support

[Laszlo Ersek]

On 02/16/17 19:32, Ben Warren wrote:
> 
>> On Feb 16, 2017, at 1:56 AM, Igor Mammedov  wrote:
>>
>> On Wed, 15 Feb 2017 22:18:14 -0800
>> b...@skyportsystems.com wrote:
>>
>>> From: Ben Warren 
>>>
>>> This implements the VM Generation ID feature by passing a 128-bit
>>> GUID to the guest via a fw_cfg blob.
>>> Any time the GUID changes, an ACPI notify event is sent to the guest
>>>
>>> The user interface is a simple device with one parameter:
>>> - guid (string, must be "auto" or in UUID format
>>>   ----)
>>>
>>> Signed-off-by: Ben Warren 
>> Reviewed-by: Igor Mammedov 
>>
>> Thing to get fixed on top is to check
>> that there isn't vmgenid device present already
>> into realizefn() and fail gracefully is there is.
>>
> I made the change as follows:
> ===
> 
> diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
> index c8465df..fa3de6d 100644
> --- a/hw/acpi/vmgenid.c
> +++ b/hw/acpi/vmgenid.c
> @@ -207,8 +207,15 @@ static void vmgenid_handle_reset(void *opaque)
>  
>  static void vmgenid_realize(DeviceState *dev, Error **errp)
>  {
> +static bool is_realized = false;
>  VmGenIdState *vms = VMGENID(dev);
> +
> +if (is_realized) {
> +error_setg(errp, "Device %s may only be specified once",
> +   VMGENID_DEVICE);
> +}
>  qemu_register_reset(vmgenid_handle_reset, vms);
> +is_realized = true;
>  }
> 
> ===
> Sample output:
> $ ../workspace/qemu/x86_64-softmmu/qemu-system-x86_64 -nographic -bios 
> ../workspace/seabios/out/bios.bin -machine type=q35 -hda 
> beiwe-with-vmgenid-driver.qcow2 -qmp unix:./qmp-sock,server,nowait -device 
> vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb66" -device 
> vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb67"
> qemu-system-x86_64: -device 
> vmgenid,guid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb67: Device vmgenid may only be 
> specified once
> 
> 
> Good enough?  If so, I’ll roll it in.  Otherwise, it’ll be a supplemental 
> patch.

Ehm, I'd say let's postpone that patch. Function (or even file) scope
static variables that plaster over QOM shortcomings (or, well,
"non-trivial QOM patterns") are strongly frowned upon. I've done it
myself before (totally as a last resort, really -- not kidding!), and it
was real hard to get into the tree.

This deserves more discussion, so please delay it.

(While at it, please remember my other recommendation for realize():
enforcing that the running machine type / version provides the guest
with the DMA interface for fw_cfg. For that, based on prior consensus,
you'll need another device property, to be set in parallel to
fw_cfg_mem's and fw_cfg_io's "dma-enabled" property. So I think it makes
sense to address all of these things in a separate, followup series.)

Thanks!
Laszlo

Re: [Qemu-devel] [PATCH] qemu-img: Do not truncate before preallocation

[Kevin Wolf]

Am 16.02.2017 um 19:23 hat Nir Soffer geschrieben:
> On Thu, Feb 16, 2017 at 7:52 PM, Kevin Wolf  wrote:
> > Am 03.02.2017 um 20:50 hat Nir Soffer geschrieben:
> >> When using file system that does not support fallocate() (e.g. NFS <
> >> 4.2), truncating the file only when preallocation=OFF speeds up creating
> >> raw file.
> >>
> >> Here is example run, tested on Fedora 24 machine, creating raw file on
> >> NFS version 3 server.
> >>
> >> $ time ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 1g
> >> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
> >>
> >> real  0m21.185s
> >> user  0m0.022s
> >> sys   0m0.574s
> >>
> >> $ time ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 1g
> >> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
> >>
> >> real  0m11.601s
> >> user  0m0.016s
> >> sys   0m0.525s
> >>
> >> $ time dd if=/dev/zero of=mnt/test bs=1M count=1024 oflag=direct
> >> 1024+0 records in
> >> 1024+0 records out
> >> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.6627 s, 68.6 MB/s
> >>
> >> real  0m16.104s
> >> user  0m0.009s
> >> sys   0m0.220s
> >>
> >> Running with strace we can see that without this change we do one
> >> pread() and one pwrite() for each block. With this change, we do only
> >> one pwrite() per block.
> >>
> >> $ strace ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 
> >> 8192
> >> ...
> >> pread64(9, "\0", 1, 4095)   = 1
> >> pwrite64(9, "\0", 1, 4095)  = 1
> >> pread64(9, "\0", 1, 8191)   = 1
> >> pwrite64(9, "\0", 1, 8191)  = 1
> >>
> >> $ strace ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 8192
> >> ...
> >> pwrite64(9, "\0", 1, 4095)  = 1
> >> pwrite64(9, "\0", 1, 8191)  = 1
> >>
> >> This happens because posix_fallocate is checking if each block is
> >> allocated before writing a byte to the block, and when truncating the
> >> file before preallocation, all blocks are unallocated.
> >>
> >> Signed-off-by: Nir Soffer 
> >
> > Thanks, applied to the block branch.
> >
> > I'm not completely sure if doing an ftruncate() first couldn't improve
> > PREALLOC_MODE_FULL somewhat in some cases, but I agree that the patch
> > should still result in correct images.
> 
> Good point, I'll do some tests with full mode to check this.
> 
> Do you know which cases can benefit from ftruncate() before full 
> preallocation?

Knowing the final size from the beginning could allow the file system
driver to do less allocations and possibly avoid fragmentation of the
file. I'm not sure if that's easily measurable, though.

I'd also expect that with XFS, you'll see no or less preallocation.
'du' often shows values much larger than the actual image size on XFS
because the file was growing a lot, so without having the actual size,
XFS takes a guess and does some generous preallocation.

Kevin

Re: [Qemu-devel] [PATCH 11/18] nbd: BLOCK_STATUS for bitmap export: server part

[Denis V. Lunev]

On 02/03/2017 06:47 PM, Vladimir Sementsov-Ogievskiy wrote:
> Only one meta context type is defined: qemu-bitmap:.
> Maximum one query is allowed for NBD_OPT_{SET,LIST}_META_CONTEXT,
> NBD_REP_ERR_TOO_BIG is returned otherwise.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
...
> +static int nbd_negotiate_opt_meta_context_start(NBDClient *client, uint32_t 
> opt,
> +uint32_t length,
> +uint32_t *nb_queries,
> +BlockDriverState **bs)
> +{
> +int ret;
> +NBDExport *exp;
> +char *export_name;
> +int nb_read = 0;
> +
> +if (!client->structured_reply) {
> +uint32_t tail = length - nb_read;
> +LOG("Structured reply is not negotiated");
> +
> +if (nbd_negotiate_drop_sync(client->ioc, tail) != tail) {
> +return -EIO;
> +}
> +ret = nbd_negotiate_send_rep_err(client->ioc, NBD_REP_ERR_INVALID, 
> opt,
> + "Structured reply is not 
> negotiated");
> +g_free(export_name);
export_name is not initialized here! for me there is no need to free
anything here


> +
> +if (ret < 0) {
> +return ret;
> +} else {
> +*bs = NULL;
> +*nb_queries = 0;
> +return length;
> +}
> +}
> +
> +nb_read = nbd_negotiate_read_size_string(client->ioc, _name,
> + NBD_MAX_NAME_SIZE);
> +if (nb_read < 0) {
> +return nb_read;
> +}
> +
> +exp = nbd_export_find(export_name);
> +if (exp == NULL) {
> +uint32_t tail = length - nb_read;
> +LOG("export '%s' is not found", export_name);
> +
> +if (nbd_negotiate_drop_sync(client->ioc, tail) != tail) {
export_name is leaked on this path

> +return -EIO;
> +}
> +ret = nbd_negotiate_send_rep_err(client->ioc, NBD_REP_ERR_INVALID, 
> opt,
> + "export '%s' is not found",
> + export_name);
> +g_free(export_name);
> +

Re: [Qemu-devel] [PATCH v7 4/8] ACPI: Add Virtual Machine Generation ID support

[Ben Warren]

> On Feb 16, 2017, at 1:56 AM, Igor Mammedov  wrote:
> 
> On Wed, 15 Feb 2017 22:18:14 -0800
> b...@skyportsystems.com wrote:
> 
>> From: Ben Warren 
>> 
>> This implements the VM Generation ID feature by passing a 128-bit
>> GUID to the guest via a fw_cfg blob.
>> Any time the GUID changes, an ACPI notify event is sent to the guest
>> 
>> The user interface is a simple device with one parameter:
>> - guid (string, must be "auto" or in UUID format
>>   ----)
>> 
>> Signed-off-by: Ben Warren 
> Reviewed-by: Igor Mammedov 
> 
> Thing to get fixed on top is to check
> that there isn't vmgenid device present already
> into realizefn() and fail gracefully is there is.
> 
I made the change as follows:
===

diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
index c8465df..fa3de6d 100644
--- a/hw/acpi/vmgenid.c
+++ b/hw/acpi/vmgenid.c
@@ -207,8 +207,15 @@ static void vmgenid_handle_reset(void *opaque)
 
 static void vmgenid_realize(DeviceState *dev, Error **errp)
 {
+static bool is_realized = false;
 VmGenIdState *vms = VMGENID(dev);
+
+if (is_realized) {
+error_setg(errp, "Device %s may only be specified once",
+   VMGENID_DEVICE);
+}
 qemu_register_reset(vmgenid_handle_reset, vms);
+is_realized = true;
 }

===
Sample output:
$ ../workspace/qemu/x86_64-softmmu/qemu-system-x86_64 -nographic -bios 
../workspace/seabios/out/bios.bin -machine type=q35 -hda 
beiwe-with-vmgenid-driver.qcow2 -qmp unix:./qmp-sock,server,nowait -device 
vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb66" -device 
vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb67"
qemu-system-x86_64: -device vmgenid,guid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb67: 
Device vmgenid may only be specified once


Good enough?  If so, I’ll roll it in.  Otherwise, it’ll be a supplemental patch.

—Ben



smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH v2 03/13] armv7m: Rewrite NVIC to not use any GIC code

[Peter Maydell]

On 16 February 2017 at 16:35, Peter Maydell  wrote:
> From: Michael Davidsaver 
>
> Despite some superficial similarities of register layout, the
> M-profile NVIC is really very different from the A-profile GIC.
> Our current attempt to reuse the GIC code means that we have
> significant bugs in our NVIC.
>
> Implement the NVIC as an entirely separate device, to give
> us somewhere we can get the behaviour correct.
>
> This initial commit does not attempt to implement exception
> priority escalation, since the GIC-based code didn't either.
> It does fix a few bugs in passing:
>  * ICSR.RETTOBASE polarity was wrong and didn't account for
>internal exceptions
>  * ICSR.VECTPENDING was 16 too high if the pending exception
>was for an external interrupt
>  * UsageFault, BusFault and MemFault were not disabled on reset
>as they are supposed to be
>
> Signed-off-by: Michael Davidsaver 
> [PMM: reworked, various bugs and stylistic cleanups]
> Signed-off-by: Peter Maydell 

> +case 0x400 ... 0x5ef: /* NVIC Priority */
> +startvec = 8 * (offset - 0x400) + NVIC_FIRST_IRQ; /* vector # */
> +
> +for (i = 0; i < size; i++) {

Just noticed this line should be
+for (i = 0; i < size && startvec + i < s->num_irq; i++) {

which brings it into line with the nvic_sysreg_read() code
and prevents an assert() in set_prio() if the guest writes to
registers beyond the end of the implemented IRQ range.

> +set_prio(s, startvec + i, (value >> (i * 8)) & 0xff);
> +}
> +nvic_irq_update(s);
> +return;

Unless there's some other problem that means I need
to respin anyway I propose to just squash in that fix.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] qemu-img: Do not truncate before preallocation

[Nir Soffer]

On Thu, Feb 16, 2017 at 7:52 PM, Kevin Wolf  wrote:
> Am 03.02.2017 um 20:50 hat Nir Soffer geschrieben:
>> When using file system that does not support fallocate() (e.g. NFS <
>> 4.2), truncating the file only when preallocation=OFF speeds up creating
>> raw file.
>>
>> Here is example run, tested on Fedora 24 machine, creating raw file on
>> NFS version 3 server.
>>
>> $ time ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 1g
>> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
>>
>> real  0m21.185s
>> user  0m0.022s
>> sys   0m0.574s
>>
>> $ time ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 1g
>> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
>>
>> real  0m11.601s
>> user  0m0.016s
>> sys   0m0.525s
>>
>> $ time dd if=/dev/zero of=mnt/test bs=1M count=1024 oflag=direct
>> 1024+0 records in
>> 1024+0 records out
>> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.6627 s, 68.6 MB/s
>>
>> real  0m16.104s
>> user  0m0.009s
>> sys   0m0.220s
>>
>> Running with strace we can see that without this change we do one
>> pread() and one pwrite() for each block. With this change, we do only
>> one pwrite() per block.
>>
>> $ strace ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 
>> 8192
>> ...
>> pread64(9, "\0", 1, 4095)   = 1
>> pwrite64(9, "\0", 1, 4095)  = 1
>> pread64(9, "\0", 1, 8191)   = 1
>> pwrite64(9, "\0", 1, 8191)  = 1
>>
>> $ strace ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 8192
>> ...
>> pwrite64(9, "\0", 1, 4095)  = 1
>> pwrite64(9, "\0", 1, 8191)  = 1
>>
>> This happens because posix_fallocate is checking if each block is
>> allocated before writing a byte to the block, and when truncating the
>> file before preallocation, all blocks are unallocated.
>>
>> Signed-off-by: Nir Soffer 
>
> Thanks, applied to the block branch.
>
> I'm not completely sure if doing an ftruncate() first couldn't improve
> PREALLOC_MODE_FULL somewhat in some cases, but I agree that the patch
> should still result in correct images.

Good point, I'll do some tests with full mode to check this.

Do you know which cases can benefit from ftruncate() before full preallocation?

Nir

Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems.

[Chad Joan]

I am glad others are chiming in and might provide better solutions.

Honestly, following the instructions at
http://wiki.qemu-project.org/Contribute/SubmitAPatch to-the-letter is quite
daunting to me, just to get one line of code changed.  It might help if
that page had some kind of dead-simple example for trivial patches;
something like:
$ cd 
$ git format-patch blah blah blah
$ maybe-some-other-command
$ # Now copy the contents of file xyz.patch into your email client and send
to qemu-devel@nongnu.org and qemu-triv...@nongnu.org

Ask me to do signing/secure-signatures/etc (or any foray into gnupg
commands), setup and secure new email connectivity (ex: git send-email), or
install new software on my system... and I'm going to bounce ;)  Sorry.

I kind of expected that discerning maintainers might want to do this patch
differently.  I'm not familiar with the why's of how your configure script
is organized, so I really hope the QEMU devs can meet me in the middle and
take this the rest of the way.  I am perfectly willing to run commands on
my machine and echo results to you if it helps you learn the nature of this
problem.

Hope that helps.
- Chad

On Thu, Feb 16, 2017 at 12:23 PM, Laszlo Ersek  wrote:

> On 02/16/17 17:58, Paolo Bonzini wrote:
> >
> >
> > On 16/02/2017 17:30, Chad Joan wrote:
> >> Hello,
> >>
> >> This is a one-line patch to the configure script that will allow QEMU
> to be
> >> built on musl-libc based Linux systems.  This problem is only noticeable
> >> when QEMU is built with --enable-curses.
> >>
> >> Detailed reading material if you want to know where this came from:
> >> https://bugs.gentoo.org/show_bug.cgi?id=609364
> >
> > Hi,
> >
> > can you explain exactly which function is missing without
> > -D_XOPEN_SOURCE=500?  If it is curses' wide-char functions, why does it
> > fail with musl but not with glibc?  Is _XOPEN_SOURCE always defined by
> > glibc if you have _D_GNU_SOURCE?
>
> It is not necessarily auto-defined, but the effect is "as if".
>
> It is documented in the libc info:
>
> https://www.gnu.org/software/libc/manual/html_node/Feature-
> Test-Macros.html#index-_005fXOPEN_005fSOURCE
>
> > Macro: _XOPEN_SOURCE
> > Macro: _XOPEN_SOURCE_EXTENDED
> >
> > If you define this macro, functionality described in the X/Open
> > Portability Guide is included. This is a superset of the POSIX.1
> > and POSIX.2 functionality and in fact _POSIX_SOURCE and
> > _POSIX_C_SOURCE are automatically defined.
> >
> > As the unification of all Unices, functionality only available in
> > BSD and SVID is also included.
> >
> > If the macro _XOPEN_SOURCE_EXTENDED is also defined, even more
> > functionality is available. The extra functions will make all
> > functions available which are necessary for the X/Open Unix brand.
> >
> > If the macro _XOPEN_SOURCE has the value 500 this includes all
> > functionality described so far plus some new definitions from the
> > Single Unix Specification, version 2.
>
> https://www.gnu.org/software/libc/manual/html_node/Feature-
> Test-Macros.html#index-_005fGNU_005fSOURCE
>
> > Macro: _GNU_SOURCE
> >
> > If you define this macro, everything is included: ISO C89, ISO
> > C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions.
> > In the cases where POSIX.1 conflicts with BSD, the POSIX
> > definitions take precedence.
>
> Curiously, I managed to recall this from years ago, when I was still
> living and breathing the SUS (and looking frequently at the glibc info
> too).
>
> Laszlo
>

Re: [Qemu-devel] [PULL 00/23] Misc patches for 2017-02-16

[Peter Maydell]

On 16 February 2017 at 14:31, Paolo Bonzini  wrote:
> The following changes since commit 5dae13cd71f0755a1395b5a4cde635b8a6ee3f58:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-or-20170214' into 
> staging (2017-02-14 09:55:48 +)
>
> are available in the git repository at:
>
>
>   git://github.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 395d41a549f69f4ec603afa3d3ade1e2005777d5:
>
>   target-i386: correctly propagate retaddr into SVM helpers (2017-02-16 
> 15:30:49 +0100)
>
> 
> * GUEST_PANICKED improvements (Anton)
> * vCont gdbstub rewrite (Claudio)
> * Fix CPU creation with -device (Liyang)
> * Logging fixes for pty chardevs (Ed)
> * Makefile "move if changed" fix (Lin)
> * First part of cpu_exec refactoring (me)
> * SVM emulation fix (me)
> * apic_delivered fix (Pavel)
> * "info ioapic" fix (Peter)
> * qemu-nbd socket activation (Richard)
> * QOMification of mcf_uart (Thomas)

Fails to build on 32-bit ARM:

/home/petmay01/qemu/target/i386/svm_helper.c:63:6: error: conflicting
types for 'cpu_v
mexit'
 void cpu_vmexit(CPUX86State *nenv, uint32_t exit_code, uint64_t exit_info_1,
  ^
In file included from /home/petmay01/qemu/target/i386/svm_helper.c:21:0:
/home/petmay01/qemu/target/i386/cpu.h:1625:6: note: previous
declaration of 'cpu_vmexit' was here
 void cpu_vmexit(CPUX86State *nenv, uint32_t exit_code, uint64_t exit_info_1,
  ^
/home/petmay01/qemu/rules.mak:69: recipe for target
'target/i386/svm_helper.o' failed

The problem is in the bit of the prototype the error message
doesn't quote:

Prototype in cpu.h:
  void cpu_vmexit(CPUX86State *nenv, uint32_t exit_code, uint64_t exit_info_1,
  uintptr_t retaddr);

svm_helper.c stub version;
  void cpu_vmexit(CPUX86State *nenv, uint32_t exit_code, uint64_t exit_info_1,
  uint64_t retaddr)

svm_helper.c real version:
  void cpu_vmexit(CPUX86State *env, uint32_t exit_code, uint64_t exit_info_1,
  uintptr_t retaddr)

On 32-bit uintptr_t and uint64_t aren't the same thing.

thanks
-- PMM

[Qemu-devel] [PATCH] lm32: milkymist-tmu2: fix a third integer overflow

[Peter Maydell]

Don't truncate the multiplication and do a 64 bit one instead
because the result is stored in a 64 bit variable.

This fixes a similar coverity warning to commits 237a8650d640 and
4382fa655498, in a similar way, and is the final third of the fix for
coverity CID 1167561 (hopefully!).

Signed-off-by: Peter Maydell 
---
Third time lucky -- I checked and this is the last of these
multiply lines.

 hw/display/milkymist-tmu2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/display/milkymist-tmu2.c b/hw/display/milkymist-tmu2.c
index 7528665..59120dd 100644
--- a/hw/display/milkymist-tmu2.c
+++ b/hw/display/milkymist-tmu2.c
@@ -293,7 +293,7 @@ static void tmu2_start(MilkymistTMU2State *s)
 cpu_physical_memory_unmap(mesh, mesh_len, 0, mesh_len);
 
 /* Write back the OpenGL framebuffer to the QEMU framebuffer */
-fb_len = 2 * s->regs[R_DSTHRES] * s->regs[R_DSTVRES];
+fb_len = 2ULL * s->regs[R_DSTHRES] * s->regs[R_DSTVRES];
 fb = cpu_physical_memory_map(s->regs[R_DSTFBUF], _len, 1);
 if (fb == NULL) {
 glDeleteTextures(1, );
-- 
2.7.4

[Qemu-devel] [PATCH] qmp-events: fix GUEST_PANICKED description formatting

[Anton Nefedov]

Signed-off-by: Anton Nefedov 
---
 qapi/event.json | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/qapi/event.json b/qapi/event.json
index 970ff02..e02852c 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -488,9 +488,9 @@
 #
 # @action: action that has been taken, currently always "pause"
 #
-# @info: optional information about a panic
+# @info: #optional information about a panic (since 2.9)
 #
-# Since: 1.5 (@info since 2.9)
+# Since: 1.5
 #
 # Example:
 #
-- 
2.7.4

Re: [Qemu-devel] [PATCH v7 3/8] ACPI: Add vmgenid blob storage to the build tables

[Laszlo Ersek]

On 02/16/17 07:18, b...@skyportsystems.com wrote:
> From: Ben Warren 
> 
> This allows them to be centrally initialized and destroyed
> 
> The "AcpiBuildTables.vmgenid" array will be used to construct the
> "etc/vmgenid_guid" fw_cfg blob.
> 
> Its contents will be linked into fw_cfg after being built on the
> pc_machine_done() -> acpi_setup() -> acpi_build() call path, and dropped
> without use on the subsequent, guest triggered, acpi_build_update() ->
> acpi_build() call path.
> 
> Signed-off-by: Ben Warren 
> Reviewed-by: Laszlo Ersek 
> Reviewed-by: Igor Mammedov 
> ---
>  hw/acpi/aml-build.c | 2 ++
>  include/hw/acpi/aml-build.h | 1 +
>  2 files changed, 3 insertions(+)

Tested-by: Laszlo Ersek 

[Qemu-devel] [PATCH v2 05/13] arm: gic: Remove references to NVIC

[Peter Maydell]

From: Michael Davidsaver 

Now that the NVIC is its own separate implementation, we can
clean up the GIC code by removing REV_NVIC and conditionals
which use it.

Signed-off-by: Michael Davidsaver 
Signed-off-by: Peter Maydell 
Reviewed-by: Alex Bennée 
---
 hw/intc/gic_internal.h   |  7 ++-
 hw/intc/arm_gic.c| 31 +--
 hw/intc/arm_gic_common.c | 23 ---
 3 files changed, 15 insertions(+), 46 deletions(-)

diff --git a/hw/intc/gic_internal.h b/hw/intc/gic_internal.h
index 3f31174..7fe87b1 100644
--- a/hw/intc/gic_internal.h
+++ b/hw/intc/gic_internal.h
@@ -25,9 +25,7 @@
 
 #define ALL_CPU_MASK ((unsigned)(((1 << GIC_NCPU) - 1)))
 
-/* The NVIC has 16 internal vectors.  However these are not exposed
-   through the normal GIC interface.  */
-#define GIC_BASE_IRQ ((s->revision == REV_NVIC) ? 32 : 0)
+#define GIC_BASE_IRQ 0
 
 #define GIC_SET_ENABLED(irq, cm) s->irq_state[irq].enabled |= (cm)
 #define GIC_CLEAR_ENABLED(irq, cm) s->irq_state[irq].enabled &= ~(cm)
@@ -75,7 +73,6 @@
 
 /* The special cases for the revision property: */
 #define REV_11MPCORE 0
-#define REV_NVIC 0x
 
 void gic_set_pending_private(GICState *s, int cpu, int irq);
 uint32_t gic_acknowledge_irq(GICState *s, int cpu, MemTxAttrs attrs);
@@ -87,7 +84,7 @@ void gic_set_priority(GICState *s, int cpu, int irq, uint8_t 
val,
 
 static inline bool gic_test_pending(GICState *s, int irq, int cm)
 {
-if (s->revision == REV_NVIC || s->revision == REV_11MPCORE) {
+if (s->revision == REV_11MPCORE) {
 return s->irq_state[irq].pending & cm;
 } else {
 /* Edge-triggered interrupts are marked pending on a rising edge, but
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 521aac3..8e5a9d8 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -156,17 +156,6 @@ static void gic_set_irq_11mpcore(GICState *s, int irq, int 
level,
 }
 }
 
-static void gic_set_irq_nvic(GICState *s, int irq, int level,
- int cm, int target)
-{
-if (level) {
-GIC_SET_LEVEL(irq, cm);
-GIC_SET_PENDING(irq, target);
-} else {
-GIC_CLEAR_LEVEL(irq, cm);
-}
-}
-
 static void gic_set_irq_generic(GICState *s, int irq, int level,
 int cm, int target)
 {
@@ -214,8 +203,6 @@ static void gic_set_irq(void *opaque, int irq, int level)
 
 if (s->revision == REV_11MPCORE) {
 gic_set_irq_11mpcore(s, irq, level, cm, target);
-} else if (s->revision == REV_NVIC) {
-gic_set_irq_nvic(s, irq, level, cm, target);
 } else {
 gic_set_irq_generic(s, irq, level, cm, target);
 }
@@ -367,7 +354,7 @@ uint32_t gic_acknowledge_irq(GICState *s, int cpu, 
MemTxAttrs attrs)
 return 1023;
 }
 
-if (s->revision == REV_11MPCORE || s->revision == REV_NVIC) {
+if (s->revision == REV_11MPCORE) {
 /* Clear pending flags for both level and edge triggered interrupts.
  * Level triggered IRQs will be reasserted once they become inactive.
  */
@@ -589,11 +576,6 @@ void gic_complete_irq(GICState *s, int cpu, int irq, 
MemTxAttrs attrs)
 DPRINTF("Set %d pending mask %x\n", irq, cm);
 GIC_SET_PENDING(irq, cm);
 }
-} else if (s->revision == REV_NVIC) {
-if (GIC_TEST_LEVEL(irq, cm)) {
-DPRINTF("Set nvic %d pending mask %x\n", irq, cm);
-GIC_SET_PENDING(irq, cm);
-}
 }
 
 group = gic_has_groups(s) && GIC_TEST_GROUP(irq, cm);
@@ -768,7 +750,7 @@ static uint32_t gic_dist_readb(void *opaque, hwaddr offset, 
MemTxAttrs attrs)
 } else if (offset < 0xf10) {
 goto bad_reg;
 } else if (offset < 0xf30) {
-if (s->revision == REV_11MPCORE || s->revision == REV_NVIC) {
+if (s->revision == REV_11MPCORE) {
 goto bad_reg;
 }
 
@@ -802,9 +784,6 @@ static uint32_t gic_dist_readb(void *opaque, hwaddr offset, 
MemTxAttrs attrs)
 case 2:
 res = gic_id_gicv2[(offset - 0xfd0) >> 2];
 break;
-case REV_NVIC:
-/* Shouldn't be able to get here */
-abort();
 default:
 res = 0;
 }
@@ -1028,7 +1007,7 @@ static void gic_dist_writeb(void *opaque, hwaddr offset,
 continue; /* Ignore Non-secure access of Group0 IRQ */
 }
 
-if (s->revision == REV_11MPCORE || s->revision == REV_NVIC) {
+if (s->revision == REV_11MPCORE) {
 if (value & (1 << (i * 2))) {
 GIC_SET_MODEL(irq + i);
 } else {
@@ -1046,7 +1025,7 @@ static void gic_dist_writeb(void *opaque, hwaddr offset,
 goto bad_reg;
 } else if (offset < 0xf20) {
 /* GICD_CPENDSGIRn */
-if (s->revision == REV_11MPCORE || s->revision == REV_NVIC) {

Re: [Qemu-devel] [PATCH] qemu-img: Do not truncate before preallocation

[Kevin Wolf]

Am 03.02.2017 um 20:50 hat Nir Soffer geschrieben:
> When using file system that does not support fallocate() (e.g. NFS <
> 4.2), truncating the file only when preallocation=OFF speeds up creating
> raw file.
> 
> Here is example run, tested on Fedora 24 machine, creating raw file on
> NFS version 3 server.
> 
> $ time ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 1g
> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
> 
> real  0m21.185s
> user  0m0.022s
> sys   0m0.574s
> 
> $ time ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 1g
> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
> 
> real  0m11.601s
> user  0m0.016s
> sys   0m0.525s
> 
> $ time dd if=/dev/zero of=mnt/test bs=1M count=1024 oflag=direct
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.6627 s, 68.6 MB/s
> 
> real  0m16.104s
> user  0m0.009s
> sys   0m0.220s
> 
> Running with strace we can see that without this change we do one
> pread() and one pwrite() for each block. With this change, we do only
> one pwrite() per block.
> 
> $ strace ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 8192
> ...
> pread64(9, "\0", 1, 4095)   = 1
> pwrite64(9, "\0", 1, 4095)  = 1
> pread64(9, "\0", 1, 8191)   = 1
> pwrite64(9, "\0", 1, 8191)  = 1
> 
> $ strace ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 8192
> ...
> pwrite64(9, "\0", 1, 4095)  = 1
> pwrite64(9, "\0", 1, 8191)  = 1
> 
> This happens because posix_fallocate is checking if each block is
> allocated before writing a byte to the block, and when truncating the
> file before preallocation, all blocks are unallocated.
> 
> Signed-off-by: Nir Soffer 

Thanks, applied to the block branch.

I'm not completely sure if doing an ftruncate() first couldn't improve
PREALLOC_MODE_FULL somewhat in some cases, but I agree that the patch
should still result in correct images.

KEvin

[Qemu-devel] [PULL 23/23] target-i386: correctly propagate retaddr into SVM helpers

[Paolo Bonzini]

Commit 2afbdf8 ("target-i386: exception handling for memory helpers",
2015-09-15) changed tlb_fill's cpu_restore_state+raise_exception_err
to raise_exception_err_ra.  After this change, the cpu_restore_state
and raise_exception_err's cpu_loop_exit are merged into
raise_exception_err_ra's cpu_loop_exit_restore.

This actually fixed some bugs, but when SVM is enabled there is a
second path from raise_exception_err_ra to cpu_loop_exit.  This is
the VMEXIT path, and now cpu_vmexit is called without a
cpu_restore_state before.

The fix is to pass the retaddr to cpu_vmexit (via
cpu_svm_check_intercept_param).  All helpers can now use GETPC() to pass
the correct retaddr, too.

Cc: qemu-sta...@nongnu.org
Fixes: 2afbdf84807d673eb682cb78158e11cdacbf4673
Reported-by: Alexander Boettcher 
Tested-by: Alexander Boettcher 
Signed-off-by: Paolo Bonzini 
---
 cpu-exec.c|  2 +-
 target/i386/cpu.h |  5 ++--
 target/i386/excp_helper.c | 11 
 target/i386/helper.h  |  1 -
 target/i386/misc_helper.c | 24 -
 target/i386/seg_helper.c  |  6 ++---
 target/i386/svm_helper.c  | 65 ++-
 7 files changed, 56 insertions(+), 58 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index b8ebb5c..142a586 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -491,7 +491,7 @@ static inline bool cpu_handle_interrupt(CPUState *cpu,
 X86CPU *x86_cpu = X86_CPU(cpu);
 CPUArchState *env = _cpu->env;
 replay_interrupt();
-cpu_svm_check_intercept_param(env, SVM_EXIT_INIT, 0);
+cpu_svm_check_intercept_param(env, SVM_EXIT_INIT, 0, 0);
 do_cpu_init(x86_cpu);
 cpu->exception_index = EXCP_HALTED;
 return true;
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 4d788d5..8df124f 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1621,8 +1621,9 @@ void helper_lock_init(void);
 
 /* svm_helper.c */
 void cpu_svm_check_intercept_param(CPUX86State *env1, uint32_t type,
-   uint64_t param);
-void cpu_vmexit(CPUX86State *nenv, uint32_t exit_code, uint64_t exit_info_1);
+   uint64_t param, uintptr_t retaddr);
+void cpu_vmexit(CPUX86State *nenv, uint32_t exit_code, uint64_t exit_info_1,
+uintptr_t retaddr);
 
 /* seg_helper.c */
 void do_interrupt_x86_hardirq(CPUX86State *env, int intno, int is_hw);
diff --git a/target/i386/excp_helper.c b/target/i386/excp_helper.c
index f0dc499..ee596c6 100644
--- a/target/i386/excp_helper.c
+++ b/target/i386/excp_helper.c
@@ -39,7 +39,8 @@ void helper_raise_exception(CPUX86State *env, int 
exception_index)
  * needed. It should only be called, if this is not an interrupt.
  * Returns the new exception number.
  */
-static int check_exception(CPUX86State *env, int intno, int *error_code)
+static int check_exception(CPUX86State *env, int intno, int *error_code,
+   uintptr_t retaddr)
 {
 int first_contributory = env->old_exception == 0 ||
   (env->old_exception >= 10 &&
@@ -53,7 +54,7 @@ static int check_exception(CPUX86State *env, int intno, int 
*error_code)
 #if !defined(CONFIG_USER_ONLY)
 if (env->old_exception == EXCP08_DBLE) {
 if (env->hflags & HF_SVMI_MASK) {
-cpu_vmexit(env, SVM_EXIT_SHUTDOWN, 0); /* does not return */
+cpu_vmexit(env, SVM_EXIT_SHUTDOWN, 0, retaddr); /* does not return 
*/
 }
 
 qemu_log_mask(CPU_LOG_RESET, "Triple fault\n");
@@ -93,10 +94,10 @@ static void QEMU_NORETURN raise_interrupt2(CPUX86State 
*env, int intno,
 
 if (!is_int) {
 cpu_svm_check_intercept_param(env, SVM_EXIT_EXCP_BASE + intno,
-  error_code);
-intno = check_exception(env, intno, _code);
+  error_code, retaddr);
+intno = check_exception(env, intno, _code, retaddr);
 } else {
-cpu_svm_check_intercept_param(env, SVM_EXIT_SWINT, 0);
+cpu_svm_check_intercept_param(env, SVM_EXIT_SWINT, 0, retaddr);
 }
 
 cs->exception_index = intno;
diff --git a/target/i386/helper.h b/target/i386/helper.h
index 4c1aaff..6fb8fb9 100644
--- a/target/i386/helper.h
+++ b/target/i386/helper.h
@@ -99,7 +99,6 @@ DEF_HELPER_2(inl, tl, env, i32)
 DEF_HELPER_FLAGS_4(bpt_io, TCG_CALL_NO_WG, void, env, i32, i32, tl)
 
 DEF_HELPER_3(svm_check_intercept_param, void, env, i32, i64)
-DEF_HELPER_3(vmexit, void, env, i32, i64)
 DEF_HELPER_4(svm_check_io, void, env, i32, i32, i32)
 DEF_HELPER_3(vmrun, void, env, int, int)
 DEF_HELPER_1(vmmcall, void, env)
diff --git a/target/i386/misc_helper.c b/target/i386/misc_helper.c
index 5029efe..ca2ea09 100644
--- a/target/i386/misc_helper.c
+++ b/target/i386/misc_helper.c
@@ -101,7 +101,7 @@ void helper_cpuid(CPUX86State *env)
 {
 

[Qemu-devel] [PATCH v2 07/13] armv7m: Remove unused armv7m_nvic_acknowledge_irq() return value

[Peter Maydell]

Having armv7m_nvic_acknowledge_irq() return the new value of
env->v7m.exception and its one caller assign the return value
back to env->v7m.exception is pointless. Just make the return
type void instead.

Signed-off-by: Peter Maydell 
Reviewed-by: Alex Bennée 
---
 target/arm/cpu.h  | 2 +-
 hw/intc/armv7m_nvic.c | 4 +---
 target/arm/helper.c   | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 53299fa..ab46c0c 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1351,7 +1351,7 @@ static inline bool 
armv7m_nvic_can_take_pending_exception(void *opaque)
 }
 #endif
 void armv7m_nvic_set_pending(void *opaque, int irq);
-int armv7m_nvic_acknowledge_irq(void *opaque);
+void armv7m_nvic_acknowledge_irq(void *opaque);
 void armv7m_nvic_complete_irq(void *opaque, int irq);
 
 /* Interface for defining coprocessor registers.
diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index d9b9a43..010bf92 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -412,7 +412,7 @@ void armv7m_nvic_set_pending(void *opaque, int irq)
 }
 
 /* Make pending IRQ active.  */
-int armv7m_nvic_acknowledge_irq(void *opaque)
+void armv7m_nvic_acknowledge_irq(void *opaque)
 {
 NVICState *s = (NVICState *)opaque;
 CPUARMState *env = >cpu->env;
@@ -439,8 +439,6 @@ int armv7m_nvic_acknowledge_irq(void *opaque)
 env->v7m.exception = s->vectpending;
 
 nvic_irq_update(s);
-
-return env->v7m.exception;
 }
 
 void armv7m_nvic_complete_irq(void *opaque, int irq)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index bac1718..050d8df 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6141,7 +6141,7 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
 armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_DEBUG);
 return;
 case EXCP_IRQ:
-env->v7m.exception = armv7m_nvic_acknowledge_irq(env->nvic);
+armv7m_nvic_acknowledge_irq(env->nvic);
 break;
 case EXCP_EXCEPTION_EXIT:
 do_v7m_exception_exit(env);
-- 
2.7.4

[Qemu-devel] [PATCH v2 09/13] armv7m: VECTCLRACTIVE and VECTRESET are UNPREDICTABLE

[Peter Maydell]

From: Michael Davidsaver 

The VECTCLRACTIVE and VECTRESET bits in the AIRCR are both
documented as UNPREDICTABLE if you write a 1 to them when
the processor is not halted in Debug state (ie stopped
and under the control of an external JTAG debugger).
Since we don't implement Debug state or emulated JTAG
these bits are always UNPREDICTABLE for us. Instead of
logging them as unimplemented we can simply log writes
as guest errors and ignore them.

Signed-off-by: Michael Davidsaver 
[PMM: change extracted from another patch; commit message
 constructed from scratch]
Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Alex Bennée 
---
 hw/intc/armv7m_nvic.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index 010bf92..ca4fb49 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -716,10 +716,14 @@ static void nvic_writel(NVICState *s, uint32_t offset, 
uint32_t value)
 qemu_irq_pulse(s->sysresetreq);
 }
 if (value & 2) {
-qemu_log_mask(LOG_UNIMP, "VECTCLRACTIVE unimplemented\n");
+qemu_log_mask(LOG_GUEST_ERROR,
+  "Setting VECTCLRACTIVE when not in DEBUG mode "
+  "is UNPREDICTABLE\n");
 }
 if (value & 1) {
-qemu_log_mask(LOG_UNIMP, "AIRCR system reset unimplemented\n");
+qemu_log_mask(LOG_GUEST_ERROR,
+  "Setting VECTRESET when not in DEBUG mode "
+  "is UNPREDICTABLE\n");
 }
 s->prigroup = extract32(value, 8, 3);
 nvic_irq_update(s);
-- 
2.7.4

Re: [Qemu-devel] [PULL 00/23] Misc patches for 2017-02-16

[Paolo Bonzini]

> The problem is in the bit of the prototype the error message
> doesn't quote:
> 
> Prototype in cpu.h:
>   void cpu_vmexit(CPUX86State *nenv, uint32_t exit_code, uint64_t
>   exit_info_1,
>   uintptr_t retaddr);
> 
> svm_helper.c stub version;
>   void cpu_vmexit(CPUX86State *nenv, uint32_t exit_code, uint64_t
>   exit_info_1,
>   uint64_t retaddr)
> 
> svm_helper.c real version:
>   void cpu_vmexit(CPUX86State *env, uint32_t exit_code, uint64_t exit_info_1,
>   uintptr_t retaddr)
> 
> On 32-bit uintptr_t and uint64_t aren't the same thing.

Saw the same on mingw, must have forgotten to "commit --amend".

Paolo

[Qemu-devel] [PATCH v2 12/13] armv7m: Raise correct kind of UsageFault for attempts to execute ARM code

[Peter Maydell]

M profile doesn't implement ARM, and the architecturally required
behaviour for attempts to execute with the Thumb bit clear is to
generate a UsageFault with the CFSR INVSTATE bit set.  We were
incorrectly implementing this as generating an UNDEFINSTR UsageFault;
fix this.

Signed-off-by: Peter Maydell 
---
 target/arm/cpu.h   | 1 +
 linux-user/main.c  | 1 +
 target/arm/helper.c| 4 
 target/arm/translate.c | 8 ++--
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 017e301..228747f 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -54,6 +54,7 @@
 #define EXCP_VFIQ   15
 #define EXCP_SEMIHOST   16   /* semihosting call */
 #define EXCP_NOCP   17   /* v7M NOCP UsageFault */
+#define EXCP_INVSTATE   18   /* v7M INVSTATE UsageFault */
 
 #define ARMV7M_EXCP_RESET   1
 #define ARMV7M_EXCP_NMI 2
diff --git a/linux-user/main.c b/linux-user/main.c
index 4fd49ce..b6043d8 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -574,6 +574,7 @@ void cpu_loop(CPUARMState *env)
 switch(trapnr) {
 case EXCP_UDEF:
 case EXCP_NOCP:
+case EXCP_INVSTATE:
 {
 TaskState *ts = cs->opaque;
 uint32_t opcode;
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 6a476b4..948aba2 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6244,6 +6244,10 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
 armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_USAGE);
 env->v7m.cfsr |= R_V7M_CFSR_NOCP_MASK;
 break;
+case EXCP_INVSTATE:
+armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_USAGE);
+env->v7m.cfsr |= R_V7M_CFSR_INVSTATE_MASK;
+break;
 case EXCP_SWI:
 /* The PC already points to the next instruction.  */
 armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_SVC);
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 4436d8f..9fded03 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -7978,9 +7978,13 @@ static void disas_arm_insn(DisasContext *s, unsigned int 
insn)
 TCGv_i32 addr;
 TCGv_i64 tmp64;
 
-/* M variants do not implement ARM mode.  */
+/* M variants do not implement ARM mode; this must raise the INVSTATE
+ * UsageFault exception.
+ */
 if (arm_dc_feature(s, ARM_FEATURE_M)) {
-goto illegal_op;
+gen_exception_insn(s, 4, EXCP_INVSTATE, syn_uncategorized(),
+   default_exception_el(s));
+return;
 }
 cond = insn >> 28;
 if (cond == 0xf){
-- 
2.7.4

Re: [Qemu-devel] [PATCH] linux-user: fix fork()

[Peter Maydell]

On 16 February 2017 at 17:37, Laurent Vivier  wrote:
> Since commit 5ea2fc8 ("linux-user: Sanity check clone flags"),
> trying to run fork() fails with old distro on some architectures.
>
> This is the case with HP-PA and Debian 5 (Lenny).
>
> It fails on:
>
>  if ((flags & CSIGNAL) != TARGET_SIGCHLD) {
>  return -TARGET_EINVAL;
>  }
>
> because flags is 17, whereas on HP-PA, SIGCHLD is 18.
> 17 is the SIGCHLD value of my host (x86_64).
>
> It appears that for TARGET_NR_fork and TARGET_NR_vfork, QEMU calls
> do_fork() with SIGCHLD instead of TARGET_SIGCHLD.
>
> Signed-off-by: Laurent Vivier 
> ---
>  linux-user/syscall.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index f569f82..4d85355 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -7680,7 +7680,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  break;
>  #ifdef TARGET_NR_fork
>  case TARGET_NR_fork:
> -ret = get_errno(do_fork(cpu_env, SIGCHLD, 0, 0, 0, 0));
> +ret = get_errno(do_fork(cpu_env, TARGET_SIGCHLD, 0, 0, 0, 0));
>  break;
>  #endif
>  #ifdef TARGET_NR_waitpid
> @@ -10490,7 +10490,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  #endif
>  #ifdef TARGET_NR_vfork
>  case TARGET_NR_vfork:
> -ret = get_errno(do_fork(cpu_env, CLONE_VFORK | CLONE_VM | SIGCHLD,
> +ret = get_errno(do_fork(cpu_env,
> +CLONE_VFORK | CLONE_VM | TARGET_SIGCHLD,
>  0, 0, 0, 0));
>  break;
>  #endif

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [Qemu-devel] [PATCH] qemu-img: Do not truncate before preallocation

[Nir Soffer]

Ping

On Fri, Feb 3, 2017 at 9:50 PM, Nir Soffer  wrote:
> When using file system that does not support fallocate() (e.g. NFS <
> 4.2), truncating the file only when preallocation=OFF speeds up creating
> raw file.
>
> Here is example run, tested on Fedora 24 machine, creating raw file on
> NFS version 3 server.
>
> $ time ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 1g
> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
>
> real0m21.185s
> user0m0.022s
> sys 0m0.574s
>
> $ time ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 1g
> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
>
> real0m11.601s
> user0m0.016s
> sys 0m0.525s
>
> $ time dd if=/dev/zero of=mnt/test bs=1M count=1024 oflag=direct
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.6627 s, 68.6 MB/s
>
> real0m16.104s
> user0m0.009s
> sys 0m0.220s
>
> Running with strace we can see that without this change we do one
> pread() and one pwrite() for each block. With this change, we do only
> one pwrite() per block.
>
> $ strace ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 8192
> ...
> pread64(9, "\0", 1, 4095)   = 1
> pwrite64(9, "\0", 1, 4095)  = 1
> pread64(9, "\0", 1, 8191)   = 1
> pwrite64(9, "\0", 1, 8191)  = 1
>
> $ strace ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 8192
> ...
> pwrite64(9, "\0", 1, 4095)  = 1
> pwrite64(9, "\0", 1, 8191)  = 1
>
> This happens because posix_fallocate is checking if each block is
> allocated before writing a byte to the block, and when truncating the
> file before preallocation, all blocks are unallocated.
>
> Signed-off-by: Nir Soffer 
> ---
>
> I sent this a week ago:
> http://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg06123.html
>
> Sending again with improved commit message.
>
>  block/file-posix.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 2134e0e..442f080 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -1591,12 +1591,6 @@ static int raw_create(const char *filename, QemuOpts 
> *opts, Error **errp)
>  #endif
>  }
>
> -if (ftruncate(fd, total_size) != 0) {
> -result = -errno;
> -error_setg_errno(errp, -result, "Could not resize file");
> -goto out_close;
> -}
> -
>  switch (prealloc) {
>  #ifdef CONFIG_POSIX_FALLOCATE
>  case PREALLOC_MODE_FALLOC:
> @@ -1636,6 +1630,10 @@ static int raw_create(const char *filename, QemuOpts 
> *opts, Error **errp)
>  break;
>  }
>  case PREALLOC_MODE_OFF:
> +if (ftruncate(fd, total_size) != 0) {
> +result = -errno;
> +error_setg_errno(errp, -result, "Could not resize file");
> +}
>  break;
>  default:
>  result = -EINVAL;
> @@ -1644,7 +1642,6 @@ static int raw_create(const char *filename, QemuOpts 
> *opts, Error **errp)
>  break;
>  }
>
> -out_close:
>  if (qemu_close(fd) != 0 && result == 0) {
>  result = -errno;
>  error_setg_errno(errp, -result, "Could not close the new file");
> --
> 2.9.3
>

Re: [Qemu-devel] [PATCH 0/6] Make CoMutex/CoQueue/CoRwlock thread-safe

[Stefan Hajnoczi]

On Mon, Feb 13, 2017 at 07:12:38PM +0100, Paolo Bonzini wrote:
> This is yet another tiny bit of the multiqueue work, this time affecting
> the synchronization infrastructure for coroutines.  Currently, coroutines
> synchronize between the main I/O thread and the dataplane iothread through
> the AioContext lock.  However, for multiqueue a single BDS will be used
> by multiple iothreads and hence multiple AioContexts.  This calls for
> a different approach to coroutine synchronization, and this series is my
> attempt.
> 
> After the previous series, coroutines are already bound to an AioContext
> while they wait on a CoMutex.  Of course currently a CoMutex is generally
> not used across multiple iothreads, because you have to acquire/release
> the AioContext around CoMutex critical sections.  This series is the
> missing link between the aio_co_schedule/aio_co_wake infrastructure and
> making BDS thread-safe: by making CoMutex thread-safe, it removes
> the need for a "thread-based" mutex around it.
> 
> This will still need some changes in the formats because, for multiqueue,
> CoMutexes would need to be used like "real" thread mutexes.  Code like
> this:
> 
> ...
> qemu_co_mutex_unlock()
> ... /* still access shared data, but don't yield */
> qemu_coroutine_yield()
> 
> might be required to use this other pattern:
> 
> ... /* access shared data, but don't yield */
> qemu_co_mutex_unlock()
> qemu_coroutine_yield()
> 
> because adding a second AioContext is already introducing concurrency that
> wasn't there before.  Still, even if you have to take concurrency into
> account, multitasking between coroutines remains non-preemptive.  So for
> example, it is easy to synchronize between qemu_co_mutex_lock's yield
> and the qemu_coroutine_enter in aio_co_schedule's bottom half.
> 
> CoMutex puts coroutines to sleep with qemu_coroutine_yield and wake them
> up with aio_co_wake.  I could have wrapped CoMutex's CoQueue with
> a "regular" thread mutex or spinlock.  The resulting code would
> have looked a lot like RFifoLock (with CoQueue replacing RFifoLock's
> condition variable).  Instead, CoMutex is implemented from scratch and
> CoQueue is made to depend on a CoMutex, similar to condition variables.
> Most CoQueues already have a corresponding CoMutex so this is not a big
> deal; converting the others is left for a future series, but a surprising
> number of drivers actually need no change.
> 
> The mutex algorithm comes from OSv; it only needs two to four atomic ops
> for a lock-unlock pair (two when uncontended) and if necessary
> we could even take OSv's support for wait morphing (which avoids the
> thundering herd problem) and add it to CoMutex and CoQueue.
> 
> Performance of CoMutex is comparable to pthread mutexes.  However, you
> cannot make a direct comparison between CoMutex (fair) and pthread_mutex_t
> (unfair).  For this reason the testcase also measures performance of
> a quick-and-dirty implementation of a fair mutex, based on MCS locks
> and futexes.
> 
> Paolo
> 
> Paolo Bonzini (6):
>   coroutine-lock: make CoMutex thread-safe
>   coroutine-lock: add limited spinning to CoMutex
>   test-aio-multithread: add performance comparison with thread-based
> mutexes
>   coroutine-lock: place CoMutex before CoQueue in header
>   coroutine-lock: add mutex argument to CoQueue APIs
>   coroutine-lock: make CoRwlock thread-safe and fair
> 
>  block/backup.c   |   2 +-
>  block/io.c   |   4 +-
>  block/nbd-client.c   |   2 +-
>  block/qcow2-cluster.c|   4 +-
>  block/sheepdog.c |   2 +-
>  block/throttle-groups.c  |   2 +-
>  hw/9pfs/9p.c |   2 +-
>  include/qemu/coroutine.h |  84 +--
>  tests/test-aio-multithread.c | 250 
> +++
>  util/qemu-coroutine-lock.c   | 247 ++
>  util/qemu-coroutine.c|   2 +-
>  util/trace-events|   1 +
>  12 files changed, 537 insertions(+), 65 deletions(-)
> 
> -- 
> 2.9.3
> 

Thanks, applied to my block tree:
https://github.com/stefanha/qemu/commits/block

Stefan


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH v2 13/13] armv7m: Allow SHCSR writes to change pending and active bits

[Peter Maydell]

Implement the NVIC SHCSR write behaviour which allows pending and
active status of some exceptions to be changed.

Signed-off-by: Peter Maydell 
---
 hw/intc/armv7m_nvic.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
index a8c5a9e..1d34e0d 100644
--- a/hw/intc/armv7m_nvic.c
+++ b/hw/intc/armv7m_nvic.c
@@ -755,8 +755,17 @@ static void nvic_writel(NVICState *s, uint32_t offset, 
uint32_t value)
 cpu->env.v7m.ccr = value;
 break;
 case 0xd24: /* System Handler Control.  */
-/* TODO: Real hardware allows you to set/clear the active bits
-   under some circumstances.  We don't implement this.  */
+s->vectors[ARMV7M_EXCP_MEM].active = (value & (1 << 0)) != 0;
+s->vectors[ARMV7M_EXCP_BUS].active = (value & (1 << 1)) != 0;
+s->vectors[ARMV7M_EXCP_USAGE].active = (value & (1 << 3)) != 0;
+s->vectors[ARMV7M_EXCP_SVC].active = (value & (1 << 7)) != 0;
+s->vectors[ARMV7M_EXCP_DEBUG].active = (value & (1 << 8)) != 0;
+s->vectors[ARMV7M_EXCP_PENDSV].active = (value & (1 << 10)) != 0;
+s->vectors[ARMV7M_EXCP_SYSTICK].active = (value & (1 << 11)) != 0;
+s->vectors[ARMV7M_EXCP_USAGE].pending = (value & (1 << 12)) != 0;
+s->vectors[ARMV7M_EXCP_MEM].pending = (value & (1 << 13)) != 0;
+s->vectors[ARMV7M_EXCP_BUS].pending = (value & (1 << 14)) != 0;
+s->vectors[ARMV7M_EXCP_SVC].pending = (value & (1 << 15)) != 0;
 s->vectors[ARMV7M_EXCP_MEM].enabled = (value & (1 << 16)) != 0;
 s->vectors[ARMV7M_EXCP_BUS].enabled = (value & (1 << 17)) != 0;
 s->vectors[ARMV7M_EXCP_USAGE].enabled = (value & (1 << 18)) != 0;
-- 
2.7.4

[Qemu-devel] [PULL v2 00/23] Misc patches for 2017-02-16

[Paolo Bonzini]

The following changes since commit 5dae13cd71f0755a1395b5a4cde635b8a6ee3f58:

  Merge remote-tracking branch 'remotes/rth/tags/pull-or-20170214' into staging 
(2017-02-14 09:55:48 +)

are available in the git repository at:


  git://github.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to 65c9d60a3ad3249784348824eca69acac455bc02:

  target-i386: correctly propagate retaddr into SVM helpers (2017-02-16 
18:37:01 +0100)


* GUEST_PANICKED improvements (Anton)
* vCont gdbstub rewrite (Claudio)
* Fix CPU creation with -device (Liyang)
* Logging fixes for pty chardevs (Ed)
* Makefile "move if changed" fix (Lin)
* First part of cpu_exec refactoring (me)
* SVM emulation fix (me)
* apic_delivered fix (Pavel)
* "info ioapic" fix (Peter)
* qemu-nbd socket activation (Richard)
* QOMification of mcf_uart (Thomas)


Alberto Garcia (1):
  qemu-doc: Clarify that -vga std is now the default

Anton Nefedov (4):
  qemu-char: socket backend: disconnect on write error
  i386/cpu: add crash-information QOM property
  report guest crash information in GUEST_PANICKED event
  vl: log available guest crash information

Claudio Imbrenda (2):
  move vm_start to cpus.c
  gdbstub: Fix vCont behaviour

Dou Liyang (1):
  vl: Move the cpu_synchronize_all_post_init() after generic devices 
initialization

Ed Swierk (1):
  char: drop data written to a disconnected pty

Lin Ma (1):
  Makefile: avoid leaving the temporary QEMU_PKGVERSION header file

Paolo Bonzini (7):
  test-vmstate: remove yield_until_fd_readable
  cpu-exec: fix icount out-of-bounds access
  cpu-exec: tighten barrier on TCG_EXIT_REQUESTED
  cpu-exec: avoid cpu_loop_exit in cpu_handle_interrupt
  cpu-exec: avoid repeated sigsetjmp on interrupts
  cpu-exec: remove outermost infinite loop
  target-i386: correctly propagate retaddr into SVM helpers

Pavel Dovgalyuk (1):
  apic: reset apic_delivered global variable on machine reset

Peter Xu (3):
  kvm/ioapic: dump real object instead of a fake one
  ioapic: fix error report value of def version
  kvm/ioapic: correct kvm ioapic version

Richard W.M. Jones (1):
  qemu-nbd: Implement socket activation.

Thomas Huth (1):
  hw/char/mcf_uart: QOMify the ColdFire UART

 Makefile  |   6 +-
 chardev/char-pty.c|   2 +-
 chardev/char-socket.c |  10 +++
 cpu-exec.c|  86 ++-
 cpus.c|  42 ++
 gdbstub.c | 209 +++---
 hw/char/mcf_uart.c| 102 --
 hw/i386/kvm/ioapic.c  |  13 ++-
 hw/intc/apic_common.c |   2 +
 hw/intc/ioapic.c  |   6 +-
 hw/m68k/mcf5208.c |   6 +-
 hw/misc/pvpanic.c |   2 +-
 hw/ppc/spapr_rtas.c   |   3 +-
 include/exec/exec-all.h   |   1 +
 include/hw/m68k/mcf.h |   6 +-
 include/qom/cpu.h |  10 +++
 include/sysemu/sysemu.h   |   4 +-
 kvm-all.c |   3 +-
 qapi-schema.json  |  24 ++
 qapi/event.json   |   6 +-
 qemu-nbd.c| 172 --
 qemu-options.hx   |   4 +-
 qom/cpu.c |  11 +++
 target/i386/cpu.c |  51 +++
 target/i386/cpu.h |   5 +-
 target/i386/excp_helper.c |  11 +--
 target/i386/helper.h  |   1 -
 target/i386/misc_helper.c |  24 +++---
 target/i386/seg_helper.c  |   6 +-
 target/i386/svm_helper.c  |  65 +++---
 target/s390x/kvm.c|   4 +-
 tests/test-vmstate.c  |  11 ---
 vl.c  |  56 +
 33 files changed, 711 insertions(+), 253 deletions(-)
-- 
1.8.3.1

[Qemu-devel] [PATCH] linux-user: fix fork()

[Laurent Vivier]

Since commit 5ea2fc8 ("linux-user: Sanity check clone flags"),
trying to run fork() fails with old distro on some architectures.

This is the case with HP-PA and Debian 5 (Lenny).

It fails on:

 if ((flags & CSIGNAL) != TARGET_SIGCHLD) {
 return -TARGET_EINVAL;
 }

because flags is 17, whereas on HP-PA, SIGCHLD is 18.
17 is the SIGCHLD value of my host (x86_64).

It appears that for TARGET_NR_fork and TARGET_NR_vfork, QEMU calls
do_fork() with SIGCHLD instead of TARGET_SIGCHLD.

Signed-off-by: Laurent Vivier 
---
 linux-user/syscall.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index f569f82..4d85355 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -7680,7 +7680,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 break;
 #ifdef TARGET_NR_fork
 case TARGET_NR_fork:
-ret = get_errno(do_fork(cpu_env, SIGCHLD, 0, 0, 0, 0));
+ret = get_errno(do_fork(cpu_env, TARGET_SIGCHLD, 0, 0, 0, 0));
 break;
 #endif
 #ifdef TARGET_NR_waitpid
@@ -10490,7 +10490,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 #endif
 #ifdef TARGET_NR_vfork
 case TARGET_NR_vfork:
-ret = get_errno(do_fork(cpu_env, CLONE_VFORK | CLONE_VM | SIGCHLD,
+ret = get_errno(do_fork(cpu_env,
+CLONE_VFORK | CLONE_VM | TARGET_SIGCHLD,
 0, 0, 0, 0));
 break;
 #endif
-- 
2.9.3

Re: [Qemu-devel] Missing rewrite rule for qemu.org/images/ links

[Jeff Cody]

On Thu, Feb 16, 2017 at 10:47:07AM -0500, Jeff Cody wrote:
> On Thu, Feb 16, 2017 at 03:30:25PM +, Stefan Hajnoczi wrote:
> > Hi Jeff,
> > The old qemu.org/images/ links are not being rewritten to
> > wiki.qemu-project.org/images/.
> > 
> > For example, http://www.qemu-project.org/images/4/4e/Q35.pdf no longer 
> > works:
> > https://bugs.launchpad.net/qemu/+bug/1665344
> > 
> > I do notice that qemu.org/Features/Q35 is working.  Is it possible to
> > set up a rewrite rule or HTTP redirect so existing /images/ links keep
> > working?
> > 
> > Thanks,
> > Stefan
> 
> Thanks for noticing, and pointing that out.  I'll get right on that.
>

Fixed now.

-Jeff

Re: [Qemu-devel] [PATCH 3/9] armv7m: Rewrite NVIC to not use any GIC code

[Peter Maydell]

On 15 February 2017 at 13:34, Peter Maydell  wrote:
> On 15 February 2017 at 12:46, Alex Bennée  wrote:
>> Can we not calculate a vector index rather than abusing the meaning of
>> offset while switching on it?
>
> Yeah, we could. (This is just a case where I thought "I could
> rewrite the code Michael did initially, but it doesn't quite
> reach my threshold for doing that just because it's not the
> way I'd have written it.".)

FWIW, it took me five attempts at rewriting these loops before
I got a version that actually worked. I think I'm going to
take that as justification for my bias towards not rewriting
code that already works :-)

(The change I ended up with just uses a local 'startvec' instead
of modifying 'offset'.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH v7 1/8] linker-loader: Add new 'write pointer' command

[Laszlo Ersek]

On 02/16/17 07:18, b...@skyportsystems.com wrote:
> From: Ben Warren 
> 
> This is similar to the existing 'add pointer' functionality, but instead
> of instructing the guest (BIOS or UEFI) to patch memory, it instructs
> the guest to write the pointer back to QEMU via a writeable fw_cfg file.
> 
> Signed-off-by: Ben Warren 
> ---
>  hw/acpi/bios-linker-loader.c | 66 
> ++--
>  include/hw/acpi/bios-linker-loader.h |  7 
>  2 files changed, 70 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/acpi/bios-linker-loader.c b/hw/acpi/bios-linker-loader.c
> index d963ebe..d5fb703 100644
> --- a/hw/acpi/bios-linker-loader.c
> +++ b/hw/acpi/bios-linker-loader.c
> @@ -78,6 +78,21 @@ struct BiosLinkerLoaderEntry {
>  uint32_t length;
>  } cksum;
>  
> +/*
> + * COMMAND_WRITE_POINTER - write the fw_cfg file (originating from
> + * @dest_file) at @wr_pointer.offset, by adding a pointer to
> + * @src_offset within the table originating from @src_file.
> + * 1,2,4 or 8 byte unsigned addition is used depending on
> + * @wr_pointer.size.
> + */
> +struct {
> +char dest_file[BIOS_LINKER_LOADER_FILESZ];
> +char src_file[BIOS_LINKER_LOADER_FILESZ];
> +uint32_t dst_offset;
> +uint32_t src_offset;
> +uint8_t size;
> +} wr_pointer;
> +
>  /* padding */
>  char pad[124];
>  };
> @@ -85,9 +100,10 @@ struct BiosLinkerLoaderEntry {
>  typedef struct BiosLinkerLoaderEntry BiosLinkerLoaderEntry;
>  
>  enum {
> -BIOS_LINKER_LOADER_COMMAND_ALLOCATE = 0x1,
> -BIOS_LINKER_LOADER_COMMAND_ADD_POINTER  = 0x2,
> -BIOS_LINKER_LOADER_COMMAND_ADD_CHECKSUM = 0x3,
> +BIOS_LINKER_LOADER_COMMAND_ALLOCATE  = 0x1,
> +BIOS_LINKER_LOADER_COMMAND_ADD_POINTER   = 0x2,
> +BIOS_LINKER_LOADER_COMMAND_ADD_CHECKSUM  = 0x3,
> +BIOS_LINKER_LOADER_COMMAND_WRITE_POINTER = 0x4,
>  };
>  
>  enum {
> @@ -278,3 +294,47 @@ void bios_linker_loader_add_pointer(BIOSLinker *linker,
>  
>  g_array_append_vals(linker->cmd_blob, , sizeof entry);
>  }
> +
> +/*
> + * bios_linker_loader_write_pointer: ask guest to write a pointer to the
> + * source file into the destination file, and write it back to QEMU via
> + * fw_cfg DMA.
> + *
> + * @linker: linker object instance
> + * @dest_file: destination file that must be written
> + * @dst_patched_offset: location within destination file blob to be patched
> + *  with the pointer to @src_file, in bytes
> + * @dst_patched_offset_size: size of the pointer to be patched
> + *  at @dst_patched_offset in @dest_file blob, in bytes
> + * @src_file: source file who's address must be taken
> + * @src_offset: location within source file blob to which
> + *  @dest_file+@dst_patched_offset will point to after
> + *  firmware's executed WRITE_POINTER command
> + */
> +void bios_linker_loader_write_pointer(BIOSLinker *linker,
> +const char *dest_file,
> +uint32_t dst_patched_offset,
> +uint8_t dst_patched_size,
> +const char *src_file,
> +uint32_t src_offset)
> +{
> +BiosLinkerLoaderEntry entry;
> +const BiosLinkerFileEntry *source_file =
> +bios_linker_find_file(linker, src_file);
> +
> +assert(source_file);
> +assert(src_offset <= source_file->blob->len);

(1) Off by one, as pointed out by Igor.

> +memset(, 0, sizeof entry);
> +strncpy(entry.wr_pointer.dest_file, dest_file,
> +sizeof entry.wr_pointer.dest_file - 1);
> +strncpy(entry.wr_pointer.src_file, src_file,
> +sizeof entry.wr_pointer.src_file - 1);
> +entry.command = cpu_to_le32(BIOS_LINKER_LOADER_COMMAND_WRITE_POINTER);
> +entry.wr_pointer.dst_offset = cpu_to_le32(dst_patched_offset);
> +entry.wr_pointer.src_offset = cpu_to_le32(dst_patched_offset);

(2) copy/paste error, you should be assigning "src_offset", as in:

> diff --git a/hw/acpi/bios-linker-loader.c b/hw/acpi/bios-linker-loader.c
> index d5fb7033a0be..d1a9f2f33dcc 100644
> --- a/hw/acpi/bios-linker-loader.c
> +++ b/hw/acpi/bios-linker-loader.c
> @@ -331,7 +331,7 @@ void bios_linker_loader_write_pointer(BIOSLinker *linker,
>  sizeof entry.wr_pointer.src_file - 1);
>  entry.command = cpu_to_le32(BIOS_LINKER_LOADER_COMMAND_WRITE_POINTER);
>  entry.wr_pointer.dst_offset = cpu_to_le32(dst_patched_offset);
> -entry.wr_pointer.src_offset = cpu_to_le32(dst_patched_offset);
> +entry.wr_pointer.src_offset = cpu_to_le32(src_offset);
>  entry.wr_pointer.size = dst_patched_size;
>  assert(dst_patched_size == 1 || dst_patched_size == 2 ||
> dst_patched_size == 4 

Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems.

[Laszlo Ersek]

On 02/16/17 17:58, Paolo Bonzini wrote:
> 
> 
> On 16/02/2017 17:30, Chad Joan wrote:
>> Hello,
>>
>> This is a one-line patch to the configure script that will allow QEMU to be
>> built on musl-libc based Linux systems.  This problem is only noticeable
>> when QEMU is built with --enable-curses.
>>
>> Detailed reading material if you want to know where this came from:
>> https://bugs.gentoo.org/show_bug.cgi?id=609364
> 
> Hi,
> 
> can you explain exactly which function is missing without
> -D_XOPEN_SOURCE=500?  If it is curses' wide-char functions, why does it
> fail with musl but not with glibc?  Is _XOPEN_SOURCE always defined by
> glibc if you have _D_GNU_SOURCE?

It is not necessarily auto-defined, but the effect is "as if".

It is documented in the libc info:

https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fXOPEN_005fSOURCE

> Macro: _XOPEN_SOURCE
> Macro: _XOPEN_SOURCE_EXTENDED
>
> If you define this macro, functionality described in the X/Open
> Portability Guide is included. This is a superset of the POSIX.1
> and POSIX.2 functionality and in fact _POSIX_SOURCE and
> _POSIX_C_SOURCE are automatically defined.
>
> As the unification of all Unices, functionality only available in
> BSD and SVID is also included.
>
> If the macro _XOPEN_SOURCE_EXTENDED is also defined, even more
> functionality is available. The extra functions will make all
> functions available which are necessary for the X/Open Unix brand.
>
> If the macro _XOPEN_SOURCE has the value 500 this includes all
> functionality described so far plus some new definitions from the
> Single Unix Specification, version 2.

https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fGNU_005fSOURCE

> Macro: _GNU_SOURCE
>
> If you define this macro, everything is included: ISO C89, ISO
> C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions.
> In the cases where POSIX.1 conflicts with BSD, the POSIX
> definitions take precedence.

Curiously, I managed to recall this from years ago, when I was still
living and breathing the SUS (and looking frequently at the glibc info too).

Laszlo

Re: [Qemu-devel] [PATCH v7 5/8] qmp/hmp: add query-vm-generation-id and 'info vm-generation-id' commands

[Laszlo Ersek]

On 02/16/17 07:18, b...@skyportsystems.com wrote:
> From: Igor Mammedov 
> 
> Add commands to query Virtual Machine Generation ID counter.
> 
> QMP command example:
> { "execute": "query-vm-generation-id" }
> 
> HMP command example:
> info vm-generation-id
> 
> Signed-off-by: Igor Mammedov 
> Reviewed-by: Eric Blake 
> Signed-off-by: Ben Warren 
> Reviewed-by: Laszlo Ersek 
> ---
>  hmp-commands-info.hx | 14 ++
>  hmp.c|  9 +
>  hmp.h|  1 +
>  hw/acpi/vmgenid.c| 16 
>  qapi-schema.json | 20 
>  stubs/Makefile.objs  |  1 +
>  stubs/vmgenid.c  |  9 +
>  7 files changed, 70 insertions(+)
>  create mode 100644 stubs/vmgenid.c

I tested the "info vm-generation-id" command via HMP.

Tested-by: Laszlo Ersek 

Thanks,
Laszlo

Re: [Qemu-devel] [PATCH 1/2] qmp/hmp: add writeconfig

[Eric Blake]

On 02/15/2017 04:14 AM, Eduardo Otubo wrote:
> This patch adds support for the command `writeconfig' on the QMP and HMP
> consoles. This is a simple way to keep track of current state of VM
> after series of hotplugs and/or hotunplugs of different devices:
> 
>   (qemu) writeconfig qemu.conf
> 
> Signed-off-by: Eduardo Otubo 
> ---

> +++ b/qapi-schema.json
> @@ -4696,6 +4696,26 @@
>'data': { 'keys': ['KeyValue'], '*hold-time': 'int' } }
>  
>  ##
> +# @writeconfig:
> +#
> +# Write config to file.
> +#
> +# @filename: the path of a new file to store the current config
> +#
> +# Returns: Nothing on success
> +#
> +# Since: 2.7.0
> +#

You've missed 2.7 by two releases.  This should be 2.9.


> +++ b/ui/console.c

>  
> +void qmp_writeconfig(const char *filename, Error **errp)
> +{
> +if (filename == NULL) {
> +error_setg(errp, "You must specify a filename.");
> +return;
> +}

Dead code; QAPI ensures that filename is non-NULL.
Even if it weren't dead code, error_setg() messages should not end in '.'.

> +
> +FILE *fp;
> +fp = fopen(filename, "w");

Please use qemu_fopen() - that way, the caller can also use qemu's magic
/dev/fdset to write to a pre-opened fd even when qemu itself can't
open() the file.

-- 
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 2/6] coroutine-lock: add limited spinning to CoMutex

[Stefan Hajnoczi]

On Mon, Feb 13, 2017 at 07:12:40PM +0100, Paolo Bonzini wrote:
> Running a very small critical section on pthread_mutex_t and CoMutex
> shows that pthread_mutex_t is much faster because it doesn't actually
> go to sleep.  What happens is that the critical section is shorter
> than the latency of entering the kernel and thus FUTEX_WAIT always
> fails.  With CoMutex there is no such latency but you still want to
> avoid wait and wakeup.  So introduce it artificially.
> 
> This only works with one waiters; because CoMutex is fair, it will
> always have more waits and wakeups than a pthread_mutex_t.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  include/qemu/coroutine.h   |  5 +
>  util/qemu-coroutine-lock.c | 51 
> --
>  util/qemu-coroutine.c  |  2 +-
>  3 files changed, 51 insertions(+), 7 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [Qemu-devel] [Qemu-arm] [PATCH 0/4] cpu: Implement cpu_generic_new()

[Peter Maydell]

On 13 February 2017 at 14:28, Peter Maydell  wrote:
> This patchset adds a new function cpu_generic_new()
> which is similar to cpu_generic_init() except that it
> does not realize the created CPU object. This means that
> board code can do a "new cpu; set QOM properties; realize"
> sequence without having to do all the work of splitting
> the CPU model string and calling parse_features by hand.
>
> Patch 2 clarifies a TODO comment, hopefully correctly,
> based on an email conversation I had with Eduardo a
> little while back.
>
> Patches 3 and 4 change the ARM boards which currently
> call parse_features by hand to use the new function.
>
>
> If there's consensus that this is the right general
> direction to go in, then I think that some other
> architectures could also make cleanups to use this:
>  * cpu_s390x_create() is almost exactly this function,
>give or take some fine detail of error handling
>  * ppc_cpu_parse_features is almost the same thing,
>except that it doesn't actually create the CPU object,
>it only calls parse_features
>  * hw/i386/pc.c does a manual parse_features
>
> I'm not strongly attached to this particular approach
> (though it seems like a reasonable one, especially given
> the proliferation of different arch-specific helpers
> listed above and the bugs in boards which don't call
> parse_features when they should), but I would like us to
> figure out and document what the right way for a board
> to create and configure its CPU objects is...

I know it's only been a few days, but I just wanted to
say that I'd appreciate it if we could manage relatively
quick review on this one, since I have a set of patches
pending that depend on this and which it would be nice
to get into 2.9 (softfreeze approaching rapidly).

thanks
-- PMM

Re: [Qemu-devel] Missing rewrite rule for qemu.org/images/ links

[Paolo Bonzini]

On 16/02/2017 16:30, Stefan Hajnoczi wrote:
> Hi Jeff,
> The old qemu.org/images/ links are not being rewritten to
> wiki.qemu-project.org/images/.
> 
> For example, http://www.qemu-project.org/images/4/4e/Q35.pdf no longer works:
> https://bugs.launchpad.net/qemu/+bug/1665344
> 
> I do notice that qemu.org/Features/Q35 is working.  Is it possible to
> set up a rewrite rule or HTTP redirect so existing /images/ links keep
> working?

Yes, it's possible.  The existing rules cover URLs that start with
uppercase, linking them to either the handful of pages in the website,
or to wiki.qemu-project.org as a fallback.

Paolo

Re: [Qemu-devel] [PATCH v7 4/8] ACPI: Add Virtual Machine Generation ID support

[Laszlo Ersek]

On 02/16/17 07:18, b...@skyportsystems.com wrote:
> From: Ben Warren 
> 
> This implements the VM Generation ID feature by passing a 128-bit
> GUID to the guest via a fw_cfg blob.
> Any time the GUID changes, an ACPI notify event is sent to the guest
> 
> The user interface is a simple device with one parameter:
>  - guid (string, must be "auto" or in UUID format
>----)
> 
> Signed-off-by: Ben Warren 
> ---
>  default-configs/i386-softmmu.mak |   1 +
>  default-configs/x86_64-softmmu.mak   |   1 +
>  hw/acpi/Makefile.objs|   1 +
>  hw/acpi/vmgenid.c| 239 
> +++
>  hw/i386/acpi-build.c |  16 +++
>  include/hw/acpi/acpi_dev_interface.h |   1 +
>  include/hw/acpi/vmgenid.h|  35 +
>  7 files changed, 294 insertions(+)
>  create mode 100644 hw/acpi/vmgenid.c
>  create mode 100644 include/hw/acpi/vmgenid.h

I compared this version against v6. It looks good. I also tested it
(with the fixup I mentioned under v7 1/8, and without live migration).

Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

Thanks
Laszlo

Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems.

[Peter Maydell]

On 16 February 2017 at 16:30, Chad Joan  wrote:
> Hello,
>
> This is a one-line patch to the configure script that will allow QEMU to be
> built on musl-libc based Linux systems.  This problem is only noticeable
> when QEMU is built with --enable-curses.
>
> Detailed reading material if you want to know where this came from:
> https://bugs.gentoo.org/show_bug.cgi?id=609364

Thanks for the bug report and the patch. I'm a bit confused
about why it's necessary, though. We already define _GNU_SOURCE,
which the musl docs say implies _XOPEN_SOURCE:
 https://www.musl-libc.org/doc/1.0.0/manual.html
Is that not true for your musl, or is our configure script
failing to pass -D_GNU_SOURCE when building the curses test program?

If we do need an explicit define of _XOPEN_SOURCE I think we should
do it at the same place where we add -D_GNU_SOURCE to the cflags.

thanks
-- PMM

[Qemu-devel] [PATCH v2 08/13] armv7m: Simpler and faster exception start

[Peter Maydell]

From: Michael Davidsaver 

All the places in armv7m_cpu_do_interrupt() which pend an
exception in the NVIC are doing so for synchronous
exceptions. We know that we will always take some
exception in this case, so we can just acknowledge it
immediately, rather than returning and then immediately
being called again because the NVIC has raised its outbound
IRQ line.

Signed-off-by: Michael Davidsaver 
[PMM: tweaked commit message; added DEBUG to the set of
exceptions we handle immediately, since it is synchronous
when it results from the BKPT instruction]
Signed-off-by: Peter Maydell 
Reviewed-by: Alex Bennée 
---
 target/arm/helper.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 050d8df..1844852 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6109,22 +6109,22 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
 case EXCP_UDEF:
 armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_USAGE);
 env->v7m.cfsr |= R_V7M_CFSR_UNDEFINSTR_MASK;
-return;
+break;
 case EXCP_NOCP:
 armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_USAGE);
 env->v7m.cfsr |= R_V7M_CFSR_NOCP_MASK;
-return;
+break;
 case EXCP_SWI:
 /* The PC already points to the next instruction.  */
 armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_SVC);
-return;
+break;
 case EXCP_PREFETCH_ABORT:
 case EXCP_DATA_ABORT:
 /* TODO: if we implemented the MPU registers, this is where we
  * should set the MMFAR, etc from exception.fsr and exception.vaddress.
  */
 armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_MEM);
-return;
+break;
 case EXCP_BKPT:
 if (semihosting_enabled()) {
 int nr;
@@ -6139,9 +6139,8 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
 }
 }
 armv7m_nvic_set_pending(env->nvic, ARMV7M_EXCP_DEBUG);
-return;
+break;
 case EXCP_IRQ:
-armv7m_nvic_acknowledge_irq(env->nvic);
 break;
 case EXCP_EXCEPTION_EXIT:
 do_v7m_exception_exit(env);
@@ -6151,6 +6150,10 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
 return; /* Never happens.  Keep compiler happy.  */
 }
 
+armv7m_nvic_acknowledge_irq(env->nvic);
+
+qemu_log_mask(CPU_LOG_INT, "... as %d\n", env->v7m.exception);
+
 /* Align stack pointer if the guest wants that */
 if ((env->regs[13] & 4) && (env->v7m.ccr & R_V7M_CCR_STKALIGN_MASK)) {
 env->regs[13] -= 4;
-- 
2.7.4