Re: [Qemu-devel] [PATCH] trace: fix group name generation

[Fam Zheng]

On Thu, 10/20 15:25, Stefan Hajnoczi wrote:
> > 
> > I have two other patches ready to fix the current situation:
> > - one using os.getcwd() to guess the build directory
> > - one implementing --group as mentioned in my other mail
> > 
> > But the one that filters unwanted characters is a less intrusive
> > workaround.
> 
> If Dan's patches will eliminate the issue then we can take a workaround.
> 
> Any more comments about Greg's patch before I merge it?

Should we include this in -rc1? I still see a build error today.

Fam

Re: [Qemu-devel] QMP event on reboot when -no-reboot is set

[Dirk Braunschweiger]

On 2016-11-16 17:29, John Snow wrote:

On 11/16/2016 09:01 AM, Dirk Braunschweiger wrote:

Hey Guys,

I want to get a qmp event when the qemu does a shutdown due to the
-no-reboot flag. Looking at the code I realized that the -no-reboot 
flag

just changes any reset request to a shutdown request.
Does anybody already patched qemu to emit some kind of reboot event to
the qmp socket?

If no one already patched it, would you accept such a patch? Or is a
non-wanted feature?

Best regards,
Dirk Braunschweiger



Is the existing "STOP" event insufficient for some reason? Is it
important to distinguish between a 'real' stop and a stop that was
originally intended to be a reboot?

If you can elaborate on that case, you have a good chance of amending
the event spec to add some new events.

--js



Hi John,

the stop event is not sufficient. I want to restart the VM if the guest 
initiates a reboot. The user of the VM expects that the VM is startet 
again after he/she clicks on reboot ;)
I want to use the --no-reboot flag to stop qemu and restart it on 
another vm host or to start it with another configuration (more/less 
RAM/CPU, a bigger HDD, etc...)


Best regards,
Dirk

Re: [Qemu-devel] dpdk/vpp and cross-version migration for vhost

[Yuanhan Liu]

As usaual, sorry for late response :/

On Thu, Oct 13, 2016 at 08:50:52PM +0300, Michael S. Tsirkin wrote:
> Hi!
> So it looks like we face a problem with cross-version
> migration when using vhost. It's not new but became more
> acute with the advent of vhost user.
> 
> For users to be able to migrate between different versions
> of the hypervisor the interface exposed to guests
> by hypervisor must stay unchanged.
> 
> The problem is that a qemu device is connected
> to a backend in another process, so the interface
> exposed to guests depends on the capabilities of that
> process.
> 
> Specifically, for vhost user interface based on virtio, this includes
> the "host features" bitmap that defines the interface, as well as more
> host values such as the max ring size.  Adding new features/changing
> values to this interface is required to make progress, but on the other
> hand we need ability to get the old host features to be compatible.

It looks like to the same issue of vhost-user reconnect to me. For example,

- start dpdk 16.07 & qemu 2.5
- kill dpdk
- start dpdk 16.11

Though DPDK 16.11 has more features comparing to dpdk 16.07 (say, indirect),
above should work. Because qemu saves the negotiated features before the
disconnect and stores it back after the reconnection.

commit a463215b087c41d7ca94e51aa347cde523831873
Author: Marc-André Lureau 
Date:   Mon Jun 6 18:45:05 2016 +0200

vhost-net: save & restore vhost-user acked features

The initial vhost-user connection sets the features to be negotiated
with the driver. Renegotiation isn't possible without device reset.

To handle reconnection of vhost-user backend, ensure the same set of
features are provided, and reuse already acked features.

Signed-off-by: Marc-André Lureau 


So we could do similar to vhost-user? I mean, save the acked features
before migration and store it back after it. This should be able to
keep the compatibility. If user downgrades DPDK version, it also could
be easily detected, and then exit with an error to user: migration
failed due to un-compatible vhost features.

Just some rough thoughts. Makes tiny sense?

--yliu
> 
> To solve this problem within qemu, qemu has a versioning system based on
> a machine type concept which fundamentally is a version string, by
> specifying that string one can get hardware compatible with a previous
> qemu version. QEMU also reports the latest version and list of versions
> supported so libvirt records the version at VM creation and then is
> careful to use this machine version whenever it migrates a VM.
> 
> One might wonder how is this solved with a kernel vhost backend. The
> answer is that it mostly isn't - instead an assumption is made, that
> qemu versions are deployed together with the kernel - this is generally
> true for downstreams.  Thus whenever qemu gains a new feature, it is
> already supported by the kernel as well.  However, if one attempts
> migration with a new qemu from a system with a new to old kernel, one
> would get a failure.
> 
> In the world where we have multiple userspace backends, with some of
> these supplied by ISVs, this seems non-realistic.
> 
> IMO we need to support vhost backend versioning, ideally
> in a way that will also work for vhost kernel backends.
> 
> So I'd like to get some input from both backend and management
> developers on what a good solution would look like.
> 
> If we want to emulate the qemu solution, this involves adding the
> concept of interface versions to dpdk.  For example, dpdk could supply a
> file (or utility printing?) with list of versions: latest and versions
> supported. libvirt could read that and
> - store latest version at vm creation
> - pass it around with the vm
> - pass it to qemu
> 
> >From here, qemu could pass this over the vhost-user channel,
> thus making sure it's initialized with the correct
> compatible interface.
> 
> As version here is an opaque string for libvirt and qemu,
> anything can be used - but I suggest either a list
> of values defining the interface, e.g.
> any_layout=on,max_ring=256
> or a version including the name and vendor of the backend,
> e.g. "org.dpdk.v4.5.6".
> 
> Note that typically the list of supported versions can only be
> extended, not shrunk. Also, if the host/guest interface
> does not change, don't change the current version as
> this just creates work for everyone.
> 
> Thoughts? Would this work well for management? dpdk? vpp?
> 
> Thanks!
> 
> -- 
> MST

Re: [Qemu-devel] [PATCH 3/4] hw/timer: Add Epson RX8900 RTC support

[Cédric Le Goater]

On 11/17/2016 05:36 AM, Alastair D'Silva wrote:
> From: Alastair D'Silva 
> 
> This patch adds support for the Epson RX8900 RTC chip.

It would be nice to have a short list of the features this 
chip has and also the main point of the design. I see you 
are using a BH.


> Signed-off-by: Alastair D'Silva 
> ---
>  default-configs/arm-softmmu.mak |   1 +
>  hw/timer/Makefile.objs  |   2 +
>  hw/timer/rx8900.c   | 891 
> 
>  hw/timer/rx8900_regs.h  | 125 ++
>  tests/Makefile.include  |   2 +
>  tests/rx8900-test.c | 800 

Nice test ! But Why aren't you using the aspeed machine in 
qtest ? 

The reason I am asking is because the I2C controller model 
is a little too simplistic in the way it handles the irq 
status and we would need a test for it.


Also I would put the test case in another patch, after the 
model and after patch 2 also which introduces named 
interrupts for qtest.


>  6 files changed, 1821 insertions(+)
>  create mode 100644 hw/timer/rx8900.c
>  create mode 100644 hw/timer/rx8900_regs.h
>  create mode 100644 tests/rx8900-test.c
> 
> diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
> index 6de3e16..adb600e 100644
> --- a/default-configs/arm-softmmu.mak
> +++ b/default-configs/arm-softmmu.mak
> @@ -29,6 +29,7 @@ CONFIG_SMC91C111=y
>  CONFIG_ALLWINNER_EMAC=y
>  CONFIG_IMX_FEC=y
>  CONFIG_DS1338=y
> +CONFIG_RX8900=y
>  CONFIG_PFLASH_CFI01=y
>  CONFIG_PFLASH_CFI02=y
>  CONFIG_MICRODRIVE=y
> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
> index 7ba8c23..fa028ac 100644
> --- a/hw/timer/Makefile.objs
> +++ b/hw/timer/Makefile.objs
> @@ -3,6 +3,7 @@ common-obj-$(CONFIG_ARM_MPTIMER) += arm_mptimer.o
>  common-obj-$(CONFIG_A9_GTIMER) += a9gtimer.o
>  common-obj-$(CONFIG_CADENCE) += cadence_ttc.o
>  common-obj-$(CONFIG_DS1338) += ds1338.o
> +common-obj-$(CONFIG_RX8900) += rx8900.o
>  common-obj-$(CONFIG_HPET) += hpet.o
>  common-obj-$(CONFIG_I8254) += i8254_common.o i8254.o
>  common-obj-$(CONFIG_M48T59) += m48t59.o
> @@ -17,6 +18,7 @@ common-obj-$(CONFIG_IMX) += imx_epit.o
>  common-obj-$(CONFIG_IMX) += imx_gpt.o
>  common-obj-$(CONFIG_LM32) += lm32_timer.o
>  common-obj-$(CONFIG_MILKYMIST) += milkymist-sysctl.o
> +common-obj-$(CONFIG_RX8900) += rx8900.o
>  
>  obj-$(CONFIG_EXYNOS4) += exynos4210_mct.o
>  obj-$(CONFIG_EXYNOS4) += exynos4210_pwm.o
> diff --git a/hw/timer/rx8900.c b/hw/timer/rx8900.c
> new file mode 100644
> index 000..208a31b
> --- /dev/null
> +++ b/hw/timer/rx8900.c
> @@ -0,0 +1,891 @@
> +/*
> + * Epson RX8900SA/CE Realtime Clock Module
> + *
> + * Copyright (c) 2016 IBM Corporation
> + * Authors:
> + *  Alastair D'Silva 
> + *
> + * This code is licensed under the GPL version 2 or later.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Datasheet available at:
> + *  https://support.epson.biz/td/api/doc_check.php?dl=app_RX8900CE&lang=en
> + *
> + * Not implemented:
> + *  Implement Timer Counters
> + *  Implement i2c timeout
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +#include "hw/i2c/i2c.h"
> +#include "hw/timer/rx8900_regs.h"
> +#include "hw/ptimer.h"
> +#include "qemu/main-loop.h"
> +#include "qemu/bcd.h"
> +#include "qemu/error-report.h"
> +#include "qemu/log.h"
> +#include "qapi/error.h"
> +#include "qapi/visitor.h"
> +
> + #include 
> +
> + #include 
> +
> +#define TYPE_RX8900 "rx8900"
> +#define RX8900(obj) OBJECT_CHECK(RX8900State, (obj), TYPE_RX8900)
> +
> +static bool log;
> +
> +typedef struct RX8900State {
> +I2CSlave parent_obj;
> +
> +ptimer_state *sec_timer; /* triggered once per second */
> +ptimer_state *fout_timer;
> +ptimer_state *countdown_timer;
> +bool fout;
> +int64_t offset;
> +uint8_t weekday; /* Saved for deferred offset calculation, 0-6 */
> +uint8_t wday_offset;
> +uint8_t nvram[RX8900_NVRAM_SIZE];
> +int32_t ptr; /* Wrapped to stay within RX8900_NVRAM_SIZE */
> +bool addr_byte;
> +uint8_t last_interrupt_seconds;
> +uint8_t last_update_interrupt_minutes;
> +qemu_irq interrupt_pin;
> +qemu_irq fout_pin;
> +} RX8900State;
> +
> +static const VMStateDescription vmstate_rx8900 = {
> +.name = "rx8900",
> +.version_id = 2,
> +.minimum_version_id = 1,
> +.fields = (VMStateField[]) {
> +VMSTATE_I2C_SLAVE(parent_obj, RX8900State),
> +VMSTATE_PTIMER(sec_timer, RX8900State),
> +VMSTATE_PTIMER(fout_timer, RX8900State),
> +VMSTATE_PTIMER(countdown_timer, RX8900State),
> +VMSTATE_BOOL(fout, RX8900State),
> +VMSTATE_INT64(offset, RX8900State),
> +VMSTATE_UINT8_V(weekday, RX8900State, 2),
> +VMSTATE_UINT8_V(wday_offset, RX8900State, 2),
> +VMSTATE_UINT8_ARRAY(nvram, RX8900State, RX8900_NVRAM_SIZE),
> +VMSTATE_INT32(ptr, RX8900State),
> +VMSTATE_BOOL(addr_byte, RX8900State),
> +VMSTATE_UIN

Re: [Qemu-devel] [PATCH 1/3] virtio: add missing vdev->broken check

[Cornelia Huck]

On Wed, 16 Nov 2016 21:53:07 +
Stefan Hajnoczi  wrote:

> virtio_queue_notify_vq() checks vdev->broken before invoking the
> handler, virtio_queue_notify_aio_vq() should too.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  hw/virtio/virtio.c | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Cornelia Huck 

I think this makes sense as a fix independent of your other patches.

Re: [Qemu-devel] [PATCH 1/3] virtio: introduce grab/release_ioeventfd to fix vhost

[Cornelia Huck]

On Wed, 16 Nov 2016 19:05:49 +0100
Paolo Bonzini  wrote:

> Following the recent refactoring of virtio notifiers [1], more specifically
> the patch ed08a2a0b ("virtio: use virtio_bus_set_host_notifier to
> start/stop ioeventfd") that uses virtio_bus_set_host_notifier [2]
> by default, core virtio code requires 'ioeventfd_started' to be set
> to true/false when the host notifiers are configured.
> 
> When vhost is stopped and started, however, there is a stop followed by
> another start. Since ioeventfd_started was never set to true, the 'stop'
> operation triggered by virtio_bus_set_host_notifier() will not result
> in a call to virtio_pci_ioeventfd_assign(assign=false). This leaves
> the memory regions with stale notifiers and results on the next start
> triggering the following assertion:
> 
>   kvm_mem_ioeventfd_add: error adding ioeventfd: File exists
>   Aborted
> 
> This patch reintroduces (hopefully in a cleaner way) the concept
> that was present with ioeventfd_disabled before the refactoring.
> When ioeventfd_grabbed>0, ioeventfd_started tracks whether ioeventfd
> should be enabled or not, but ioeventfd is actually not started at
> all until vhost releases the host notifiers.
> 
> [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07748.html
> [2] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07760.html
> 
> Reported-by: Felipe Franciosi 
> Reported-by: Christian Borntraeger 
> Reported-by: Alex Williamson 
> Fixes: ed08a2a0b ("virtio: use virtio_bus_set_host_notifier to start/stop 
> ioeventfd")
> Signed-off-by: Paolo Bonzini 
> Message-Id: <2016192855.26350-1-pbonz...@redhat.com>
> Signed-off-by: Paolo Bonzini 
> ---
> v1->v2: more comments [Cornelia]
> 
>  hw/virtio/vhost.c  | 14 +-
>  hw/virtio/virtio-bus.c | 58 
> ++
>  hw/virtio/virtio.c | 16 
>  include/hw/virtio/virtio-bus.h | 14 ++
>  include/hw/virtio/virtio.h |  2 ++
>  5 files changed, 86 insertions(+), 18 deletions(-)

Reviewed-by: Cornelia Huck 

Re: [Qemu-devel] dpdk/vpp and cross-version migration for vhost

[Maxime Coquelin]

On 11/17/2016 09:29 AM, Yuanhan Liu wrote:

As usaual, sorry for late response :/

On Thu, Oct 13, 2016 at 08:50:52PM +0300, Michael S. Tsirkin wrote:

Hi!
So it looks like we face a problem with cross-version
migration when using vhost. It's not new but became more
acute with the advent of vhost user.

For users to be able to migrate between different versions
of the hypervisor the interface exposed to guests
by hypervisor must stay unchanged.

The problem is that a qemu device is connected
to a backend in another process, so the interface
exposed to guests depends on the capabilities of that
process.

Specifically, for vhost user interface based on virtio, this includes
the "host features" bitmap that defines the interface, as well as more
host values such as the max ring size.  Adding new features/changing
values to this interface is required to make progress, but on the other
hand we need ability to get the old host features to be compatible.


It looks like to the same issue of vhost-user reconnect to me. For example,

- start dpdk 16.07 & qemu 2.5
- kill dpdk
- start dpdk 16.11

Though DPDK 16.11 has more features comparing to dpdk 16.07 (say, indirect),
above should work. Because qemu saves the negotiated features before the
disconnect and stores it back after the reconnection.

commit a463215b087c41d7ca94e51aa347cde523831873
Author: Marc-André Lureau 
Date:   Mon Jun 6 18:45:05 2016 +0200

vhost-net: save & restore vhost-user acked features

The initial vhost-user connection sets the features to be negotiated
with the driver. Renegotiation isn't possible without device reset.

To handle reconnection of vhost-user backend, ensure the same set of
features are provided, and reuse already acked features.

Signed-off-by: Marc-André Lureau 


So we could do similar to vhost-user? I mean, save the acked features
before migration and store it back after it. This should be able to
keep the compatibility. If user downgrades DPDK version, it also could
be easily detected, and then exit with an error to user: migration
failed due to un-compatible vhost features.

Just some rough thoughts. Makes tiny sense?


My understanding is that the management tool has to know whether
versions are compatible before initiating the migration:
 1. The downtime could be unpredictable if a VM has to move from hosts
to hosts multiple times, which is problematic, especially for NFV.
 2. If migration is not possible, maybe the management tool would
prefer not to interrupt the VM on current host.

I have little experience with migration though, so I could be mistaken.

Thanks,
Maxime



--yliu


To solve this problem within qemu, qemu has a versioning system based on
a machine type concept which fundamentally is a version string, by
specifying that string one can get hardware compatible with a previous
qemu version. QEMU also reports the latest version and list of versions
supported so libvirt records the version at VM creation and then is
careful to use this machine version whenever it migrates a VM.

One might wonder how is this solved with a kernel vhost backend. The
answer is that it mostly isn't - instead an assumption is made, that
qemu versions are deployed together with the kernel - this is generally
true for downstreams.  Thus whenever qemu gains a new feature, it is
already supported by the kernel as well.  However, if one attempts
migration with a new qemu from a system with a new to old kernel, one
would get a failure.

In the world where we have multiple userspace backends, with some of
these supplied by ISVs, this seems non-realistic.

IMO we need to support vhost backend versioning, ideally
in a way that will also work for vhost kernel backends.

So I'd like to get some input from both backend and management
developers on what a good solution would look like.

If we want to emulate the qemu solution, this involves adding the
concept of interface versions to dpdk.  For example, dpdk could supply a
file (or utility printing?) with list of versions: latest and versions
supported. libvirt could read that and
- store latest version at vm creation
- pass it around with the vm
- pass it to qemu

>From here, qemu could pass this over the vhost-user channel,
thus making sure it's initialized with the correct
compatible interface.

As version here is an opaque string for libvirt and qemu,
anything can be used - but I suggest either a list
of values defining the interface, e.g.
any_layout=on,max_ring=256
or a version including the name and vendor of the backend,
e.g. "org.dpdk.v4.5.6".

Note that typically the list of supported versions can only be
extended, not shrunk. Also, if the host/guest interface
does not change, don't change the current version as
this just creates work for everyone.

Thoughts? Would this work well for management? dpdk? vpp?

Thanks!

--
MST

Re: [Qemu-devel] [PATCH 3/3] virtio: set ISR on dataplane notifications

[Paolo Bonzini]

> > > > > /*
> > > > >  * virtio spec 1.0 says ISR bit 0 should be ignored with MSI, but
> > > > >  * windows drivers included in virtio-win 1.8.0 (circa 2015)
> > > > >  * for Windows 8.1 only are incorrectly polling this bit during
> > > > >  shutdown
> > > >  
> > > > 
> > > > Not sure it's only for Windows 8.1, in fact probably not.
> > > 
> > > 8.1 on shutdown and others on crashdump or hibernation?
> > 
> > Even 8.1 is really a hibernation hidden behind a "Shut down" menu item.
> > 
> > Paolo
> 
> what does "hang during shutdown" in your commit log refer to then?

The full text from the commit log is:

recent releases of
Windows do not really shut down, but rather log out and hibernate to
make the next startup faster.  Hence, this manifested as a more serious
hang during shutdown with e.g. Windows 8.1 and virtio-win 1.8.0 RPMs.

Shutdown in the commit log just means "clicking Shut down".  The previous
sentence explains why.  Also note the "e.g.", I've not tested other versions
of Windows.

Paolo

> > > > Looks good if you replace this line with
> > > > 
> > > > "are incorrectly polling this bit during crashdump or hibernation"
> > > > 
> > > > Paolo
> > > > 
> > > > >  * in MSI mode, causing a hang if this bit is never updated.
> > > > >  * Next driver release from 2016 fixed this problem, so working
> > > > >  around it
> > > > >  * is not a must, but it's easy to do so let's do it here.
> > > > >  *
> > > > >  * Note: it's safe to update ISR from any thread as it was switched
> > > > >  * to an atomic operation.
> > > > >  */
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > +event_notifier_set(&vq->guest_notifier);
> > > > > > +}
> > > > > > +
> > > > > >  void virtio_notify(VirtIODevice *vdev, VirtQueue *vq)
> > > > > >  {
> > > > > >  if (!virtio_should_notify(vdev, vq)) {
> > > > > > @@ -1990,7 +1994,7 @@ static void
> > > > > > virtio_queue_guest_notifier_read(EventNotifier *n)
> > > > > >  {
> > > > > >  VirtQueue *vq = container_of(n, VirtQueue, guest_notifier);
> > > > > >  if (event_notifier_test_and_clear(n)) {
> > > > > > -virtio_irq(vq);
> > > > > > +virtio_notify_vector(vq->vdev, vq->vector);
> > > > > >  }
> > > > > >  }
> > > > > >  
> > > > > > diff --git a/include/hw/virtio/virtio-scsi.h
> > > > > > b/include/hw/virtio/virtio-scsi.h
> > > > > > index 9fbc7d7..7375196 100644
> > > > > > --- a/include/hw/virtio/virtio-scsi.h
> > > > > > +++ b/include/hw/virtio/virtio-scsi.h
> > > > > > @@ -137,6 +137,5 @@ void virtio_scsi_push_event(VirtIOSCSI *s,
> > > > > > SCSIDevice
> > > > > > *dev,
> > > > > >  void virtio_scsi_dataplane_setup(VirtIOSCSI *s, Error **errp);
> > > > > >  int virtio_scsi_dataplane_start(VirtIODevice *s);
> > > > > >  void virtio_scsi_dataplane_stop(VirtIODevice *s);
> > > > > > -void virtio_scsi_dataplane_notify(VirtIODevice *vdev,
> > > > > > VirtIOSCSIReq
> > > > > > *req);
> > > > > >  
> > > > > >  #endif /* QEMU_VIRTIO_SCSI_H */
> > > > > > diff --git a/include/hw/virtio/virtio.h
> > > > > > b/include/hw/virtio/virtio.h
> > > > > > index 835b085..ab0e030 100644
> > > > > > --- a/include/hw/virtio/virtio.h
> > > > > > +++ b/include/hw/virtio/virtio.h
> > > > > > @@ -181,6 +181,7 @@ void virtqueue_get_avail_bytes(VirtQueue *vq,
> > > > > > unsigned
> > > > > > int *in_bytes,
> > > > > > unsigned max_in_bytes, unsigned
> > > > > > max_out_bytes);
> > > > > >  
> > > > > >  bool virtio_should_notify(VirtIODevice *vdev, VirtQueue *vq);
> > > > > > +void virtio_notify_irqfd(VirtIODevice *vdev, VirtQueue *vq);
> > > > > >  void virtio_notify(VirtIODevice *vdev, VirtQueue *vq);
> > > > > >  
> > > > > >  void virtio_save(VirtIODevice *vdev, QEMUFile *f);
> > > > > > @@ -280,7 +281,6 @@ void
> > > > > > virtio_queue_host_notifier_read(EventNotifier
> > > > > > *n);
> > > > > >  void virtio_queue_aio_set_host_notifier_handler(VirtQueue *vq,
> > > > > >  AioContext
> > > > > >  *ctx,
> > > > > >  void
> > > > > >  (*fn)(VirtIODevice
> > > > > >  *,
> > > > > > 
> > > > > > VirtQueue
> > > > > > *));
> > > > > > -void virtio_irq(VirtQueue *vq);
> > > > > >  VirtQueue *virtio_vector_first_queue(VirtIODevice *vdev, uint16_t
> > > > > >  vector);
> > > > > >  VirtQueue *virtio_vector_next_queue(VirtQueue *vq);
> > > > > >  
> > > > > > --
> > > > > > 2.9.3
> > > > > 
> > > 
> 

Re: [Qemu-devel] [PATCH] trace: fix group name generation

[Greg Kurz]

On Thu, 17 Nov 2016 16:07:38 +0800
Fam Zheng  wrote:

> On Thu, 10/20 15:25, Stefan Hajnoczi wrote:
> > > 
> > > I have two other patches ready to fix the current situation:
> > > - one using os.getcwd() to guess the build directory
> > > - one implementing --group as mentioned in my other mail
> > > 
> > > But the one that filters unwanted characters is a less intrusive
> > > workaround.  
> > 
> > If Dan's patches will eliminate the issue then we can take a workaround.
> > 
> > Any more comments about Greg's patch before I merge it?  
> 
> Should we include this in -rc1? I still see a build error today.
> 
> Fam
> 

Hi Fam,

My patch was partly superseded by this commit:

commit 630b210b9abbf362905a2096c22c5eb1d6224e77
Author: Stefan Weil 
Date:   Thu Oct 13 20:29:30 2016 +0200

Fix build for less common build directories names

which does:

-return re.sub(r"/|-", "_", dirname)
+return re.sub(r"[^A-Za-z0-9]", "_", dirname)

What is the build error you're hitting ?

--
Greg

Re: [Qemu-devel] (no subject)

[Thomas Huth]

 Hi Christopher,

On 16.11.2016 20:41, Christopher Oliver wrote:
> This patch (hack?) works around the slowness in SEEK_HOLE for large dense 
> files
> on Linux tmpfs.  It may improve life elsewhere as well, and the penalty of 
> the checks
> should be vanishingly small where it is not needed.
> 
> If I'm subtly (or not so subtly) wrong, please fire back.

When submitting QEMU patches, there are some rules to be followed:
First, please have a look at
 http://qemu-project.org/Contribute/SubmitAPatch#Do_not_send_as_an_attachment
and the other paragraphs there.
Your mail should also have a proper subject, and the Signed-off-by line
should contain your e-mail address.

 Thanks,
  Thomas

Re: [Qemu-devel] [PATCH v2] hw/isa/lpc_ich9: inject SMI on all VCPUs if APM_STS == 'Q'

[Laszlo Ersek]

On 11/16/16 21:38, Michael S. Tsirkin wrote:
> On Wed, Nov 16, 2016 at 01:04:00PM -0500, Paolo Bonzini wrote:
>>> I guess that's what the next paragraph is about:
>>>
 - we could have another magic 0xB2 value, which is implemented directly
 in QEMU and sets 0xB3 to a magic value.  Then OVMF can invoke it
 after SMBASE relocation and SMM IPL (so as not to crash on old QEMUs)
 to detect the new feature.  It can fail to start if using traditional
 AP and the new feature is not there.
>>>
>>> Please explain in more detail. If I write to 0xB2 (by invoking the
>>> Trigger() method or somehow else), then on old QEMU's that will raise a
>>> sync / unicast SMI. The SMI handler in edk2 will run, but no request
>>> parameters will have been set up by OVMF, so the SMI handler will do...
>>> no clue what.
>>
>> It should hopefully do nothing.  A spurious SMI (such as the one caused
>> by the write to 0xB2) should not crash OVMF.
>>
>> SMBASE relocation uses IPIs, so my hope was to use the
>> SmmCpuFeaturesSmmRelocationComplete hook.
>>
>>> My preference is fw_cfg ATM. It provides a prove, flexible and
>>> extensible interface (it's easy to add new files for future features).
>>> If we expect more knobs in the area, I can modify my proposal to use
>>> "etc/smi/broadcast", so we can add "etc/smi/" later.
>>
>> Did you know there are 16 entries only for fw_cfg files? :)  And we're
>> using already 20 in the worst case:
>>
>> genroms/linuxboot.bin
>> genroms/kvmvapic.bin
>> NVDIMM_DSM_MEM_FILE
>> "etc/smbios/smbios-tables"
>> "etc/smbios/smbios-anchor"
>> "etc/acpi/tables"
>> "etc/table-loader"
>> ACPI_BUILD_TPMLOG_FILE
>> ACPI_BUILD_RSDP_FILE
>> "etc/e820"
>> "etc/msr_feature_control"
>> "etc/reserved-memory-end"
>> "etc/pvpanic-port"
>> "etc/boot-menu-wait"
>> "bootsplash.jpg"
>> "etc/boot-fail-wait"
>> "etc/igd-opregion"
>> "etc/igd-bdsm-size"
>> "etc/extra-pci-roots"
>> "bootorder"
>>
>> Therefore, so close to the release I'm a bit worried about doing
>> changes to fw_cfg or adding more fw_cfg files.
> 
> Indeed. Is an unconditional thing so bad?
> What would be the observed behaviour with new OVMF on old QEMU?

The SMM stack would expect broadcast SMIs but only unicast SMIs would
occur. This would
- introduce very long delays in the handling on each SMI as the
synchronization algorithms time out and then force individual APs into
SMM by LAPIC writes,
- expose obscure synchronization bugs in the SMM stack, especially
during S3 resume.

The directed / unicast SMI model is less tested in edk2 and a number of
super-obscure corner cases remain.

Thanks
Laszlo

> Note you need to migrate during boot to notice this.
> 
>> Though we just got
>> rid of one file for the number of CPUs, so I guess we might not care.
>>
>>> Do you have any specific arguments against fw_cfg? As I suggested in my
>>> previous email, with fw_cfg I can implement the change in OVMF such that
>>> the default behavior wouldn't change -- the default delivery would
>>> remain relaxed, and the broadcast wouldn't be requested, unless the
>>> fw_cfg file told OVMF otherwise.
>>>
 By the way, in case OVMF needs to use SmmSwDispatch in the future, I
 would make QEMU use broadcast behavior for all values in the 0x10-0xff
 range, or something like that.
>>>
>>> Are we talking control/command (0xB2) or scratch/data (0xB3) register
>>> values? My patches currently use the scratch/data register to provide
>>> the hint to QEMU; that register is less likely to interfere with
>>> anything the SMM core in edk2 does.
>>
>> Sorry I confused the two registers.  0xb3 is more or less unused as far
>> as I can see indeed.
>>
>> Paolo

Re: [Qemu-devel] [RFC PATCH 1/8] coroutine: Introduce qemu_coroutine_enter_if_inactive()

[Alberto Garcia]

On Thu 10 Nov 2016 06:19:02 PM CET, Kevin Wolf wrote:
> diff --git a/util/qemu-coroutine.c b/util/qemu-coroutine.c
> index 737bffa..a06befe 100644
> --- a/util/qemu-coroutine.c
> +++ b/util/qemu-coroutine.c
> @@ -19,6 +19,7 @@
>  #include "qemu/atomic.h"
>  #include "qemu/coroutine.h"
>  #include "qemu/coroutine_int.h"
> +#include "block/aio.h"

I also don't see why this include is necessary.

Otherwise,

Reviewed-by: Alberto Garcia 

Berto

Re: [Qemu-devel] [PATCH] trace: fix group name generation

[Fam Zheng]

On Thu, 11/17 10:10, Greg Kurz wrote:
> On Thu, 17 Nov 2016 16:07:38 +0800
> Fam Zheng  wrote:
> 
> > On Thu, 10/20 15:25, Stefan Hajnoczi wrote:
> > > > 
> > > > I have two other patches ready to fix the current situation:
> > > > - one using os.getcwd() to guess the build directory
> > > > - one implementing --group as mentioned in my other mail
> > > > 
> > > > But the one that filters unwanted characters is a less intrusive
> > > > workaround.  
> > > 
> > > If Dan's patches will eliminate the issue then we can take a workaround.
> > > 
> > > Any more comments about Greg's patch before I merge it?  
> > 
> > Should we include this in -rc1? I still see a build error today.
> > 
> > Fam
> > 
> 
> Hi Fam,
> 
> My patch was partly superseded by this commit:
> 
> commit 630b210b9abbf362905a2096c22c5eb1d6224e77
> Author: Stefan Weil 
> Date:   Thu Oct 13 20:29:30 2016 +0200
> 
> Fix build for less common build directories names
> 
> which does:
> 
> -return re.sub(r"/|-", "_", dirname)
> +return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> 
> What is the build error you're hitting ?

The substracted parts (basedir and dirname) are different paths for out-of-tree
build, and the "dirname" after the nonsense substraction as fed into re.sub()
could still start with a number. In my case the source is at

/var/tmp/aaa-qemu-clone

and the build dir is

/var/tmp/qemu-aio-poll-v2

Then I get an error as:

trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events" on 
integer constant
 TraceEvent *2_trace_events[] = {
 ^
trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ before 
numeric constant
trace/generated-tracers.c: In function ‘trace_2_register_events’:
trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" on 
integer constant
 trace_event_register_group(2_trace_events);
^
make: *** [trace/generated-tracers.o] Error 1

Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry

[Thomas Huth]

On 17.11.2016 05:24, Sam Bobroff wrote:
> The spapr-vlan device in QEMU has always presented it's MAC address in
> the device tree as an 8 byte value, even though PAPR requires it to be
> 6 bytes.  This is because, at the time, AIX required the value to be 8
> bytes.  However, modern versions of AIX only support the (correct) 6
> byte value so they are now failing to get this value correctly.
> 
> This patch removes the old workaround and presents the address as the
> correct 6 byte value in the device tree.
> 
> However, the value is also consumed by the Linux ibmveth driver.
> 
> Since commit 13f85203e (3.10, May 2013) the driver has been able to
> handle 6 or 8 byte addresses so versions after that should be
> unaffected by this change.
> 
> Drivers from kernels before that can also handle either type of
> address, but not always:
> * If the first byte's lowest bits are 10, the address must be 6 bytes.
> * Otherwise, the address must be 8 bytes.
> (The two bits in question are significant in a MAC address: they
> indicate a locally-administered unicast address.)
> 
> After this change they will see incorrect values for broadcast or
> non-locally generated addresses. AFAIK these addresses would not
> normally be used as the address of an emulated adapter, so any
> breakage should be rare. The breakage would appear as the MAC address
> losing the first two bytes and receiving two bytes of garbage at the
> other end.
> 
> Signed-off-by: Sam Bobroff 
> ---
> 
>  hw/net/spapr_llan.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)

I just double-checked the code in SLOF, and it should also be able to
deal with both, 8-byte and 6-byte MAC address properties, so from that
point of view, the change is OK.

But since there are still old kernels in the field (RHEL6 is using
2.6.32 for example), it's maybe better to play safe and only provide a
6-byte address property if bit #1 is set in the nicconf.macaddr array,
and provide an 8-byte property otherwise.

 Thomas

Re: [Qemu-devel] [PATCH] trace: fix group name generation

[Greg Kurz]

On Thu, 17 Nov 2016 17:34:44 +0800
Fam Zheng  wrote:

> On Thu, 11/17 10:10, Greg Kurz wrote:
> > On Thu, 17 Nov 2016 16:07:38 +0800
> > Fam Zheng  wrote:
> >   
> > > On Thu, 10/20 15:25, Stefan Hajnoczi wrote:  
> > > > > 
> > > > > I have two other patches ready to fix the current situation:
> > > > > - one using os.getcwd() to guess the build directory
> > > > > - one implementing --group as mentioned in my other mail
> > > > > 
> > > > > But the one that filters unwanted characters is a less intrusive
> > > > > workaround.
> > > > 
> > > > If Dan's patches will eliminate the issue then we can take a workaround.
> > > > 
> > > > Any more comments about Greg's patch before I merge it?
> > > 
> > > Should we include this in -rc1? I still see a build error today.
> > > 
> > > Fam
> > >   
> > 
> > Hi Fam,
> > 
> > My patch was partly superseded by this commit:
> > 
> > commit 630b210b9abbf362905a2096c22c5eb1d6224e77
> > Author: Stefan Weil 
> > Date:   Thu Oct 13 20:29:30 2016 +0200
> > 
> > Fix build for less common build directories names
> > 
> > which does:
> > 
> > -return re.sub(r"/|-", "_", dirname)
> > +return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> > 
> > What is the build error you're hitting ?  
> 
> The substracted parts (basedir and dirname) are different paths for 
> out-of-tree
> build, and the "dirname" after the nonsense substraction as fed into re.sub()
> could still start with a number. In my case the source is at
> 
> /var/tmp/aaa-qemu-clone
> 
> and the build dir is
> 
> /var/tmp/qemu-aio-poll-v2
> 
> Then I get an error as:
> 
> trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events" on 
> integer constant
>  TraceEvent *2_trace_events[] = {
>  ^
> trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ before 
> numeric constant
> trace/generated-tracers.c: In function ‘trace_2_register_events’:
> trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" on 
> integer constant
>  trace_event_register_group(2_trace_events);
> ^
> make: *** [trace/generated-tracers.o] Error 1

My patch was addressing this as well... it is unfortunate it got dumped. :-\

I guess the following should be enough to fix your issue... but I'm no tracetool
expert and I cannot assure it doesn't break anything elsewhere...

-return re.sub(r"[^A-Za-z0-9]", "_", dirname)
+return "_" + re.sub(r"[^A-Za-z0-9]", "_", dirname)

Cheers.

--
Greg

Re: [Qemu-devel] dpdk/vpp and cross-version migration for vhost

[Yuanhan Liu]

On Thu, Nov 17, 2016 at 09:47:09AM +0100, Maxime Coquelin wrote:
> 
> 
> On 11/17/2016 09:29 AM, Yuanhan Liu wrote:
> >As usaual, sorry for late response :/
> >
> >On Thu, Oct 13, 2016 at 08:50:52PM +0300, Michael S. Tsirkin wrote:
> >>Hi!
> >>So it looks like we face a problem with cross-version
> >>migration when using vhost. It's not new but became more
> >>acute with the advent of vhost user.
> >>
> >>For users to be able to migrate between different versions
> >>of the hypervisor the interface exposed to guests
> >>by hypervisor must stay unchanged.
> >>
> >>The problem is that a qemu device is connected
> >>to a backend in another process, so the interface
> >>exposed to guests depends on the capabilities of that
> >>process.
> >>
> >>Specifically, for vhost user interface based on virtio, this includes
> >>the "host features" bitmap that defines the interface, as well as more
> >>host values such as the max ring size.  Adding new features/changing
> >>values to this interface is required to make progress, but on the other
> >>hand we need ability to get the old host features to be compatible.
> >
> >It looks like to the same issue of vhost-user reconnect to me. For example,
> >
> >- start dpdk 16.07 & qemu 2.5
> >- kill dpdk
> >- start dpdk 16.11
> >
> >Though DPDK 16.11 has more features comparing to dpdk 16.07 (say, indirect),
> >above should work. Because qemu saves the negotiated features before the
> >disconnect and stores it back after the reconnection.
> >
> >commit a463215b087c41d7ca94e51aa347cde523831873
> >Author: Marc-André Lureau 
> >Date:   Mon Jun 6 18:45:05 2016 +0200
> >
> >vhost-net: save & restore vhost-user acked features
> >
> >The initial vhost-user connection sets the features to be negotiated
> >with the driver. Renegotiation isn't possible without device reset.
> >
> >To handle reconnection of vhost-user backend, ensure the same set of
> >features are provided, and reuse already acked features.
> >
> >Signed-off-by: Marc-André Lureau 
> >
> >
> >So we could do similar to vhost-user? I mean, save the acked features
> >before migration and store it back after it. This should be able to
> >keep the compatibility. If user downgrades DPDK version, it also could
> >be easily detected, and then exit with an error to user: migration
> >failed due to un-compatible vhost features.
> >
> >Just some rough thoughts. Makes tiny sense?
> 
> My understanding is that the management tool has to know whether
> versions are compatible before initiating the migration:

Makes sense. How about getting and restoring the acked features through
qemu command lines then, say, through the monitor interface?

With that, it would be something like:

- start vhost-user backend (DPDK, VPP, or whatever) & qemu in the src host

- read the acked features (through monitor interface)

- start vhost-user backend in the dst host

- start qemu in the dst host with the just queried acked features

  QEMU then is expected to use this feature set for the later vhost-user
  feature negotitation. Exit if features compatibility is broken.

Thoughts?

--yliu

>  1. The downtime could be unpredictable if a VM has to move from hosts
> to hosts multiple times, which is problematic, especially for NFV.
>  2. If migration is not possible, maybe the management tool would
> prefer not to interrupt the VM on current host.
> 
> I have little experience with migration though, so I could be mistaken.
> 
> Thanks,
> Maxime
> 
> >
> > --yliu
> >>
> >>To solve this problem within qemu, qemu has a versioning system based on
> >>a machine type concept which fundamentally is a version string, by
> >>specifying that string one can get hardware compatible with a previous
> >>qemu version. QEMU also reports the latest version and list of versions
> >>supported so libvirt records the version at VM creation and then is
> >>careful to use this machine version whenever it migrates a VM.
> >>
> >>One might wonder how is this solved with a kernel vhost backend. The
> >>answer is that it mostly isn't - instead an assumption is made, that
> >>qemu versions are deployed together with the kernel - this is generally
> >>true for downstreams.  Thus whenever qemu gains a new feature, it is
> >>already supported by the kernel as well.  However, if one attempts
> >>migration with a new qemu from a system with a new to old kernel, one
> >>would get a failure.
> >>
> >>In the world where we have multiple userspace backends, with some of
> >>these supplied by ISVs, this seems non-realistic.
> >>
> >>IMO we need to support vhost backend versioning, ideally
> >>in a way that will also work for vhost kernel backends.
> >>
> >>So I'd like to get some input from both backend and management
> >>developers on what a good solution would look like.
> >>
> >>If we want to emulate the qemu solution, this involves adding the
> >>concept of interface versions to dpdk.  For example, dpdk could s

Re: [Qemu-devel] [PATCH] trace: fix group name generation

[Fam Zheng]

On Thu, 11/17 10:48, Greg Kurz wrote:
> On Thu, 17 Nov 2016 17:34:44 +0800
> Fam Zheng  wrote:
> 
> > On Thu, 11/17 10:10, Greg Kurz wrote:
> > > On Thu, 17 Nov 2016 16:07:38 +0800
> > > Fam Zheng  wrote:
> > >   
> > > > On Thu, 10/20 15:25, Stefan Hajnoczi wrote:  
> > > > > > 
> > > > > > I have two other patches ready to fix the current situation:
> > > > > > - one using os.getcwd() to guess the build directory
> > > > > > - one implementing --group as mentioned in my other mail
> > > > > > 
> > > > > > But the one that filters unwanted characters is a less intrusive
> > > > > > workaround.
> > > > > 
> > > > > If Dan's patches will eliminate the issue then we can take a 
> > > > > workaround.
> > > > > 
> > > > > Any more comments about Greg's patch before I merge it?
> > > > 
> > > > Should we include this in -rc1? I still see a build error today.
> > > > 
> > > > Fam
> > > >   
> > > 
> > > Hi Fam,
> > > 
> > > My patch was partly superseded by this commit:
> > > 
> > > commit 630b210b9abbf362905a2096c22c5eb1d6224e77
> > > Author: Stefan Weil 
> > > Date:   Thu Oct 13 20:29:30 2016 +0200
> > > 
> > > Fix build for less common build directories names
> > > 
> > > which does:
> > > 
> > > -return re.sub(r"/|-", "_", dirname)
> > > +return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> > > 
> > > What is the build error you're hitting ?  
> > 
> > The substracted parts (basedir and dirname) are different paths for 
> > out-of-tree
> > build, and the "dirname" after the nonsense substraction as fed into 
> > re.sub()
> > could still start with a number. In my case the source is at
> > 
> > /var/tmp/aaa-qemu-clone
> > 
> > and the build dir is
> > 
> > /var/tmp/qemu-aio-poll-v2
> > 
> > Then I get an error as:
> > 
> > trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events" 
> > on integer constant
> >  TraceEvent *2_trace_events[] = {
> >  ^
> > trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ 
> > before numeric constant
> > trace/generated-tracers.c: In function ‘trace_2_register_events’:
> > trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" 
> > on integer constant
> >  trace_event_register_group(2_trace_events);
> > ^
> > make: *** [trace/generated-tracers.o] Error 1
> 
> My patch was addressing this as well... it is unfortunate it got dumped. :-\
> 
> I guess the following should be enough to fix your issue... but I'm no 
> tracetool
> expert and I cannot assure it doesn't break anything elsewhere...
> 
> -return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> +return "_" + re.sub(r"[^A-Za-z0-9]", "_", dirname)

Yes that does make a workaround for me.

Fam

Re: [Qemu-devel] [PATCH] trace: fix group name generation

[Stefan Hajnoczi]

On Thu, Nov 17, 2016 at 10:48:34AM +0100, Greg Kurz wrote:
> On Thu, 17 Nov 2016 17:34:44 +0800
> Fam Zheng  wrote:
> 
> > On Thu, 11/17 10:10, Greg Kurz wrote:
> > > On Thu, 17 Nov 2016 16:07:38 +0800
> > > Fam Zheng  wrote:
> > >   
> > > > On Thu, 10/20 15:25, Stefan Hajnoczi wrote:  
> > > > > > 
> > > > > > I have two other patches ready to fix the current situation:
> > > > > > - one using os.getcwd() to guess the build directory
> > > > > > - one implementing --group as mentioned in my other mail
> > > > > > 
> > > > > > But the one that filters unwanted characters is a less intrusive
> > > > > > workaround.
> > > > > 
> > > > > If Dan's patches will eliminate the issue then we can take a 
> > > > > workaround.
> > > > > 
> > > > > Any more comments about Greg's patch before I merge it?
> > > > 
> > > > Should we include this in -rc1? I still see a build error today.
> > > > 
> > > > Fam
> > > >   
> > > 
> > > Hi Fam,
> > > 
> > > My patch was partly superseded by this commit:
> > > 
> > > commit 630b210b9abbf362905a2096c22c5eb1d6224e77
> > > Author: Stefan Weil 
> > > Date:   Thu Oct 13 20:29:30 2016 +0200
> > > 
> > > Fix build for less common build directories names
> > > 
> > > which does:
> > > 
> > > -return re.sub(r"/|-", "_", dirname)
> > > +return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> > > 
> > > What is the build error you're hitting ?  
> > 
> > The substracted parts (basedir and dirname) are different paths for 
> > out-of-tree
> > build, and the "dirname" after the nonsense substraction as fed into 
> > re.sub()
> > could still start with a number. In my case the source is at
> > 
> > /var/tmp/aaa-qemu-clone
> > 
> > and the build dir is
> > 
> > /var/tmp/qemu-aio-poll-v2
> > 
> > Then I get an error as:
> > 
> > trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events" 
> > on integer constant
> >  TraceEvent *2_trace_events[] = {
> >  ^
> > trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ 
> > before numeric constant
> > trace/generated-tracers.c: In function ‘trace_2_register_events’:
> > trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" 
> > on integer constant
> >  trace_event_register_group(2_trace_events);
> > ^
> > make: *** [trace/generated-tracers.o] Error 1
> 
> My patch was addressing this as well... it is unfortunate it got dumped. :-\
> 
> I guess the following should be enough to fix your issue... but I'm no 
> tracetool
> expert and I cannot assure it doesn't break anything elsewhere...
> 
> -return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> +return "_" + re.sub(r"[^A-Za-z0-9]", "_", dirname)

I think that will solve the problem for QEMU 2.8.  Please send a patch.

Thanks,
Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH 4/8] quorum: Do cleanup in caller coroutine

[Alberto Garcia]

On Thu 10 Nov 2016 06:19:05 PM CET, Kevin Wolf wrote:
> Instead of calling quorum_aio_finalize() deeply nested in what used
> to be an AIO callback, do it in the same functions that allocated the
> AIOCB.
>
> Signed-off-by: Kevin Wolf 

Reviewed-by: Alberto Garcia 

Berto

Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] qapi-schema: clarify 'colo' state for MigrationStatus

[Stefan Hajnoczi]

On Thu, Nov 17, 2016 at 08:52:12AM +0100, Laurent Vivier wrote:
> Le 17/11/2016 à 08:08, Hailiang Zhang a écrit :
> > Hi Laurent,
> > 
> > On 2016/11/15 16:44, Laurent Vivier wrote:
> >> Le 14/11/2016 à 14:54, Stefan Hajnoczi a écrit :
> >>> On Mon, Nov 14, 2016 at 10:36:45AM +0800, Hailiang Zhang wrote:
>  ping ?
> 
>  Anyone pick this up?
> >>>
> >>> The original patch that added these lines went through Amit Shah and
> >>> David Gilbert.  I have CCed them.
> >>
> >> If it is needed, I can also send a pull request through my
> >> trivial-patches branch.
> >>
> > 
> > I think this patch can go through your trivial branch if Amit or Dave
> > didn't pick it up.
> 
> Stefan,
> 
> can I send a pull request for this while we are in hard freeze phase or
> should we wait the end of the release?

Yes, it's a fix for incomplete documentation.

Stefan


signature.asc
Description: PGP signature

[Qemu-devel] [PULL 1/1] qapi-schema: clarify 'colo' state for MigrationStatus

[Laurent Vivier]

From: zhanghailiang 

VM can not get into colo state unless users enable 'x-colo'
capability for migration, Here it is necessary to clarify
this.

Suggested-by: Eric Blake 
Signed-off-by: zhanghailiang 
Message-Id: <1478072652-9884-1-git-send-email-zhang.zhanghaili...@huawei.com>
Reviewed-by: Eric Blake 
Signed-off-by: Laurent Vivier 
---
 qapi-schema.json | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index b0b4bf6..f3e9bfc 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -176,8 +176,9 @@
 #
 # @guest-panicked: guest has been panicked as a result of guest OS panic
 #
-# @colo: guest is paused to save/restore VM state under colo checkpoint (since
-# 2.8)
+# @colo: guest is paused to save/restore VM state under colo checkpoint,
+#VM can not get into this state unless colo capability is enabled
+#for migration. (since 2.8)
 ##
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
@@ -462,7 +463,8 @@
 #
 # @failed: some error occurred during migration process.
 #
-# @colo: VM is in the process of fault tolerance. (since 2.8)
+# @colo: VM is in the process of fault tolerance, VM can not get into this
+#state unless colo capability is enabled for migration. (since 2.8)
 #
 # Since: 2.3
 #
-- 
2.7.4

[Qemu-devel] [PULL 0/1] Trivial patches patches

[Laurent Vivier]

The following changes since commit b0bcc86d2a87456f5a276f941dc775b265b309cf:

  Update version for v2.8.0-rc0 release (2016-11-15 20:55:12 +)

are available in the git repository at:

  git://github.com/vivier/qemu.git tags/trivial-patches-pull-request

for you to fetch changes up to 252093a726eb8aefdea13544554c24f7704555b4:

  qapi-schema: clarify 'colo' state for MigrationStatus (2016-11-17 08:52:47 
+0100)


Fix for incomplete documentation.



zhanghailiang (1):
  qapi-schema: clarify 'colo' state for MigrationStatus

 qapi-schema.json | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH for-2.8] gluster: Fix use after free in glfs_clear_preopened()

[Kevin Wolf]

This fixes a use-after-free bug introduced in commit 6349c154. We need
to use QLIST_FOREACH_SAFE() when freeing elements in the loop. Spotted
by Coverity.

Signed-off-by: Kevin Wolf 
---
 block/gluster.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/block/gluster.c b/block/gluster.c
index 0ce15f7..891c13b 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -239,12 +239,13 @@ static glfs_t *glfs_find_preopened(const char *volume)
 static void glfs_clear_preopened(glfs_t *fs)
 {
 ListElement *entry = NULL;
+ListElement *next;
 
 if (fs == NULL) {
 return;
 }
 
-QLIST_FOREACH(entry, &glfs_list, list) {
+QLIST_FOREACH_SAFE(entry, &glfs_list, list, next) {
 if (entry->saved.fs == fs) {
 if (--entry->saved.ref) {
 return;
-- 
1.8.3.1

Re: [Qemu-devel] a small issue with VSOCK

[Stefan Hajnoczi]

On Tue, Nov 15, 2016 at 07:25:59PM +0100, Claudio Imbrenda wrote:
> I have found a small issue in the current implementation of VSOCK: if
> you load both the vhost_vsock module (or if it's compiled in) then the
> vmw_vsock_virtio_transport will not load successfully (both when
> compiled as a module or compiled in).
> 
> The actual error message I get is:
> 
> vmw_vsock_virtio_transport: probe of virtio2 failed with error -16
> 
> I dug into the code and it seems that vsock_core_init is called twice,
> once for the vhost module and once for the virtio-transport module, the
> second time returning -EBUSY (-16) since it's already initialized.
> 
> This means that if a guest loads the vhost_vsock module, or if it is
> compiled in, then the guest can't use virtio-vsock. This also prevents
> using vsock in a nested virtualization scenario, where both host and
> guest modules could work at the same time.
> 
> Unfortunately I don't have the time to fix this, I just wanted to raise
> the issue here, so that you are now aware of it, and can maybe fix it in
> the future.

Thanks for letting me know.  It's definitely something that will need to
be fixed.  I've added it to my todo list.

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [Qemu-block] [PATCH for-2.8 v2] hbitmap: Fix shifts of constants by granularity

[Stefan Hajnoczi]

On Tue, Nov 15, 2016 at 11:47:32PM +0100, Max Reitz wrote:
> An hbitmap's granularity may be anything from 0 to 63, so when shifting
> constants by its value, they should not be plain ints.
> 
> Even having changed the types, hbitmap_serialization_granularity() still
> tries to shift 64 to the right by the granularity. This operation is
> undefined if the granularity is greater than 57. Adding an assertion is
> fine for now, because serializing is done only in tests so far, but this
> means that only bitmaps with a granularity below 58 can be serialized
> and we should thus add a hbitmap_is_serializable() function later.
> 
> One of the two places touched in this patch uses
> QEMU_ALIGN_UP(x, 1 << y). We can use ROUND_UP() there, since the second
> parameter is obviously a power of two.
> 
> Signed-off-by: Max Reitz 
> ---
> v2:
> - Fix the same issue in hbitmap_truncate() [Stefan]
> - Use ROUND_UP() instead of QEMU_ALIGN_UP() there (because we can)
> - Add an assertion to hbitmap_serialization_granularity() guaranteeing
>   that the shift doesn't overflow; we can guarantee this so far because
>   the only place where serialization functions are used in is the
>   hbitmap test
>   (I'll send a follow-up patch to allow users to check whether a certain
>   bitmap can be (de-)serialized)
> ---
>  util/hbitmap.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [Qemu-devel] your mail

[Kevin Wolf]

Am 16.11.2016 um 20:41 hat Christopher Oliver geschrieben:
> This patch (hack?) works around the slowness in SEEK_HOLE for large dense 
> files
> on Linux tmpfs.  It may improve life elsewhere as well, and the penalty of 
> the checks
> should be vanishingly small where it is not needed.
> 
> If I'm subtly (or not so subtly) wrong, please fire back.

Can't quote the commit message easily because you put it into an
attachment, but I'm not sure if we can make the assumption you're
making. Accessing a raw image from multiple VMs sounds valid to me
as long as a cluster file system is used.

Kevin

Re: [Qemu-devel] [Qemu-block] [PATCH for-2.9 0/2] hbitmap: Add hbitmap_is_serializable()

[Stefan Hajnoczi]

On Tue, Nov 15, 2016 at 11:57:44PM +0100, Max Reitz wrote:
> This series is a follow-up for "hbitmap: Fix shifts of constants by
> granularity".
> 
> So far, adding the assertion in hbitmap_serialization_granularity() (as
> done by said previous patch) is enough and we know that it will always
> hold true since bitmaps are only serialized as part of a test for now.
> 
> However, in the future we need some other way than a failed assertion to
> tell the user that they cannot serialize a certain bitmap. This series
> adds a function that can be called to tell whether a bitmap can be
> (de-)serialized.
> 
> 
> Max Reitz (2):
>   hbitmap: Add hbitmap_is_serializable()
>   test-hbitmap: Add hbitmap_is_serializable() calls
> 
>  include/qemu/hbitmap.h | 13 +
>  tests/test-hbitmap.c   | 11 +++
>  util/hbitmap.c | 22 +++---
>  3 files changed, 43 insertions(+), 3 deletions(-)
> 
> -- 
> 2.10.2
> 
> 

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PULL 0/3] pc: remove redundant fw_cfg file "etc/boot-cpus"

[Stefan Hajnoczi]

On Wed, Nov 16, 2016 at 12:17:33PM -0200, Eduardo Habkost wrote:
> Unfortunately not in time for -rc0, but we still want to remove
> "etc/boot-cpus" before 2.8.0 is released.
> 
> The following changes since commit b0bcc86d2a87456f5a276f941dc775b265b309cf:
> 
>   Update version for v2.8.0-rc0 release (2016-11-15 20:55:12 +)
> 
> are available in the git repository at:
> 
>   git://github.com/ehabkost/qemu.git tags/machine-pull-request
> 
> for you to fetch changes up to e3cadac073a99489df1627be56c3f487f5cb9e31:
> 
>   pc: fix FW_CFG_NB_CPUS to account for -device added CPUs (2016-11-16 
> 12:10:00 -0200)
> 
> 
> pc: remove redundant fw_cfg file "etc/boot-cpus"
> 
> 
> 
> Igor Mammedov (3):
>   Revert "pc: Add 'etc/boot-cpus' fw_cfg file for machine with more than
> 255 CPUs"
>   fw_cfg: move FW_CFG_NB_CPUS out of fw_cfg_init1()
>   pc: fix FW_CFG_NB_CPUS to account for -device added CPUs
> 
>  hw/arm/virt.c |  4 +++-
>  hw/i386/pc.c  | 26 --
>  hw/nvram/fw_cfg.c |  1 -
>  hw/ppc/mac_newworld.c |  1 +
>  hw/ppc/mac_oldworld.c |  1 +
>  hw/sparc/sun4m.c  |  1 +
>  hw/sparc64/sun4u.c|  1 +
>  include/hw/i386/pc.h  |  4 ++--
>  8 files changed, 21 insertions(+), 18 deletions(-)
> 
> -- 
> 2.7.4
> 
> 

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

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 3/3] virtio: set ISR on dataplane notifications

[Stefan Hajnoczi]

On Wed, Nov 16, 2016 at 10:15:25PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 16, 2016 at 07:05:51PM +0100, Paolo Bonzini wrote:
> > @@ -1356,6 +1349,17 @@ bool virtio_should_notify(VirtIODevice *vdev, 
> > VirtQueue *vq)
> >  return !v || vring_need_event(vring_get_used_event(vq), new, old);
> >  }
> >  
> > +void virtio_notify_irqfd(VirtIODevice *vdev, VirtQueue *vq)
> > +{
> > +if (!virtio_should_notify(vdev, vq)) {
> > +return;
> > +}
> > +
> > +trace_virtio_notify_irqfd(vdev, vq);
> > +virtio_set_isr(vq->vdev, 0x1);
> 
> So here, I think we need a comment with parts of
> the commit log.
> 
> /*
>  * virtio spec 1.0 says ISR bit 0 should be ignored with MSI, but
>  * windows drivers included in virtio-win 1.8.0 (circa 2015)
>  * for Windows 8.1 only are incorrectly polling this bit during shutdown
>  * in MSI mode, causing a hang if this bit is never updated.
>  * Next driver release from 2016 fixed this problem, so working around it
>  * is not a must, but it's easy to do so let's do it here.
>  *
>  * Note: it's safe to update ISR from any thread as it was switched
>  * to an atomic operation.
>  */

I agree.  The commit description is nice but the information needs to be
in the code.

I remember explicitly omitting the ISR update when writing the dataplane
code because I saw the spec does not require it for MSI.

A comment is necessary.

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v4 14/15] docs: add qemu logo

[Marc-André Lureau]

Hi

On Thu, Nov 10, 2016 at 7:45 PM Daniel P. Berrange 
wrote:

> On Thu, Nov 10, 2016 at 07:22:08PM +0400, Marc-André Lureau wrote:
> > The pdf (needed by texi2pdf for vectorized images) was generated thanks
> > to inkscape, from the pc-bios/qemu_logo.svg file. Move the original file
> > in the docs folder too, since it's not being referenced elsewhere.
>
> I don't think we should be moving the qemu_logo.svg file.


> The pc-bios has 3 other logo files qemu_logo_no_text.svg, qemu-icon.bmp
> and qemu-nsis.ico. Having those three logo files in pc-bios, and the
> other file in docs/ is unhelpful. IMHO they should all live together,
> either all in docs/ or all in pc-bios/
>

let's keep them in pc-bios for now then. However, the new pdf file can be
in docs?


>
> I'd probably pick docs/ as its a bit strange to be looking for logos
> in a bios sub-dir
>

Hmm, we could add docs/ in data_dir[] when running from the build-tree.
That should make qemu_find_file() returns files from docs/ too, so we could
move the logos.
-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH v2 1/2] ivshmem: fix misconfig of not_legacy_32bit

[Markus Armbruster]

Zhuangyanying  writes:

> From: ZhuangYanying 
>
> After commit 5400c02, ivshmem_64bit renamed to not_legacy_32bit, 
> and changed the implementation of this property.
> Then use64 = 1, ~PCI_BASE_ADDRESS_MEM_TYPE_64 (default for ivshmem),
> the actual use is the legacy model, 
> can not support greater than or equal 1G mapping,
> which is the opposite of configuration requirements.
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Zhuang Yanying 
> Reviewed-by: Gonglei 

I find the commit message hard to understand.  To improve it, let's
figure out what exactly is broken.

The sense of device ivshmem's property use64 is reverted: use64=0
enables the 64 bit memory bar, use64=1 disables it.  Default is 32 bit
unless pc-1.2 or older.  This regressed in commit 5400c02.  Before,
use64 had the correct sense, and the default was 64 bit unless pc-1.2 or
older.

Note that devices ivshmem-plain and ivshmem-doorbell always have a 64
bit memory bar, as intended.

> ---
>  hw/misc/ivshmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> index 230e51b..b897685 100644
> --- a/hw/misc/ivshmem.c
> +++ b/hw/misc/ivshmem.c
> @@ -858,7 +858,7 @@ static void ivshmem_common_realize(PCIDevice *dev, Error 
> **errp)
>  pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY,
>   &s->ivshmem_mmio);
>  
> -if (!s->not_legacy_32bit) {
> +if (s->not_legacy_32bit) {
>  attr |= PCI_BASE_ADDRESS_MEM_TYPE_64;
>  }

Thanks a lot for catching my mistake!

However, this breaks ivshmem-plain and ivshmem-doorbell.  You fix that
in the next patch, but that's no good, the two need to be squashed into
a single commit.

Suggested commit message for the squashed commit:

ivshmem: Fix 64 bit memory bar configuration

Device ivshmem property use64=0 is designed to make the device
expose a 32 bit shared memory BAR instead of 64 bit one.  The
default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit
BAR.  A 32 bit BAR can support only up to 1 GiB of shared memory.

This worked as designed until commit 5400c02 accidentally flipped
its sense: since then, we misinterpret use64=0 as use64=1 and vice
versa.  Worse, the default got flipped as well.  Devices
ivshmem-plain and ivshmem-doorbell are not affected.

Fix by restoring the test of IVShmemState member not_legacy_32bit
that got messed up in commit 5400c02.  Also update its
initialization for devices ivhsmem-plain and ivshmem-doorbell.
Without that, they'd regress to 32 bit BARs.

Cc: qemu-sta...@nongnu.org

Would that work for you?

Re: [Qemu-devel] [PATCH 1/3] virtio: add missing vdev->broken check

[Stefan Hajnoczi]

On Thu, Nov 17, 2016 at 09:31:18AM +0100, Cornelia Huck wrote:
> On Wed, 16 Nov 2016 21:53:07 +
> Stefan Hajnoczi  wrote:
> 
> > virtio_queue_notify_vq() checks vdev->broken before invoking the
> > handler, virtio_queue_notify_aio_vq() should too.
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  hw/virtio/virtio.c | 4 
> >  1 file changed, 4 insertions(+)
> 
> Reviewed-by: Cornelia Huck 
> 
> I think this makes sense as a fix independent of your other patches.

I'm not aware of an actual bug caused by this.  virtio_queue_pop()
returns NULL when the device is broken.

This is more for consistency than correctness, so I didn't add
qemu-stable, -rc1, or send it as a separate fix.


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 0/3] virtio: disable notifications in blk and scsi

[Christian Borntraeger]

On 11/16/2016 10:53 PM, Stefan Hajnoczi wrote:
> Disabling notifications during virtqueue processing reduces the number of
> exits.  The virtio-net device already uses virtio_queue_set_notifications() 
> but
> virtio-blk and virtio-scsi do not.
> 
> The following benchmark shows a 15% reduction in virtio-blk-pci MMIO exits:
> 
>   (host)$ qemu-system-x86_64 \
>   -enable-kvm -m 1024 -cpu host \
>   -drive if=virtio,id=drive0,file=f24.img,format=raw,\
>  cache=none,aio=native
>   (guest)$ fio # jobs=4, iodepth=8, direct=1, randread
>   (host)$ sudo perf record -a -e kvm:kvm_fast_mmio
> 
> Number of kvm_fast_mmio events:
> Unpatched: 685k
> Patched: 592k (-15%, lower is better)
> 
> Note that a workload with iodepth=1 and a single thread will not benefit - 
> this
> is a batching optimization.  The effect should be strongest with large iodepth
> and multiple threads submitting I/O.  The guest I/O scheduler also affects the
> optimization.

I have trouble seeing any difference in terms of performances or CPU load 
(other than 
a reduced number of kicks).
I was expecting some benefit by reducing the spinlock hold times in virtio-blk,
but this needs some more setups to actually find the sweet spot.

Maybe it will show its benefit with the polling thing?
> 
> Stefan Hajnoczi (3):
>   virtio: add missing vdev->broken check
>   virtio-blk: suppress virtqueue kick during processing
>   virtio-scsi: suppress virtqueue kick during processing
> 
>  hw/block/virtio-blk.c | 18 --
>  hw/scsi/virtio-scsi.c | 36 +---
>  hw/virtio/virtio.c|  4 
>  3 files changed, 37 insertions(+), 21 deletions(-)
> 

Re: [Qemu-devel] [PULL 0/1] Trivial patches patches

[no-reply]

Hi,

Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Type: series
Subject: [Qemu-devel] [PULL 0/1] Trivial patches patches
Message-id: 1479378016-19022-1-git-send-email-laur...@vivier.eu

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
2bf70bb qapi-schema: clarify 'colo' state for MigrationStatus

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD   centos6
make[1]: Entering directory `/var/tmp/patchew-tester-tmp-tc1bi2ki/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=702b0b634591
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
COLO support  yes
RDMA support  no
TCG interpreter   no
fdt support   yes
preadv supportyes
fdatasync yes
madvise   yes
posix_madvise yes
libcap-ng support no
vhost-net support yes
vhost-s

Re: [Qemu-devel] [PATCH v2 0/5] [RFC] Add HAX support

[Vincent Palatin]

On Mon, Nov 14, 2016 at 2:09 PM, Vincent Palatin  wrote:
> On Mon, Nov 14, 2016 at 1:36 PM, Stefan Weil  wrote:
>> Am 11.11.2016 um 12:28 schrieb Vincent Palatin:
>> [...]
>>> I have tested the end result on a Windows 10 Pro machine (with UG support)
>>> with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to
>>> exercise various code paths. It looks stable.
>>> I also did a quick regression testing of the integration by running a Linux
>>> build with KVM enabled.
>>
>> My test on Windows 7 with HAXM 6.0.4 fails:
>>
>> $ test/qemu-system-x86_64.exe --enable-hax
>> HAX is working and emulator runs in fast virt mode.
>> Unknown hax vcpu return 1
>
> Sorry about this.
> I did notice that just running the default Seabios/iPXE was triggering
> an issue and forgot to debug it (as I'm mostly running Chromium OS
> images).
> I will have a look and try to sort this out..

I did more debugging on this and opened a whole new can of worms...
The actual crash was the first MMIO access in the iPXE option ROM. The
intel network driver there is triggering the MMIO emulation path (ie
the HAX kernel module is asking us to emulate the MMIO instruction
rather than using the 'fast MMIO' path as all other MMIOs),
this path was never correctly plumbed for the UG case in the original
Intel patchset, and still is not We can run a full linux image
without triggering it showing how unlikely it is, but it is not
documented why it is not using the normal fast MMIO in some rare case
even in UG mode (and I don't have much clues, maybe related to the
second bug described below ?).
Adding back a whole TCG emulation fall-back just for this is somewhat
large and complex, I will try to find first why it's not using the
normal path.
For what it worth '-net nic,model=pcnet' works as a workaround (by not
triggering the MMIO of death)

In addition to this, as you might have noticed, there is no character
on the (virtual) screen.
The VGA emulation is not triggered because the VGA hole is badly mapped.
Digging into this, that's due to the fact that the .region_del()
callback of the MemoryListener is missing a proper implementation, so
the system cannot remove the initial large mapping of memory on top of
those MMIO holes.
But there is a deeper issue to solve this: I'm not seeing in their
current kernel module API (aka the hax-interface.h header) a
(documented) way of removing a mapping...

So I will probably send the v3 patchset with those caveats still
opened to be sure the other changes are not lost,
then I will work further on this and maybe try to get Intel inputs on
those API behaviors.

>
>>
>> This application has requested the Runtime to terminate it in an unusual
>> way.
>> Please contact the application's support team for more information.
>>
>> $ test/qemu-system-i386.exe --enable-hax
>> HAX is working and emulator runs in fast virt mode.
>> Unknown hax vcpu return 1
>>
>> This application has requested the Runtime to terminate it in an unusual
>> way.
>> Please contact the application's support team for more information.
>>
>> I tested debug code (configure --enable-debug && make) based on
>> latest QEMU from git, this patch series and my include fixes.
>>
>> Stefan
>>

Re: [Qemu-devel] [PATCH v2] HACKING: document #include order

[Markus Armbruster]

Stefan Hajnoczi  writes:

> It was not obvious to me why "qemu/osdep.h" must be the first #include.
> This documents the rationale and the overall #include order.
>
> Cc: Fam Zheng 
> Cc: Markus Armbruster 
> Cc: Eric Blake 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  HACKING | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/HACKING b/HACKING
> index 20a9101..4125c97 100644
> --- a/HACKING
> +++ b/HACKING
> @@ -1,10 +1,28 @@
>  1. Preprocessor
>  
> +1.1. Variadic macros
> +
>  For variadic macros, stick with this C99-like syntax:
>  
>  #define DPRINTF(fmt, ...)   \
>  do { printf("IRQ: " fmt, ## __VA_ARGS__); } while (0)
>  
> +1.2. Include directives
> +
> +Order include directives as follows:
> +
> +#include "qemu/osdep.h"  /* Always first... */
> +#include <...>   /* then system headers... */
> +#include "..."   /* and finally QEMU headers. */
> +
> +The "qemu/osdep.h" header contains preprocessor macros that affect the 
> behavior
> +of core system headers like .  It must be the first include so that
> +core system headers included by external libraries get the preprocessor 
> macros
> +that QEMU depends on.
> +
> +Do not include "qemu/osdep.h" from header files since the .c file will have
> +already included it.
> +
>  2. C types
>  
>  It should be common sense to use the right type, but we have collected

Reviewed-by: Markus Armbruster 

[Qemu-devel] [PATCH v3 1/3] kvm: move cpu synchronization code

[Vincent Palatin]

Move the generic cpu_synchronize_ functions to the common hw_accel.h header,
in order to prepare for the addition of a second hardware accelerator.

Signed-off-by: Stefan Weil 
Signed-off-by: Vincent Palatin 
---
 cpus.c  |  1 +
 gdbstub.c   |  1 +
 hw/i386/kvm/apic.c  |  1 +
 hw/i386/kvmvapic.c  |  1 +
 hw/misc/vmport.c|  2 +-
 hw/ppc/pnv_xscom.c  |  2 +-
 hw/ppc/ppce500_spin.c   |  4 ++--
 hw/ppc/spapr.c  |  2 +-
 hw/ppc/spapr_hcall.c|  2 +-
 hw/s390x/s390-pci-inst.c|  1 +
 include/sysemu/hw_accel.h   | 39 +++
 include/sysemu/kvm.h| 23 ---
 monitor.c   |  2 +-
 qom/cpu.c   |  2 +-
 target-arm/cpu.c|  2 +-
 target-i386/helper.c|  1 +
 target-i386/kvm.c   |  1 +
 target-ppc/mmu-hash64.c |  2 +-
 target-ppc/translate_init.c |  2 +-
 target-s390x/gdbstub.c  |  1 +
 20 files changed, 58 insertions(+), 34 deletions(-)
 create mode 100644 include/sysemu/hw_accel.h

diff --git a/cpus.c b/cpus.c
index 5213351..fc78502 100644
--- a/cpus.c
+++ b/cpus.c
@@ -33,6 +33,7 @@
 #include "sysemu/block-backend.h"
 #include "exec/gdbstub.h"
 #include "sysemu/dma.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
 #include "qmp-commands.h"
 #include "exec/exec-all.h"
diff --git a/gdbstub.c b/gdbstub.c
index de62d26..de9b62b 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -32,6 +32,7 @@
 #define MAX_PACKET_LENGTH 4096
 
 #include "qemu/sockets.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
 #include "exec/semihost.h"
 #include "exec/exec-all.h"
diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
index 01cbaa8..328f80c 100644
--- a/hw/i386/kvm/apic.c
+++ b/hw/i386/kvm/apic.c
@@ -14,6 +14,7 @@
 #include "cpu.h"
 #include "hw/i386/apic_internal.h"
 #include "hw/pci/msi.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
 #include "target-i386/kvm_i386.h"
 
diff --git a/hw/i386/kvmvapic.c b/hw/i386/kvmvapic.c
index b30d1b9..2f767b6 100644
--- a/hw/i386/kvmvapic.c
+++ b/hw/i386/kvmvapic.c
@@ -14,6 +14,7 @@
 #include "exec/exec-all.h"
 #include "sysemu/sysemu.h"
 #include "sysemu/cpus.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
 #include "hw/i386/apic_internal.h"
 #include "hw/sysbus.h"
diff --git a/hw/misc/vmport.c b/hw/misc/vmport.c
index c763811..be40930 100644
--- a/hw/misc/vmport.c
+++ b/hw/misc/vmport.c
@@ -25,7 +25,7 @@
 #include "hw/hw.h"
 #include "hw/isa/isa.h"
 #include "hw/i386/pc.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "hw/qdev.h"
 
 //#define VMPORT_DEBUG
diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
index 5aaa264..abcb85d 100644
--- a/hw/ppc/pnv_xscom.c
+++ b/hw/ppc/pnv_xscom.c
@@ -20,7 +20,7 @@
 #include "qapi/error.h"
 #include "hw/hw.h"
 #include "qemu/log.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "target-ppc/cpu.h"
 #include "hw/sysbus.h"
 
diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
index cf958a9..eb219ab 100644
--- a/hw/ppc/ppce500_spin.c
+++ b/hw/ppc/ppce500_spin.c
@@ -29,9 +29,9 @@
 
 #include "qemu/osdep.h"
 #include "hw/hw.h"
-#include "sysemu/sysemu.h"
 #include "hw/sysbus.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
+#include "sysemu/sysemu.h"
 #include "e500.h"
 
 #define MAX_CPUS 32
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 0cbab24..174f4d3 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -36,7 +36,7 @@
 #include "sysemu/device_tree.h"
 #include "sysemu/block-backend.h"
 #include "sysemu/cpus.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "kvm_ppc.h"
 #include "migration/migration.h"
 #include "mmu-hash64.h"
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 9a9bedf..b2a8e48 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1,5 +1,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/sysemu.h"
 #include "qemu/log.h"
 #include "cpu.h"
@@ -9,7 +10,6 @@
 #include "mmu-hash64.h"
 #include "cpu-models.h"
 #include "trace.h"
-#include "sysemu/kvm.h"
 #include "kvm_ppc.h"
 #include "hw/ppc/spapr_ovec.h"
 
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 0864d9b..4d0775c 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -18,6 +18,7 @@
 #include "s390-pci-bus.h"
 #include "exec/memory-internal.h"
 #include "qemu/error-report.h"
+#include "sysemu/hw_accel.h"
 
 /* #define DEBUG_S390PCI_INST */
 #ifdef DEBUG_S390PCI_INST
diff --git a/include/sysemu/hw_accel.h b/include/sysemu/hw_accel.h
new file mode 100644
index 000..03812cf
--- /dev/null
+++ b/include/sysemu/hw_accel.h
@@ -0,0 +1,39 @@
+/*
+ * QEMU Hardware accelertors support
+ *
+ * Copyright 2016 Google, 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.
+ *
+ */
+
+#ifnd

[Qemu-devel] [PATCH v3 0/3] Add HAX support

[Vincent Palatin]

I took a stab at trying to rebase/upstream the support for Intel HAXM.
(Hardware Accelerated Execution Manager).
Intel HAX is kernel-based hardware acceleration module for Windows and MacOSX.

I have based my work on the last version of the source code I found:
the emu-2.2-release branch in the external/qemu-android repository as used by
the Android emulator.
In patch 2/3, I have forward-ported the core HAX code from there.
It has been modified to build and run along with the current code base.
It has been simplifying by removing non-UG hardware support / Darwin support /
Android-specific leftovers.

CAVEAT: this patchset is still RFC because in addition of potentially containing
a few outdated constructs and a questionable mess in qemu_cpu_kick_thread(),
there are 2 unsolved issues:
- in rare cases, the HAX kernel module asks us to emulate a MMIO access rather
  than just using the 'fast MMIO' path. This path is still not implemented (as
  it was in the original patch). It's unclear why/when this is happening
  (eg you can run a full linux image without hitting it but the default iPXE
  option ROM is hitting it in the Intel network driver).
- the MemoryListener implementation cannot remove a memory mapping (e.g. for
  digging the VGA 'hole' in the lowmem). This shortcoming breaks the std vga
  implementation but in the current HAX module API, I don't see any (documented)
  way of implementing this.

In patch 3/3, I have put the plumbing into the QEMU code base, I did some clean
up there and it is reasonably intrusive: i.e.
 Makefile.target   |  1 +
 configure | 18 ++
 cpus.c| 87 ++-
 exec.c| 16 +
 hw/intc/apic_common.c |  3 +-
 include/qom/cpu.h |  5 +++
 include/sysemu/hw_accel.h |  9 +
 qemu-options.hx   | 11 ++
 target-i386/Makefile.objs |  4 +++
 vl.c  | 15 ++--
 10 files changed, 164 insertions(+), 5 deletions(-)

The patch 1/3 just extracts from KVM specific header the cpu_synchronize_
functions that HAX is also using.

I have tested the end result on a Windows 10 Pro machine (with UG support)
with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to
exercise various code paths. It looks stable.
I also did a quick regression testing of the integration by running a Linux
build with KVM enabled.
Just running 'qemu-system-x86_64 -enable-hax' is broken due to the caveats
described above.

Changes from v2 to v3:
- fix saving/restoring FPU registers as suggested by Paolo.
- fix Windows build on all targets as contributed by Stefan Weil.
- clean-up IO / MMIO emulation.
- more clean-up of emulation leftovers.

Changes from v1 to v2:
- fix all style issues in the original code to get it through checkpatch.pl.
- remove Darwin support, it was barely tested and not fully functional.
- remove the support for CPU without UG mode.
- fix most review comments

Vincent Palatin (3):
  kvm: move cpu synchronization code
  target-i386: Add Intel HAX files
  Plumb the HAXM-based hardware acceleration support

 Makefile.target |1 +
 configure   |   18 +
 cpus.c  |   88 ++-
 exec.c  |   16 +
 gdbstub.c   |1 +
 hax-stub.c  |   39 ++
 hw/i386/kvm/apic.c  |1 +
 hw/i386/kvmvapic.c  |1 +
 hw/intc/apic_common.c   |3 +-
 hw/misc/vmport.c|2 +-
 hw/ppc/pnv_xscom.c  |2 +-
 hw/ppc/ppce500_spin.c   |4 +-
 hw/ppc/spapr.c  |2 +-
 hw/ppc/spapr_hcall.c|2 +-
 hw/s390x/s390-pci-inst.c|1 +
 include/qom/cpu.h   |5 +
 include/sysemu/hax.h|   56 ++
 include/sysemu/hw_accel.h   |   48 ++
 include/sysemu/kvm.h|   23 -
 monitor.c   |2 +-
 qemu-options.hx |   11 +
 qom/cpu.c   |2 +-
 target-arm/cpu.c|2 +-
 target-i386/Makefile.objs   |4 +
 target-i386/hax-all.c   | 1250 +++
 target-i386/hax-i386.h  |   85 +++
 target-i386/hax-interface.h |  357 
 target-i386/hax-slot.c  |  333 
 target-i386/hax-slot.h  |   58 ++
 target-i386/hax-windows.c   |  489 +
 target-i386/hax-windows.h   |   89 +++
 target-i386/helper.c|1 +
 target-i386/kvm.c   |1 +
 target-ppc/mmu-hash64.c |2 +-
 target-ppc/translate_init.c |2 +-
 target-s390x/gdbstub.c  |1 +
 vl.c|   15 +-
 37 files changed, 2978 insertions(+), 39 deletions(-)
 create mode 100644 hax-stub.c
 create mode 100644 include/sysemu/hax.h
 create mode 100644 include/sysemu/hw_accel.h
 create mode 100644 target-i386/hax-all.c
 create mode 100644 target-i386/hax-i386.h
 create mode 100644 target-i386/hax-interface.h
 create mode 100644 target-i386/hax-slot.c
 cre

[Qemu-devel] [PATCH v3 3/3] Plumb the HAXM-based hardware acceleration support

[Vincent Palatin]

Use the Intel HAX is kernel-based hardware acceleration module for
Windows (similar to KVM on Linux).

Based on the "target-i386: Add Intel HAX to android emulator" patch
from David Chou 

Signed-off-by: Vincent Palatin 
---
 Makefile.target   |  1 +
 configure | 18 ++
 cpus.c| 87 ++-
 exec.c| 16 +
 hw/intc/apic_common.c |  3 +-
 include/qom/cpu.h |  5 +++
 include/sysemu/hw_accel.h |  9 +
 qemu-options.hx   | 11 ++
 target-i386/Makefile.objs |  4 +++
 vl.c  | 15 ++--
 10 files changed, 164 insertions(+), 5 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 7a5080e..dab81e7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -96,6 +96,7 @@ obj-y += target-$(TARGET_BASE_ARCH)/
 obj-y += disas.o
 obj-y += tcg-runtime.o
 obj-$(call notempty,$(TARGET_XML_FILES)) += gdbstub-xml.o
+obj-$(call lnot,$(CONFIG_HAX)) += hax-stub.o
 obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
 
 obj-$(CONFIG_LIBDECNUMBER) += libdecnumber/decContext.o
diff --git a/configure b/configure
index 7d2a34e..236a7b7 100755
--- a/configure
+++ b/configure
@@ -230,6 +230,7 @@ vhost_net="no"
 vhost_scsi="no"
 vhost_vsock="no"
 kvm="no"
+hax="no"
 colo="yes"
 rdma=""
 gprof="no"
@@ -563,6 +564,7 @@ CYGWIN*)
 ;;
 MINGW32*)
   mingw32="yes"
+  hax="yes"
   audio_possible_drivers="dsound sdl"
   if check_include dsound.h; then
 audio_drv_list="dsound"
@@ -610,6 +612,7 @@ OpenBSD)
 Darwin)
   bsd="yes"
   darwin="yes"
+  hax="yes"
   LDFLAGS_SHARED="-bundle -undefined dynamic_lookup"
   if [ "$cpu" = "x86_64" ] ; then
 QEMU_CFLAGS="-arch x86_64 $QEMU_CFLAGS"
@@ -919,6 +922,10 @@ for opt do
   ;;
   --enable-kvm) kvm="yes"
   ;;
+  --disable-hax) hax="no"
+  ;;
+  --enable-hax) hax="yes"
+  ;;
   --disable-colo) colo="no"
   ;;
   --enable-colo) colo="yes"
@@ -1371,6 +1378,7 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   fdt fdt device tree
   bluez   bluez stack connectivity
   kvm KVM acceleration support
+  hax HAX acceleration support
   coloCOarse-grain LOck-stepping VM for Non-stop Service
   rdmaRDMA-based migration support
   vde support for vde network
@@ -5043,6 +5051,7 @@ echo "ATTR/XATTR support $attr"
 echo "Install blobs $blobs"
 echo "KVM support   $kvm"
 echo "COLO support  $colo"
+echo "HAX support   $hax"
 echo "RDMA support  $rdma"
 echo "TCG interpreter   $tcg_interpreter"
 echo "fdt support   $fdt"
@@ -6027,6 +6036,15 @@ case "$target_name" in
   fi
 fi
 esac
+if test "$hax" = "yes" ; then
+  if test "$target_softmmu" = "yes" ; then
+case "$target_name" in
+i386|x86_64)
+  echo "CONFIG_HAX=y" >> $config_target_mak
+;;
+esac
+  fi
+fi
 if test "$target_bigendian" = "yes" ; then
   echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
 fi
diff --git a/cpus.c b/cpus.c
index fc78502..0e01791 100644
--- a/cpus.c
+++ b/cpus.c
@@ -35,6 +35,7 @@
 #include "sysemu/dma.h"
 #include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
+#include "sysemu/hax.h"
 #include "qmp-commands.h"
 #include "exec/exec-all.h"
 
@@ -1221,6 +1222,39 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
 return NULL;
 }
 
+static void *qemu_hax_cpu_thread_fn(void *arg)
+{
+CPUState *cpu = arg;
+int r;
+qemu_thread_get_self(cpu->thread);
+qemu_mutex_lock(&qemu_global_mutex);
+
+cpu->thread_id = qemu_get_thread_id();
+cpu->created = true;
+cpu->halted = 0;
+current_cpu = cpu;
+
+hax_init_vcpu(cpu);
+qemu_cond_signal(&qemu_cpu_cond);
+
+while (1) {
+if (cpu_can_run(cpu)) {
+r = hax_smp_cpu_exec(cpu);
+if (r == EXCP_DEBUG) {
+cpu_handle_guest_debug(cpu);
+}
+}
+
+while (cpu_thread_is_idle(cpu)) {
+qemu_cond_wait(cpu->halt_cond, &qemu_global_mutex);
+}
+
+qemu_wait_io_event_common(cpu);
+}
+return NULL;
+}
+
+
 static void qemu_cpu_kick_thread(CPUState *cpu)
 {
 #ifndef _WIN32
@@ -1236,7 +1270,33 @@ static void qemu_cpu_kick_thread(CPUState *cpu)
 exit(1);
 }
 #else /* _WIN32 */
-abort();
+if (!qemu_cpu_is_self(cpu)) {
+CONTEXT context;
+
+if (SuspendThread(cpu->hThread) == (DWORD)(-1)) {
+fprintf(stderr, "qemu:%s: GetLastError:%lu\n", __func__,
+GetLastError());
+exit(1);
+}
+
+/* On multi-core systems, we are not sure that the thread is actually
+ * suspended until we can get the context.
+ */
+context.ContextFlags = CONTEXT_CONTROL;
+while (GetThreadContext(cpu->hThread, &context) != 0) {
+continue;
+}
+
+if (hax_enabled()) {
+cpu->exit_request = 1;
+}
+
+if (ResumeThread(cpu->hTh

[Qemu-devel] [PATCH v3 2/3] target-i386: Add Intel HAX files

[Vincent Palatin]

That's a forward port of the core HAX interface code from the
emu-2.2-release branch in the external/qemu-android repository as used by
the Android emulator.

The original commit was "target-i386: Add Intel HAX to android emulator"
saying:
"""
  Backport of 2b3098ff27bab079caab9b46b58546b5036f5c0c
  from studio-1.4-dev into emu-master-dev

Intel HAX (harware acceleration) will enhance android emulator performance
in Windows and Mac OS X in the systems powered by Intel processors with
"Intel Hardware Accelerated Execution Manager" package installed when
user runs android emulator with Intel target.

Signed-off-by: David Chou 
"""

It has been modified to build and run along with the current code base.
The formatting has been fixed to go through scripts/checkpatch.pl,
and the DPRINTF macros have been updated to get the instanciations checked by
the compiler.

The FPU registers saving/restoring has been updated to match the current
QEMU registers layout.

The implementation has been simplified by doing the following modifications:
- removing the code for supporting the hardware without Unrestricted Guest (UG)
  mode (including all the code to fallback on TCG emulation).
- not including the Darwin support (which is not yet debugged/tested).
- simplifying the initialization by removing the leftovers from the Android
  specific code, then trimming down the remaining logic.
- removing the unused MemoryListener callbacks.

Signed-off-by: Vincent Palatin 
---
 hax-stub.c  |   39 ++
 include/sysemu/hax.h|   56 ++
 target-i386/hax-all.c   | 1250 +++
 target-i386/hax-i386.h  |   85 +++
 target-i386/hax-interface.h |  357 
 target-i386/hax-slot.c  |  333 
 target-i386/hax-slot.h  |   58 ++
 target-i386/hax-windows.c   |  489 +
 target-i386/hax-windows.h   |   89 +++
 9 files changed, 2756 insertions(+)
 create mode 100644 hax-stub.c
 create mode 100644 include/sysemu/hax.h
 create mode 100644 target-i386/hax-all.c
 create mode 100644 target-i386/hax-i386.h
 create mode 100644 target-i386/hax-interface.h
 create mode 100644 target-i386/hax-slot.c
 create mode 100644 target-i386/hax-slot.h
 create mode 100644 target-i386/hax-windows.c
 create mode 100644 target-i386/hax-windows.h

diff --git a/hax-stub.c b/hax-stub.c
new file mode 100644
index 000..a532dba
--- /dev/null
+++ b/hax-stub.c
@@ -0,0 +1,39 @@
+/*
+ * QEMU HAXM support
+ *
+ * Copyright (c) 2015, Intel Corporation
+ *
+ * Copyright 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "cpu.h"
+#include "sysemu/hax.h"
+
+int hax_sync_vcpus(void)
+{
+return 0;
+}
+
+int hax_populate_ram(uint64_t va, uint32_t size)
+{
+return -ENOSYS;
+}
+
+int hax_init_vcpu(CPUState *cpu)
+{
+return -ENOSYS;
+}
+
+int hax_smp_cpu_exec(CPUState *cpu)
+{
+return -ENOSYS;
+}
diff --git a/include/sysemu/hax.h b/include/sysemu/hax.h
new file mode 100644
index 000..51c8fd5
--- /dev/null
+++ b/include/sysemu/hax.h
@@ -0,0 +1,56 @@
+/*
+ * QEMU HAXM support
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ *  Anthony Liguori   
+ *
+ * Copyright (c) 2011 Intel Corporation
+ *  Written by:
+ *  Jiang Yunhong
+ *  Xin Xiaohui
+ *  Zhang Xiantao
+ *
+ * Copyright 2016 Google, 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.
+ *
+ */
+
+#ifndef QEMU_HAX_H
+#define QEMU_HAX_H
+
+#include "config-host.h"
+#include "qemu-common.h"
+
+int hax_sync_vcpus(void);
+int hax_init_vcpu(CPUState *cpu);
+int hax_smp_cpu_exec(CPUState *cpu);
+int hax_populate_ram(uint64_t va, uint32_t size);
+
+void hax_cpu_synchronize_state(CPUState *cpu);
+void hax_cpu_synchronize_post_reset(CPUState *cpu);
+void hax_cpu_synchronize_post_init(CPUState *cpu);
+
+#ifdef CONFIG_HAX
+
+int hax_enabled(void);
+
+#include "hw/hw.h"
+#include "qemu/bitops.h"
+#include "exec/memory.h"
+int hax_vcpu_destroy(CPUState *cpu);
+void hax_raise_event(CPUState *cpu);
+void hax_reset_vcpu_state(void *opaque);
+#include "target-i386/hax-interface.h"
+#include "target-i386/hax-i386.h"
+
+#else /* CONFIG_HAX */
+
+#define hax_enabled() (0)
+
+#endif /* CONFIG_HAX */
+
+#endif /* QEMU_HAX_H */
diff --git a/target-i386/hax-all.c b/target-i386/hax-all.c
new file mode 100644
index 000..53bb2a9
--- /dev/null
+++ b/target-i386/hax-all.c
@@ -0,0 +1,1250 @@
+/*
+ * QEMU HAX support
+ *
+ * Copyright IBM, Corp. 2008
+ *   Red Hat, Inc. 2008
+ *
+ * Authors:
+ *  Anthony Liguori   
+ *  Glauber Costa 
+ *
+ * Copyright (c) 2011 Intel Corporation
+ *  Written by:
+ *  Jiang Yunhong

Re: [Qemu-devel] [PULL 0/1] Trivial patches patches

[Fam Zheng]

On Thu, 11/17 03:06, no-re...@patchew.org wrote:
> Cannot create temporary file in ./: Read-only file system
> cc: Internal error: Aborted (program collect2)
> Please submit a full bug report.
> See  for instructions.
> Cannot create temporary file in /tmp/: Read-only file system
> Cannot create temporary file in /tmp/: Read-only file system
> Cannot create temporary file in /tmp/: Read-only file system
> Cannot create temporary file in /tmp/: Read-only file system
> Cannot create temporary file in /tmp/: Read-only file system
> cc: Internal error: Aborted (program collect2)

Somehow patchew tester fails to clean up temp dir after each run, and the disk
is full now.. I've cleanup a little and is investigating. Sorry for the noise.

Fam

Re: [Qemu-devel] [PATCH] dma: rc4030: limit interval timer reload value

[Paolo Bonzini]

On 16/11/2016 07:29, P J P wrote:
> +-- On Wed, 16 Nov 2016, Hervé Poussineau wrote --+
> | I don't have any datasheet for this device either, so I tested with real 
> | programs. Those initialize itr field to either 0 or to 9, so your mask 
> | doesn't change anything.
> | 
> | Tested-by: Hervé Poussineau 
> 
>   Thank you so much. To confirm, do we need to update the mask to maybe 
> 0x000F?

It's not needed if you change it as suggested elsewhere in the thread.

timer_mod(s->periodic_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
  NANOSECONDS_PER_SECOND / 1000 * (s->itr + 1));

Thanks,

Paolo

> | > > >  case 0x0228:
> | > > > -s->itr = val;
> | > > > +s->itr = val & 0x01FF;
> | > > >  qemu_irq_lower(s->timer_irq);

Re: [Qemu-devel] [PATCH v2 2/4] aio: add polling mode to AioContext

[Stefan Hajnoczi]

On Wed, Nov 16, 2016 at 07:14:47PM +0100, Paolo Bonzini wrote:
> 
> 
> On 16/11/2016 18:47, Stefan Hajnoczi wrote:
> > The AioContext event loop uses ppoll(2) or epoll_wait(2) to monitor file
> > descriptors or until a timer expires.  In cases like virtqueues, Linux
> > AIO, and ThreadPool it is technically possible to wait for events via
> > polling (i.e. continuously checking for events without blocking).
> > 
> > Polling can be faster than blocking syscalls because file descriptors,
> > the process scheduler, and system calls are bypassed.
> > 
> > The main disadvantage to polling is that it increases CPU utilization.
> > In classic polling configuration a full host CPU thread might run at
> > 100% to respond to events as quickly as possible.  This patch implements
> > a timeout so we fall back to blocking syscalls if polling detects no
> > activity.  After the timeout no CPU cycles are wasted on polling until
> > the next event loop iteration.
> > 
> > This patch implements an experimental polling mode that can be
> > controlled with the QEMU_AIO_POLL_MAX_NS= environment
> > variable.  The aio_poll() event loop function will attempt to poll
> > instead of using blocking syscalls.
> > 
> > The run_poll_handlers_begin() and run_poll_handlers_end() trace events
> > are added to aid performance analysis and troubleshooting.  If you need
> > to know whether polling mode is being used, trace these events to find
> > out.
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  aio-posix.c | 107 
> > +++-
> >  async.c |  11 +-
> >  include/block/aio.h |   3 ++
> >  trace-events|   4 ++
> >  4 files changed, 123 insertions(+), 2 deletions(-)
> 
> Nice!
> 
> 
> > diff --git a/aio-posix.c b/aio-posix.c
> > index 4379c13..5e5a561 100644
> > --- a/aio-posix.c
> > +++ b/aio-posix.c
> > @@ -18,6 +18,8 @@
> >  #include "block/block.h"
> >  #include "qemu/queue.h"
> >  #include "qemu/sockets.h"
> > +#include "qemu/cutils.h"
> > +#include "trace.h"
> >  #ifdef CONFIG_EPOLL_CREATE1
> >  #include 
> >  #endif
> > @@ -27,12 +29,16 @@ struct AioHandler
> >  GPollFD pfd;
> >  IOHandler *io_read;
> >  IOHandler *io_write;
> > +AioPollFn *io_poll;
> >  int deleted;
> >  void *opaque;
> >  bool is_external;
> >  QLIST_ENTRY(AioHandler) node;
> >  };
> >  
> > +/* How long to poll AioPollHandlers before monitoring file descriptors */
> > +static int64_t aio_poll_max_ns;
> > +
> >  #ifdef CONFIG_EPOLL_CREATE1
> >  
> >  /* The fd number threashold to switch to epoll */
> > @@ -206,11 +212,12 @@ void aio_set_fd_handler(AioContext *ctx,
> >  AioHandler *node;
> >  bool is_new = false;
> >  bool deleted = false;
> > +int poll_disable_cnt = 0;
> 
> poll_disable_cnt = !io_poll - !node->io_poll
> 
> ?  Not the most readable thing, but effective...
> 
> >  node = find_aio_handler(ctx, fd);

Taking into account creation of new nodes:

if (node) {
poll_disable_cnt = !io_poll - !node->io_poll;
} else {
poll_disable_cnt = !io_poll;
}

This does shorten the code quite a bit so I'll use it in the next
version.

> > +static bool run_poll_handlers(AioContext *ctx, int64_t max_ns)
> > +{
> > +bool progress = false;
> > +int64_t end_time;
> > +
> > +assert(ctx->notify_me);
> > +assert(ctx->walking_handlers > 0);
> > +assert(ctx->poll_disable_cnt == 0);
> > +
> > +trace_run_poll_handlers_begin(ctx, max_ns);
> > +
> > +end_time = qemu_clock_get_ns(QEMU_CLOCK_REALTIME) + max_ns;
> > +
> > +do {
> > +AioHandler *node;
> > +
> > +/* Bail if aio_notify() was called (e.g. BH was scheduled) */
> > +if (atomic_read(&ctx->notified)) {
> > +progress = true;
> > +break;
> > +}
> 
> This can be done in event_notifier_dummy_poll.

Nice idea, then the "dummy" function can serve a real purpose!

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 18/25] tcg/aarch64: Handle ctz and clz opcodes

[Richard Henderson]

On 11/16/2016 08:25 PM, Richard Henderson wrote:

@@ -206,6 +206,9 @@ static int tcg_target_const_match(tcg_target_long val, 
TCGType type,
 if ((ct & TCG_CT_CONST_MONE) && val == -1) {
 return 1;
 }
+if ((ct & TCG_CT_CONST_WSZ) && val == (type ? 64 : 32)) {
+return 1;
+}

 return 0;
 }


Bah.  Forgot to revert this hunk at the last minute.


r~

Re: [Qemu-devel] [PATCH for-2.8] gluster: Fix use after free in glfs_clear_preopened()

[Jeff Cody]

On Thu, Nov 17, 2016 at 11:30:08AM +0100, Kevin Wolf wrote:
> This fixes a use-after-free bug introduced in commit 6349c154. We need
> to use QLIST_FOREACH_SAFE() when freeing elements in the loop. Spotted
> by Coverity.
> 
> Signed-off-by: Kevin Wolf 
> ---
>  block/gluster.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/block/gluster.c b/block/gluster.c
> index 0ce15f7..891c13b 100644
> --- a/block/gluster.c
> +++ b/block/gluster.c
> @@ -239,12 +239,13 @@ static glfs_t *glfs_find_preopened(const char *volume)
>  static void glfs_clear_preopened(glfs_t *fs)
>  {
>  ListElement *entry = NULL;
> +ListElement *next;
>  
>  if (fs == NULL) {
>  return;
>  }
>  
> -QLIST_FOREACH(entry, &glfs_list, list) {
> +QLIST_FOREACH_SAFE(entry, &glfs_list, list, next) {
>  if (entry->saved.fs == fs) {
>  if (--entry->saved.ref) {
>  return;
> -- 
> 1.8.3.1
> 

Thanks,

Applied to my block branch:

git://github.com/codyprime/qemu-kvm-jtc.git block

-Jeff

Re: [Qemu-devel] [PATCH 1/3] virtio: add missing vdev->broken check

[Cornelia Huck]

On Thu, 17 Nov 2016 10:58:30 +
Stefan Hajnoczi  wrote:

> On Thu, Nov 17, 2016 at 09:31:18AM +0100, Cornelia Huck wrote:
> > On Wed, 16 Nov 2016 21:53:07 +
> > Stefan Hajnoczi  wrote:
> > 
> > > virtio_queue_notify_vq() checks vdev->broken before invoking the
> > > handler, virtio_queue_notify_aio_vq() should too.
> > > 
> > > Signed-off-by: Stefan Hajnoczi 
> > > ---
> > >  hw/virtio/virtio.c | 4 
> > >  1 file changed, 4 insertions(+)
> > 
> > Reviewed-by: Cornelia Huck 
> > 
> > I think this makes sense as a fix independent of your other patches.
> 
> I'm not aware of an actual bug caused by this.  virtio_queue_pop()
> returns NULL when the device is broken.
> 
> This is more for consistency than correctness, so I didn't add
> qemu-stable, -rc1, or send it as a separate fix.

Fair enough. It was more "we should add this patch even if we don't use
the other patches in this series".

Re: [Qemu-devel] [PATCH for-2.9 2/2] qdev: Change signature of PropertyInfo::release

[Markus Armbruster]

Eduardo Habkost  writes:

> Change the function signature to make implementations simpler and
> safer. No void pointers and Object->DeviceState casts inside each
> release function.
>
> Signed-off-by: Eduardo Habkost 
> ---
>  hw/core/qdev-properties-system.c |  8 ++--
>  hw/core/qdev-properties.c| 10 +-
>  hw/core/qdev.c   | 10 +-
>  include/hw/qdev-core.h   |  2 +-
>  4 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/hw/core/qdev-properties-system.c 
> b/hw/core/qdev-properties-system.c
> index 1b7ea50..4f49109 100644
> --- a/hw/core/qdev-properties-system.c
> +++ b/hw/core/qdev-properties-system.c
> @@ -112,10 +112,8 @@ fail:
>  }
>  }
>  
> -static void release_drive(Object *obj, const char *name, void *opaque)
> +static void release_drive(DeviceState *dev, Property *prop)
>  {
> -DeviceState *dev = DEVICE(obj);
> -Property *prop = opaque;
>  BlockBackend **ptr = qdev_get_prop_ptr(dev, prop);
>  
>  if (*ptr) {
> @@ -210,10 +208,8 @@ static void set_chr(Object *obj, Visitor *v, const char 
> *name, void *opaque,
>  g_free(str);
>  }
>  
> -static void release_chr(Object *obj, const char *name, void *opaque)
> +static void release_chr(DeviceState *dev, Property *prop)
>  {
> -DeviceState *dev = DEVICE(obj);
> -Property *prop = opaque;
>  CharBackend *be = qdev_get_prop_ptr(dev, prop);
>  
>  qemu_chr_fe_deinit(be);
> diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
> index 2a82768..3709050 100644
> --- a/hw/core/qdev-properties.c
> +++ b/hw/core/qdev-properties.c
> @@ -383,10 +383,9 @@ PropertyInfo qdev_prop_uint64 = {
>  
>  /* --- string --- */
>  
> -static void release_string(Object *obj, const char *name, void *opaque)
> +static void release_string(DeviceState *dev, Property *prop)
>  {
> -Property *prop = opaque;
> -g_free(*(char **)qdev_get_prop_ptr(DEVICE(obj), prop));
> +g_free(*(char **)qdev_get_prop_ptr(dev, prop));
>  }

Type-punning moved from the three release methods to ...

>  
>  static void get_string(Object *obj, Visitor *v, const char *name,
> @@ -823,7 +822,7 @@ PropertyInfo qdev_prop_pci_host_devaddr = {
>  typedef struct {
>  struct Property prop;
>  char *propname;
> -ObjectPropertyRelease *release;
> +void (*release)(DeviceState *dev, Property *prop);
>  } ArrayElementProperty;
>  
>  /* object property release callback for array element properties:
> @@ -832,9 +831,10 @@ typedef struct {
>   */
>  static void array_element_release(Object *obj, const char *name, void 
> *opaque)
>  {
> +DeviceState *dev = DEVICE(obj);
>  ArrayElementProperty *p = opaque;
>  if (p->release) {
> -p->release(obj, name, opaque);
> +p->release(dev, &p->prop);
>  }
>  g_free(p->propname);
>  g_free(p);

... this old wrapper and ...

> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index 5783442..b859e15 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -774,6 +774,14 @@ static void qdev_property_add_legacy(DeviceState *dev, 
> Property *prop,
>  g_free(name);
>  }
>  
> +static void qdev_release_prop(Object *obj, const char *name, void *opaque)
> +{
> +DeviceState *dev = DEVICE(obj);
> +Property *prop = opaque;

... a new one.  Hmm.

> +
> +prop->info->release(dev, prop);

Roundabout way to say prop->info->release(DEVICE(obj), opaque).  Matter
of taste.

> +}
> +
>  /**
>   * qdev_property_add_static:
>   * @dev: Device to add the property to.
> @@ -801,7 +809,7 @@ void qdev_property_add_static(DeviceState *dev, Property 
> *prop,
>  
>  object_property_add(obj, prop->name, prop->info->name,
>  prop->info->get, prop->info->set,
> -prop->info->release,
> +prop->info->release ? qdev_release_prop : NULL,
>  prop, &local_err);
>  
>  if (local_err) {
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index 2c97347..5ea2095 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -251,7 +251,7 @@ struct PropertyInfo {
>  int (*print)(DeviceState *dev, Property *prop, char *dest, size_t len);
>  ObjectPropertyAccessor *get;
>  ObjectPropertyAccessor *set;
> -ObjectPropertyRelease *release;
> +void (*release)(DeviceState *dev, Property *prop);
>  };
>  
>  /**

The transformation looks correct to me, but I'm not sure it's
worthwhile.

Moreover, it creates an inconsistency between set()/get() and release(),
both here and in the concrete implementations.  For instance,
get_string() and set_string() continue to take obj, name, opaque, while
release_string() is changed to take dev, prop.  I don't like that.

[Qemu-devel] [PATCH v3] ivshmem: Fix 64 bit memory bar configuration

[Zhuangyanying]

From: Zhuang Yanying 

Device ivshmem property use64=0 is designed to make the device
expose a 32 bit shared memory BAR instead of 64 bit one.  The
default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit
BAR.  A 32 bit BAR can support only up to 1 GiB of shared memory.

This worked as designed until commit 5400c02 accidentally flipped
its sense: since then, we misinterpret use64=0 as use64=1 and vice
versa.  Worse, the default got flipped as well.  Devices
ivshmem-plain and ivshmem-doorbell are not affected.

Fix by restoring the test of IVShmemState member not_legacy_32bit
that got messed up in commit 5400c02.  Also update its
initialization for devices ivhsmem-plain and ivshmem-doorbell.
Without that, they'd regress to 32 bit BARs.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Zhuang Yanying 
Reviewed-by: Gonglei 
Reviewed-by: Marc-Andr?? Lureau 

---
 hw/misc/ivshmem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 230e51b..abeaf3d 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -858,7 +858,7 @@ static void ivshmem_common_realize(PCIDevice *dev, Error 
**errp)
 pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY,
  &s->ivshmem_mmio);
 
-if (!s->not_legacy_32bit) {
+if (s->not_legacy_32bit) {
 attr |= PCI_BASE_ADDRESS_MEM_TYPE_64;
 }
 
@@ -1045,6 +1045,7 @@ static void ivshmem_plain_init(Object *obj)
  ivshmem_check_memdev_is_busy,
  OBJ_PROP_LINK_UNREF_ON_RELEASE,
  &error_abort);
+s->not_legacy_32bit = 1;
 }
 
 static void ivshmem_plain_realize(PCIDevice *dev, Error **errp)
@@ -1116,6 +1117,7 @@ static void ivshmem_doorbell_init(Object *obj)
 
 s->features |= (1 << IVSHMEM_MSI);
 s->legacy_size = SIZE_MAX;  /* whatever the server sends */
+s->not_legacy_32bit = 1;
 }
 
 static void ivshmem_doorbell_realize(PCIDevice *dev, Error **errp)
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH for-2.9 1/2] qom: Remove release function from class properties

[Markus Armbruster]

Eduardo Habkost  writes:

> The release functions are never called for class properties, and
> their semantics aren't even defined clearly (should the release
> function be called when an instance is destroyed, or when a class
> is destroyed?). Remove the unused functionality.
>
> Signed-off-by: Eduardo Habkost 
> ---
>  backends/hostmem.c   |  4 ++--
>  hw/core/machine.c|  6 +++---
>  hw/i386/pc.c |  8 
>  hw/ppc/pnv.c |  2 +-
>  include/qom/object.h |  1 -
>  qom/object.c | 14 --
>  6 files changed, 14 insertions(+), 21 deletions(-)
>
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index 4256d24..856e96e 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -368,11 +368,11 @@ host_memory_backend_class_init(ObjectClass *oc, void 
> *data)
>  object_class_property_add(oc, "size", "int",
>  host_memory_backend_get_size,
>  host_memory_backend_set_size,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  object_class_property_add(oc, "host-nodes", "int",
>  host_memory_backend_get_host_nodes,
>  host_memory_backend_set_host_nodes,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  object_class_property_add_enum(oc, "policy", "HostMemPolicy",
>  HostMemPolicy_lookup,
>  host_memory_backend_get_policy,
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index b0fd91f..c64e5f1 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -372,13 +372,13 @@ static void machine_class_init(ObjectClass *oc, void 
> *data)
>  
>  object_class_property_add(oc, "kernel-irqchip", "OnOffSplit",
>  NULL, machine_set_kernel_irqchip,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  object_class_property_set_description(oc, "kernel-irqchip",
>  "Configure KVM in-kernel irqchip", &error_abort);
>  
>  object_class_property_add(oc, "kvm-shadow-mem", "int",
>  machine_get_kvm_shadow_mem, machine_set_kvm_shadow_mem,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  object_class_property_set_description(oc, "kvm-shadow-mem",
>  "KVM shadow MMU size", &error_abort);
>  
> @@ -409,7 +409,7 @@ static void machine_class_init(ObjectClass *oc, void 
> *data)
>  
>  object_class_property_add(oc, "phandle-start", "int",
>  machine_get_phandle_start, machine_set_phandle_start,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  object_class_property_set_description(oc, "phandle-start",
>  "The first phandle ID we may generate dynamically", 
> &error_abort);
>  
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index a9b1950..46f95bf 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -2308,24 +2308,24 @@ static void pc_machine_class_init(ObjectClass *oc, 
> void *data)
>  
>  object_class_property_add(oc, PC_MACHINE_MEMHP_REGION_SIZE, "int",
>  pc_machine_get_hotplug_memory_region_size, NULL,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  
>  object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size",
>  pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  
>  object_class_property_set_description(oc, PC_MACHINE_MAX_RAM_BELOW_4G,
>  "Maximum ram below the 4G boundary (32bit boundary)", &error_abort);
>  
>  object_class_property_add(oc, PC_MACHINE_SMM, "OnOffAuto",
>  pc_machine_get_smm, pc_machine_set_smm,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  object_class_property_set_description(oc, PC_MACHINE_SMM,
>  "Enable SMM (pc & q35)", &error_abort);
>  
>  object_class_property_add(oc, PC_MACHINE_VMPORT, "OnOffAuto",
>  pc_machine_get_vmport, pc_machine_set_vmport,
> -NULL, NULL, &error_abort);
> +NULL, &error_abort);
>  object_class_property_set_description(oc, PC_MACHINE_VMPORT,
>  "Enable vmport (pc & q35)", &error_abort);
>  
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 9df7b25..3fb68c3 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -777,7 +777,7 @@ static void powernv_machine_class_props_init(ObjectClass 
> *oc)
>  {
>  object_class_property_add(oc, "num-chips", "uint32_t",
>pnv_get_num_chips, pnv_set_num_chips,
> -  NULL, NULL, NULL);
> +  NULL, NULL);
>  object_class_property_set_description(oc, "num-chips",
>"Specifies the number of processor chips",
>NULL);

The above all drop null releases.  No functional change.

> diff --git a/include/qom/object.h b/include/qom/object.h
> index 5ecc2d1..fbf9df2 100644
> --- a/include/qom/object.h
> +++ b/include/qom/object.h
> @@ -945,7 +945,6 @@ ObjectProperty *objec

Re: [Qemu-devel] [PATCH v14 12/22] vfio: Add notifier callback to parent's ops structure of mdev

[Jike Song]

On 11/17/2016 04:46 AM, Kirti Wankhede wrote:
> Add a notifier calback to parent's ops structure of mdev device so that per
> device notifer for vfio module is registered through vfio_mdev module.
> 
> Signed-off-by: Kirti Wankhede 
> Signed-off-by: Neo Jia 
> Change-Id: Iafa6f1721aecdd6e50eb93b153b5621e6d29b637
> ---
>  drivers/vfio/mdev/vfio_mdev.c | 34 +-
>  include/linux/mdev.h  |  9 +
>  2 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
> index ffc36758cb84..2f8e06e5f95a 100644
> --- a/drivers/vfio/mdev/vfio_mdev.c
> +++ b/drivers/vfio/mdev/vfio_mdev.c
> @@ -24,6 +24,15 @@
>  #define DRIVER_AUTHOR   "NVIDIA Corporation"
>  #define DRIVER_DESC "VFIO based driver for Mediated device"
>  
> +static int vfio_mdev_notifier(struct notifier_block *nb, unsigned long 
> action,
> +   void *data)
> +{
> + struct mdev_device *mdev = container_of(nb, struct mdev_device, nb);
> + struct parent_device *parent = mdev->parent;
> +
> + return parent->ops->notifier(mdev, action, data);
> +}
> +
>  static int vfio_mdev_open(void *device_data)
>  {
>   struct mdev_device *mdev = device_data;
> @@ -36,9 +45,27 @@ static int vfio_mdev_open(void *device_data)
>   if (!try_module_get(THIS_MODULE))
>   return -ENODEV;
>  
> + if (likely(parent->ops->notifier)) {
> + mdev->nb.notifier_call = vfio_mdev_notifier;
> + ret = vfio_register_notifier(&mdev->dev, &mdev->nb);
> +
> + /*
> +  * This should not fail if backend iommu module doesn't support
> +  * register_notifier.
> +  */
> + if (ret && (ret != -ENOTTY)) {
> + pr_err("Failed to register notifier for mdev\n");
> + module_put(THIS_MODULE);
> + return ret;
> + }
> + }
> +
>   ret = parent->ops->open(mdev);
> - if (ret)
> + if (ret) {
> + if (likely(parent->ops->notifier))
> + vfio_unregister_notifier(&mdev->dev, &mdev->nb);
>   module_put(THIS_MODULE);
> + }
>  
>   return ret;
>  }
> @@ -51,6 +78,11 @@ static void vfio_mdev_release(void *device_data)
>   if (likely(parent->ops->release))
>   parent->ops->release(mdev);
>  
> + if (likely(parent->ops->notifier)) {
> + if (vfio_unregister_notifier(&mdev->dev, &mdev->nb))
> + pr_err("Failed to unregister notifier for mdev\n");
> + }
> +
>   module_put(THIS_MODULE);
>  }
>  
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index ec819e9a115a..94c43034c297 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -37,6 +37,7 @@ struct mdev_device {
>   struct kref ref;
>   struct list_headnext;
>   struct kobject  *type_kobj;
> + struct notifier_block   nb;
>  };
>  
>  /**
> @@ -85,6 +86,12 @@ struct mdev_device {
>   * @mmap:mmap callback
>   *   @mdev: mediated device structure
>   *   @vma: vma structure
> + * @notifer: Notifier callback, currently only for
> + *   VFIO_IOMMU_NOTIFY_DMA_UNMAP action notified duing
> + *   DMA_UNMAP call on mapped iova range.
> + *   @mdev: mediated device structure
> + *   @action: Action for which notifier is called
> + *   @data: Data associated with the notifier
>   * Parent device that support mediated device should be registered with mdev
>   * module with parent_ops structure.
>   **/
> @@ -106,6 +113,8 @@ struct parent_ops {
>   ssize_t (*ioctl)(struct mdev_device *mdev, unsigned int cmd,
>unsigned long arg);
>   int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
> + int (*notifier)(struct mdev_device *mdev, unsigned long action,
> + void *data);
>  };
>  
>  /* interface for exporting mdev supported type attributes */
>

Hi Alex, Kirti,

Since everyone agreed we should let the vendor driver call 
vfio_register_notifier
directly, can you drop this patch from merging? So that I don't need to send a
reverse patch.

Thanks :)

--
Thanks,
Jike

 

Re: [Qemu-devel] [PATCH for-2.9] qmp: Report QOM type name on query-cpu-definitions

[Markus Armbruster]

Eduardo Habkost  writes:

> The new typename attribute on query-cpu-definitions will be used
> to help management software use device-list-properties to check
> which properties can be set using -cpu or -global for the CPU
> model.
>
> Signed-off-by: Eduardo Habkost 
> ---
>  qapi-schema.json| 4 +++-
>  target-arm/helper.c | 1 +
>  target-i386/cpu.c   | 1 +
>  target-ppc/translate_init.c | 1 +
>  target-s390x/cpu_models.c   | 1 +
>  5 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index b0b4bf6..9a3bdd4 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -3216,6 +3216,8 @@
>  # @unavailable-features: #optional List of properties that prevent
>  #the CPU model from running in the current
>  #host. (since 2.8)
> +# @typename: Type name that can be used as argument to 
> @device-list-properties,
> +#to introspect properties configurable using -cpu or -global.
>  #
>  # @unavailable-features is a list of QOM property names that
>  # represent CPU model attributes that prevent the CPU from running.
> @@ -3237,7 +3239,7 @@
>  ##
>  { 'struct': 'CpuDefinitionInfo',
>'data': { 'name': 'str', '*migration-safe': 'bool', 'static': 'bool',
> -'*unavailable-features': [ 'str' ] } }
> +'*unavailable-features': [ 'str' ], 'typename': 'str' } }
>  
>  ##
>  # @query-cpu-definitions:
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index b5b65ca..3fc01b5 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -5207,6 +5207,7 @@ static void arm_cpu_add_definition(gpointer data, 
> gpointer user_data)
>  info = g_malloc0(sizeof(*info));
>  info->name = g_strndup(typename,
> strlen(typename) - strlen("-" TYPE_ARM_CPU));
> +info->q_typename = g_strdup(typename);
>  
>  entry = g_malloc0(sizeof(*entry));
>  entry->value = info;
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index 6eec5dc..725f6cb 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -2239,6 +2239,7 @@ static void x86_cpu_definition_entry(gpointer data, 
> gpointer user_data)
>  info->name = x86_cpu_class_get_model_name(cc);
>  x86_cpu_class_check_missing_features(cc, &info->unavailable_features);
>  info->has_unavailable_features = true;
> +info->q_typename = g_strdup(object_class_get_name(oc));
>  
>  entry = g_malloc0(sizeof(*entry));
>  entry->value = info;
> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> index 208fa1e..42b9274 100644
> --- a/target-ppc/translate_init.c
> +++ b/target-ppc/translate_init.c
> @@ -10305,6 +10305,7 @@ CpuDefinitionInfoList 
> *arch_query_cpu_definitions(Error **errp)
>  
>  info = g_malloc0(sizeof(*info));
>  info->name = g_strdup(alias->alias);
> +info->q_typename = g_strdup(object_class_get_name(oc));
>  
>  entry = g_malloc0(sizeof(*entry));
>  entry->value = info;
> diff --git a/target-s390x/cpu_models.c b/target-s390x/cpu_models.c
> index c1e729d..5b66d33 100644
> --- a/target-s390x/cpu_models.c
> +++ b/target-s390x/cpu_models.c
> @@ -290,6 +290,7 @@ static void create_cpu_model_list(ObjectClass *klass, 
> void *opaque)
>  info->has_migration_safe = true;
>  info->migration_safe = scc->is_migration_safe;
>  info->q_static = scc->is_static;
> +info->q_typename = g_strdup(object_class_get_name(klass));
>  
>  
>  entry = g_malloc0(sizeof(*entry));

A bit sad that the QOM type name needs to be computed in
target-dependent code.

With Eric's doc fix:
Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [Bug?] Guest pause because VMPTRLD failed in KVM

[Paolo Bonzini]

On 10/11/2016 15:10, gong lei wrote:
>4) The isssue can't be reporduced. I search the Intel VMX sepc about 
> reaseons
> of vmptrld failure:
>The instruction fails if its operand is not properly aligned, sets
> unsupported physical-address bits, or is equal to the VMXON
>pointer. In addition, the instruction fails if the 32 bits in memory
> referenced by the operand do not match the VMCS
>revision identifier supported by this processor.
> 
>But I can't find any cues from the KVM source code. It seems each
>error conditions is impossible in theory. :(

Yes, it should not happen. :(

If it's not reproducible, it's really hard to say what it was, except a
random memory corruption elsewhere or even a bit flip (!).

Paolo

[Qemu-devel] GPIO input?

[Liviu Ionescu]

I added graphical buttons to GNU ARM Eclipse QEMU, and I can already trigger 
actions when a button is pushed/released, so currently I can reset the 
STM32F4DISCOVERY board clicking the reset button on the board picture.

Now I want to implement the user button, which on this board is connected to a 
GPIO pin.


Can you suggest an existing board that somehow implements a GPIO input, so I 
can a use a similar mechanism?


Thank you,

Liviu

Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration

[Marcelo Tosatti]

On Mon, Nov 14, 2016 at 04:15:18PM -0200, Marcelo Tosatti wrote:
> On Mon, Nov 14, 2016 at 06:20:29PM +0100, Paolo Bonzini wrote:
> > 
> > 
> > On 14/11/2016 18:13, Marcelo Tosatti wrote:
> > > On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
> > >>
> > >>
> > >> On 14/11/2016 16:40, Marcelo Tosatti wrote:
> > >>> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> > >>> {
> > >>> KVMClockState *s = opaque;
> > >>>
> > >>> /*
> > >>>  * On machine types that support reliable KVM_GET_CLOCK,
> > >>>  * if host kernel does provide reliable KVM_GET_CLOCK,
> > >>>  * set src_use_reliable_get_clock=true so that destination
> > >>>  * avoids reading kvmclock from memory.
> > >>>  */
> > >>> if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
> > >>> {
> > >>> s->src_use_reliable_get_clock = true;
> > >>> }
> > >>>
> > >>> return s->mach_use_reliable_get_clock;
> > >>> }
> > >>>
> > >>>
> > >>> Ah, OK, done.
> > >>
> > >> s->src_use_reliable_get_clock should not be set with
> > >> KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.
> > > 
> > > Well, thats not right: What matters is the presence of get_kvmclock_ns 
> > > which returns a value that the guest sees. 
> > > 
> > > get_kernel_monotonic_clock() + kvmclock_offset +
> > > (rdtsc() - tsc_timestamp)
> > > 
> > > IOW what the guest sees. And you changed that in 
> > > 
> > > commit 108b249c453dd7132599ab6dc7e435a7036c193f
> > > Author: Paolo Bonzini 
> > > Date:   Thu Sep 1 14:21:03 2016 +0200
> > > 
> > > KVM: x86: introduce get_kvmclock_ns
> > > 
> > > And the correct behaviour (once KVM_GET_CLOCK is fixed per 
> > > previous message to return rdtsc - tsc_timestamp for the 
> > > non masterclock case) depends on this commit above, 
> > > not on masterclock.
> > 
> > This commit in turn only gets the correct behavior if 
> > "vcpu->arch.hv_clock.flags & PVCLOCK_TSC_STABLE_BIT" (and it will be 
> > changed soon to ka->use_masterclock).  KVM_CHECK_EXTENSION can still 
> > return KVM_CLOCK_TSC_STABLE even if the masterclock is disabled, 
> > because KVM_CHECK_EXTENSION only tells you which flags are known for
> > this version of the KVM module.
> 
> What QEMU wants is to use KVM_GET_CLOCK at pre_save independently
> of whether masterclock is enabled or not... it just depends
> on KVM_GET_CLOCK being correct for the masterclock case
> (108b249c453dd7132599ab6dc7e435a7036c193f).
> 
> So a "reliable KVM_GET_CLOCK" (that does not timebackward
> when masterclock is enabled) is much simpler to userspace
> than "whether masterclock is enabled or not".
> 
> If you have a reason why that should not be the case,
> let me know.
> 
> > To see if the masterclock is enabled _now_, you need to check what
> > KVM_GET_CLOCK sets in the flags.  From the KVM_CLOCK_TSC_STABLE patch:
> > 
> > user_ns.flags = kvm->arch.use_master_clock ? 
> > KVM_CLOCK_TSC_STABLE : 0;
> 
> Again, whether masterclock is enable is independent of 
> being able to use KVM_GET_CLOCK at pre_save.

Is this point OK ?

Using 

break;
+   case KVM_CAP_ADJUST_CLOCK:
+   r = KVM_CLOCK_TSC_STABLE;
+   break;

To infer whether KVM_GET_CLOCK is fixed for the monotonic case.

Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration

[Paolo Bonzini]

On 17/11/2016 13:16, Marcelo Tosatti wrote:
> On Mon, Nov 14, 2016 at 04:15:18PM -0200, Marcelo Tosatti wrote:
>> On Mon, Nov 14, 2016 at 06:20:29PM +0100, Paolo Bonzini wrote:
>>>
>>>
>>> On 14/11/2016 18:13, Marcelo Tosatti wrote:
 On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 16:40, Marcelo Tosatti wrote:
>> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
>> {
>> KVMClockState *s = opaque;
>>
>> /*
>>  * On machine types that support reliable KVM_GET_CLOCK,
>>  * if host kernel does provide reliable KVM_GET_CLOCK,
>>  * set src_use_reliable_get_clock=true so that destination
>>  * avoids reading kvmclock from memory.
>>  */
>> if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
>> {
>> s->src_use_reliable_get_clock = true;
>> }
>>
>> return s->mach_use_reliable_get_clock;
>> }
>>
>>
>> Ah, OK, done.
>
> s->src_use_reliable_get_clock should not be set with
> KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.

 Well, thats not right: What matters is the presence of get_kvmclock_ns 
 which returns a value that the guest sees. 

 get_kernel_monotonic_clock() + kvmclock_offset +
 (rdtsc() - tsc_timestamp)

 IOW what the guest sees. And you changed that in 

 commit 108b249c453dd7132599ab6dc7e435a7036c193f
 Author: Paolo Bonzini 
 Date:   Thu Sep 1 14:21:03 2016 +0200

 KVM: x86: introduce get_kvmclock_ns

 And the correct behaviour (once KVM_GET_CLOCK is fixed per 
 previous message to return rdtsc - tsc_timestamp for the 
 non masterclock case) depends on this commit above, 
 not on masterclock.
>>>
>>> This commit in turn only gets the correct behavior if 
>>> "vcpu->arch.hv_clock.flags & PVCLOCK_TSC_STABLE_BIT" (and it will be 
>>> changed soon to ka->use_masterclock).  KVM_CHECK_EXTENSION can still 
>>> return KVM_CLOCK_TSC_STABLE even if the masterclock is disabled, 
>>> because KVM_CHECK_EXTENSION only tells you which flags are known for
>>> this version of the KVM module.
>>
>> What QEMU wants is to use KVM_GET_CLOCK at pre_save independently
>> of whether masterclock is enabled or not... it just depends
>> on KVM_GET_CLOCK being correct for the masterclock case
>> (108b249c453dd7132599ab6dc7e435a7036c193f).
>>
>> So a "reliable KVM_GET_CLOCK" (that does not timebackward
>> when masterclock is enabled) is much simpler to userspace
>> than "whether masterclock is enabled or not".
>>
>> If you have a reason why that should not be the case,
>> let me know.
>>
>>> To see if the masterclock is enabled _now_, you need to check what
>>> KVM_GET_CLOCK sets in the flags.  From the KVM_CLOCK_TSC_STABLE patch:
>>>
>>> user_ns.flags = kvm->arch.use_master_clock ? 
>>> KVM_CLOCK_TSC_STABLE : 0;
>>
>> Again, whether masterclock is enable is independent of 
>> being able to use KVM_GET_CLOCK at pre_save.
> 
> Is this point OK ?
> 
> Using 
> 
> break;
> +   case KVM_CAP_ADJUST_CLOCK:
> +   r = KVM_CLOCK_TSC_STABLE;
> +   break;
> 
> To infer whether KVM_GET_CLOCK is fixed for the monotonic case.

Yes, I still haven't digested why it is correct (I need to read again
what you wrote), but it is indeed correct to use KVM_CAP_ADJUST_CLOCK
this way.

Paolo

Re: [Qemu-devel] [PATCH v2] hw/isa/lpc_ich9: inject SMI on all VCPUs if APM_STS == 'Q'

[Laszlo Ersek]

On 11/16/16 21:27, Michael S. Tsirkin wrote:
> On Wed, Nov 16, 2016 at 07:03:27PM +0100, Laszlo Ersek wrote:
>> On 11/16/16 15:05, Paolo Bonzini wrote:
>>>
>>>
>>> On 16/11/2016 14:18, Michael S. Tsirkin wrote:
> - we could have another magic 0xB2 value, which is implemented directly
> in QEMU and sets 0xB3 to a magic value.  Then OVMF can invoke it
> after SMBASE relocation and SMM IPL (so as not to crash on old QEMUs)
> to detect the new feature.  It can fail to start if using traditional
> AP and the new feature is not there.

 If we keep collecting these magic values, should architect it
 and do a host/guest bitmap like virtio does?
>>>
>>> The value written in 0xB3 can certainly be a feature bitmap.  For now we
>>> would have for example
>>>
>>> bit 0   if set, writing 0x10-0xFF to 0xB2 results in a broadcast SMI
>>> bit 1-7 zero
>>
>> Doable, but:
>> - doesn't address how OVMF learns about the broadcast SMI availability,
>> - the command value OVMF currently writes is 0.
>>
>> How about this:
>> - etc/smi/features is the LE uint64_t bitmap proposed earlier, bit#0
>> stands for broadcast SMI availability
>> - 0xB2 is the command value (independent of 0xB3)
>> - 0XB3 is a guest feature bitmap (valid for the next request). SeaBIOS
>> reserves bit#0 already (uses values 0 and 1), so we can use the
>> remaining 7 bits for requesting features. Bit#1 (value 2) could be the
>> broadcast SMI.
>>
>> This does resemble a kind of feature negotiation, except the host cannot
>> signal back an error (unsupported combination of features), like
>> virtio-1.0 can. We can make QEMU abort in that case, or ignore the flags.
>>
>> Thanks
>> Laszlo
> 
> I think that if you are going to do it, do it like 1.0:
> - same bitmap for host and guest. how about a writeable fw cfg file?

fw_cfg files are not writeable since qemu 2.4 (see commits 023e3148567ac
and 6cec43e178cde).

How about this alternative, in STS:
- bit 0: read and written transparently
- bit 1: on write:
 0 -- set features in bits 2-7
 1 -- query host features into bits 2-7
 on read:
 - after querying features:
   - reads back as 0 if the interface is supported
   - reads back as 1 if the interface is missing
 - after setting features:
   - reads back as 0 if the feature subset is valid
   - reads back as 1 otherwise
- bit 2: on write:
 - when setting features: request broadcast SMI
 - when querying features: ignored
 on read:
 - after setting features: zero
 - after querying features: broadcast SMI availability (1 if
   available)

- bit 3-7: future features (I think 5 more features for SMI handling
   should suffice), working similarly to bit 2

SeaBIOS writes values 0x00 and 0x01, and expects to find the same when
reading back. Bit pattern _000?b  translates to "clear all
features", which always succeeds and results in behavior identical to
the current one, hence bits 1-7 read back as zero.

OVMF:
- write 0x02, read back value:
  - if bit 1 is set, interface is missing
  - otherwise feature bitmap was returned in bits 2-7
- select requested features in bits 2-7, set bit 1 to 0, write value,
  read back value
  - if bit 1 is set, the feature subset is invalid
  - okay otherwise

Thanks
Laszlo

> - use 0XB3 bit for FEATURES_OK
> 

[Qemu-devel] [qemu patch V2 0/2] improve kvmclock difference on migration

[Marcelo Tosatti]

See individual patches for details.
This patchset depends on the not yet applied
"[PATCH] kvm: kvmclock: let KVM_GET_CLOCK return whether the master clock is in 
use"
from Paolo.

Re: [Qemu-devel] [PATCH 0/3] virtio: disable notifications in blk and scsi

[Stefan Hajnoczi]

On Thu, Nov 17, 2016 at 12:17:57AM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 16, 2016 at 09:53:06PM +, Stefan Hajnoczi wrote:
> > Disabling notifications during virtqueue processing reduces the number of
> > exits.  The virtio-net device already uses virtio_queue_set_notifications() 
> > but
> > virtio-blk and virtio-scsi do not.
> > 
> > The following benchmark shows a 15% reduction in virtio-blk-pci MMIO exits:
> > 
> >   (host)$ qemu-system-x86_64 \
> >   -enable-kvm -m 1024 -cpu host \
> >   -drive if=virtio,id=drive0,file=f24.img,format=raw,\
> >  cache=none,aio=native
> >   (guest)$ fio # jobs=4, iodepth=8, direct=1, randread
> >   (host)$ sudo perf record -a -e kvm:kvm_fast_mmio
> > 
> > Number of kvm_fast_mmio events:
> > Unpatched: 685k
> > Patched: 592k (-15%, lower is better)
> 
> Any chance to see a gain in actual benchmark numbers?
> This is important to make sure we are not just
> shifting overhead around.

Good idea.  I reran this morning without any tracing and compared
against bare metal.

Total reads for a 30-second 4 KB random read benchmark with 4 processes
x iodepth=8:

Bare metal: 26440 MB
Unpatched:  19799 MB
Patched:21252 MB

Patched vs Unpatched: +7% improvement
Patched vs Bare metal: 20% virtualization overhead

The disk image is a 8 GB raw file on XFS on LVM on dm-crypt on a Samsung
MZNLN256HCHP 256 GB SATA SSD.  This is just my laptop.

Seems like a worthwhile improvement to me.

Stefan


signature.asc
Description: PGP signature

[Qemu-devel] [qemu patch V2 1/2] kvm: sync linux headers

[Marcelo Tosatti]

Import KVM_CLOCK_TSC_STABLE.

Signed-off-by: Marcelo Tosatti 

diff --git a/include/standard-headers/linux/input.h 
b/include/standard-headers/linux/input.h
index 7361a16..b472b85 100644
--- a/include/standard-headers/linux/input.h
+++ b/include/standard-headers/linux/input.h
@@ -245,6 +245,7 @@ struct input_mask {
 #define BUS_SPI0x1C
 #define BUS_RMI0x1D
 #define BUS_CEC0x1E
+#define BUS_INTEL_ISHTP0x1F
 
 /*
  * MT_TOOL types
diff --git a/include/standard-headers/linux/pci_regs.h 
b/include/standard-headers/linux/pci_regs.h
index 4040951..e5a2e68 100644
--- a/include/standard-headers/linux/pci_regs.h
+++ b/include/standard-headers/linux/pci_regs.h
@@ -612,6 +612,8 @@
  */
 #define PCI_EXP_DEVCAP236  /* Device Capabilities 2 */
 #define  PCI_EXP_DEVCAP2_ARI   0x0020 /* Alternative Routing-ID */
+#define  PCI_EXP_DEVCAP2_ATOMIC_ROUTE  0x0040 /* Atomic Op routing */
+#define PCI_EXP_DEVCAP2_ATOMIC_COMP64  0x0100 /* Atomic 64-bit compare */
 #define  PCI_EXP_DEVCAP2_LTR   0x0800 /* Latency tolerance 
reporting */
 #define  PCI_EXP_DEVCAP2_OBFF_MASK 0x000c /* OBFF support mechanism */
 #define  PCI_EXP_DEVCAP2_OBFF_MSG  0x0004 /* New message signaling */
@@ -619,6 +621,7 @@
 #define PCI_EXP_DEVCTL240  /* Device Control 2 */
 #define  PCI_EXP_DEVCTL2_COMP_TIMEOUT  0x000f  /* Completion Timeout Value */
 #define  PCI_EXP_DEVCTL2_ARI   0x0020  /* Alternative Routing-ID */
+#define PCI_EXP_DEVCTL2_ATOMIC_REQ 0x0040  /* Set Atomic requests */
 #define  PCI_EXP_DEVCTL2_IDO_REQ_EN0x0100  /* Allow IDO for requests */
 #define  PCI_EXP_DEVCTL2_IDO_CMP_EN0x0200  /* Allow IDO for completions */
 #define  PCI_EXP_DEVCTL2_LTR_EN0x0400  /* Enable LTR mechanism 
*/
@@ -671,7 +674,8 @@
 #define PCI_EXT_CAP_ID_PMUX0x1A/* Protocol Multiplexing */
 #define PCI_EXT_CAP_ID_PASID   0x1B/* Process Address Space ID */
 #define PCI_EXT_CAP_ID_DPC 0x1D/* Downstream Port Containment */
-#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_DPC
+#define PCI_EXT_CAP_ID_PTM 0x1F/* Precision Time Measurement */
+#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PTM
 
 #define PCI_EXT_CAP_DSN_SIZEOF 12
 #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
@@ -964,4 +968,13 @@
 
 #define PCI_EXP_DPC_SOURCE_ID  10  /* DPC Source Identifier */
 
+/* Precision Time Measurement */
+#define PCI_PTM_CAP0x04/* PTM Capability */
+#define  PCI_PTM_CAP_REQ   0x0001  /* Requester capable */
+#define  PCI_PTM_CAP_ROOT  0x0004  /* Root capable */
+#define  PCI_PTM_GRANULARITY_MASK  0xFF00  /* Clock granularity */
+#define PCI_PTM_CTRL   0x08/* PTM Control */
+#define  PCI_PTM_CTRL_ENABLE   0x0001  /* PTM enable */
+#define  PCI_PTM_CTRL_ROOT 0x0002  /* Root select */
+
 #endif /* LINUX_PCI_REGS_H */
diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index 541268c..2fb7859 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -84,6 +84,13 @@ struct kvm_regs {
 #define KVM_VGIC_V2_DIST_SIZE  0x1000
 #define KVM_VGIC_V2_CPU_SIZE   0x2000
 
+/* Supported VGICv3 address types  */
+#define KVM_VGIC_V3_ADDR_TYPE_DIST 2
+#define KVM_VGIC_V3_ADDR_TYPE_REDIST   3
+
+#define KVM_VGIC_V3_DIST_SIZE  SZ_64K
+#define KVM_VGIC_V3_REDIST_SIZE(2 * SZ_64K)
+
 #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
 #define KVM_ARM_VCPU_PSCI_0_2  1 /* CPU uses PSCI v0.2 */
 
diff --git a/linux-headers/asm-x86/unistd_32.h 
b/linux-headers/asm-x86/unistd_32.h
index abeaf40..d45ea28 100644
--- a/linux-headers/asm-x86/unistd_32.h
+++ b/linux-headers/asm-x86/unistd_32.h
@@ -377,5 +377,8 @@
 #define __NR_copy_file_range 377
 #define __NR_preadv2 378
 #define __NR_pwritev2 379
+#define __NR_pkey_mprotect 380
+#define __NR_pkey_alloc 381
+#define __NR_pkey_free 382
 
 #endif /* _ASM_X86_UNISTD_32_H */
diff --git a/linux-headers/asm-x86/unistd_64.h 
b/linux-headers/asm-x86/unistd_64.h
index 73c3d1f..e22db91 100644
--- a/linux-headers/asm-x86/unistd_64.h
+++ b/linux-headers/asm-x86/unistd_64.h
@@ -330,5 +330,8 @@
 #define __NR_copy_file_range 326
 #define __NR_preadv2 327
 #define __NR_pwritev2 328
+#define __NR_pkey_mprotect 329
+#define __NR_pkey_alloc 330
+#define __NR_pkey_free 331
 
 #endif /* _ASM_X86_UNISTD_64_H */
diff --git a/linux-headers/asm-x86/unistd_x32.h 
b/linux-headers/asm-x86/unistd_x32.h
index e5aea76..84e58b2 100644
--- a/linux-headers/asm-x86/unistd_x32.h
+++ b/linux-headers/asm-x86/unistd_x32.h
@@ -283,6 +283,9 @@
 #define __NR_membarrier (__X32_SYSCALL_BIT + 324)
 #define __NR_mlock2 (__X32_SYSCALL_BIT + 325)
 #define __NR_copy_file_range (__X32_SYSCALL_BIT + 326)
+#define __NR_pkey_mprotect (__X32_SYS

[Qemu-devel] [qemu patch V2 2/2] kvmclock: reduce kvmclock difference on migration

[Marcelo Tosatti]

Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
indicates that KVM_GET_CLOCK returns a value as seen by the guest at
that moment.

For new machine types, use this value rather than reading 
from guest memory.

This reduces kvmclock difference on migration from 5s to 0.1s
(when max_downtime == 5s).

Signed-off-by: Marcelo Tosatti 

---
 hw/i386/kvm/clock.c|  108 ++---
 include/hw/i386/pc.h   |5 ++
 target-i386/kvm.c  |7 +++
 target-i386/kvm_i386.h |1 
 4 files changed, 107 insertions(+), 14 deletions(-)

v2: 
- improve variable names (Juan)
- consolidate code on kvm_get_clock function (Paolo)
- return mach_use_reliable_get_clock from needed function (Paolo)

Index: qemu-mig-advance-clock/hw/i386/kvm/clock.c
===
--- qemu-mig-advance-clock.orig/hw/i386/kvm/clock.c 2016-11-14 
10:40:39.748116312 -0200
+++ qemu-mig-advance-clock/hw/i386/kvm/clock.c  2016-11-14 13:38:29.299955042 
-0200
@@ -36,6 +36,12 @@
 
 uint64_t clock;
 bool clock_valid;
+
+/* whether machine supports reliable KVM_GET_CLOCK */
+bool mach_use_reliable_get_clock;
+
+/* whether source host supported reliable KVM_GET_CLOCK */
+bool src_use_reliable_get_clock;
 } KVMClockState;
 
 struct pvclock_vcpu_time_info {
@@ -81,6 +87,19 @@
 return nsec + time.system_time;
 }
 
+static uint64_t kvm_get_clock(void)
+{
+struct kvm_clock_data data;
+int ret;
+
+ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
+if (ret < 0) {
+fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
+abort();
+}
+return data.clock;
+}
+
 static void kvmclock_vm_state_change(void *opaque, int running,
  RunState state)
 {
@@ -91,15 +110,37 @@
 
 if (running) {
 struct kvm_clock_data data = {};
-uint64_t time_at_migration = kvmclock_current_nsec(s);
+uint64_t pvclock_via_mem = 0;
 
-s->clock_valid = false;
+/* local (running VM) restore */
+if (s->clock_valid) {
+/*
+ * if host does not support reliable KVM_GET_CLOCK,
+ * read kvmclock value from memory
+ */
+if (!kvm_has_adjust_clock_stable()) {
+pvclock_via_mem = kvmclock_current_nsec(s);
+}
+/* migration/savevm/init restore */
+} else {
+/*
+ * use s->clock in case machine uses reliable
+ * get clock and source host supported
+ * reliable get clock
+ */
+if (!(s->mach_use_reliable_get_clock &&
+  s->src_use_reliable_get_clock)) {
+pvclock_via_mem = kvmclock_current_nsec(s);
+}
+}
 
-/* We can't rely on the migrated clock value, just discard it */
-if (time_at_migration) {
-s->clock = time_at_migration;
+/* We can't rely on the saved clock value, just discard it */
+if (pvclock_via_mem) {
+s->clock = pvclock_via_mem;
 }
 
+s->clock_valid = false;
+
 data.clock = s->clock;
 ret = kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
 if (ret < 0) {
@@ -120,8 +161,6 @@
 }
 }
 } else {
-struct kvm_clock_data data;
-int ret;
 
 if (s->clock_valid) {
 return;
@@ -129,13 +168,7 @@
 
 kvm_synchronize_all_tsc();
 
-ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
-if (ret < 0) {
-fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
-abort();
-}
-s->clock = data.clock;
-
+s->clock = kvm_get_clock();
 /*
  * If the VM is stopped, declare the clock state valid to
  * avoid re-reading it on next vmsave (which would return
@@ -152,22 +185,69 @@
 qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
 }
 
+static bool kvmclock_src_use_reliable_get_clock(void *opaque)
+{
+KVMClockState *s = opaque;
+
+/*
+ * On machine types that support reliable KVM_GET_CLOCK,
+ * if host kernel does provide reliable KVM_GET_CLOCK,
+ * set src_use_reliable_get_clock=true so that destination
+ * avoids reading kvmclock from memory.
+ */
+if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable()) {
+s->src_use_reliable_get_clock = true;
+}
+
+return s->mach_use_reliable_get_clock;
+}
+
+static const VMStateDescription kvmclock_reliable_get_clock = {
+.name = "kvmclock/src_use_reliable_get_clock",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = kvmclock_src_use_reliable_get_clock,
+.fields = (VMStateField[]) {
+VMSTATE_BOOL(src_use_reliable_get_clock, KVMClockState),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static void kvmclock_pre_save(void *opaque)
+{
+

Re: [Qemu-devel] [PATCH for-2.9] qmp: Report QOM type name on query-cpu-definitions

[Eduardo Habkost]

On Thu, Nov 17, 2016 at 01:38:54PM +0100, Markus Armbruster wrote:
[...]
> A bit sad that the QOM type name needs to be computed in
> target-dependent code.

I plan to provide a generic implementation of
query-cpu-definitions later, to fix this.

> 
> With Eric's doc fix:
> Reviewed-by: Markus Armbruster 

Thanks!

-- 
Eduardo

[Qemu-devel] 答复: [RFC, v1, 1/2] hw/vfio/platform: add hisilicon hnsvf device

[Songwenjun (Rick Song)]

Hi, Eric,
OK, I will look over it and see what I can do here.

BR.
Rick Song

Hi Rick,

On 21/10/2016 03:22, Rick Song wrote:
> The platform device class has become abstract. This patch introduces a 
> hisilicon hnsvf device that derives from it.

in https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg03401.html
we discussed the relevance to get the platform device non abstract. No change 
was submitted though. I can submit something next week except if you want to 
submit a patch yourself.

The idea is we would instantiate the vfio platform device using such an
option:

-device vfio-platform-device,compat="hisilicon,hnsvf-v2"

Once such change is accepted, only your second patch will be requested.

Thanks

Eric

> 
> Signed-off-by: Rick Song 
> ---
>  hw/vfio/Makefile.objs |  1 +
>  hw/vfio/hisi-hnsvf.c  | 56 
> +++
>  include/hw/vfio/vfio-hisi-hnsvf.h | 51 
> +++
>  3 files changed, 108 insertions(+)
>  create mode 100644 hw/vfio/hisi-hnsvf.c  create mode 100644 
> include/hw/vfio/vfio-hisi-hnsvf.h
> 
> diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs index 
> c25e32b..d19dffc 100644
> --- a/hw/vfio/Makefile.objs
> +++ b/hw/vfio/Makefile.objs
> @@ -4,5 +4,6 @@ obj-$(CONFIG_PCI) += pci.o pci-quirks.o
>  obj-$(CONFIG_SOFTMMU) += platform.o
>  obj-$(CONFIG_SOFTMMU) += calxeda-xgmac.o
>  obj-$(CONFIG_SOFTMMU) += amd-xgbe.o
> +obj-$(CONFIG_SOFTMMU) += hisi-hnsvf.o
>  obj-$(CONFIG_SOFTMMU) += spapr.o
>  endif
> diff --git a/hw/vfio/hisi-hnsvf.c b/hw/vfio/hisi-hnsvf.c new file mode 
> 100644 index 000..5b48e27
> --- /dev/null
> +++ b/hw/vfio/hisi-hnsvf.c
> @@ -0,0 +1,56 @@
> +/*
> + * Hisilicon HNS Virtual Function VFIO device
> + *
> + * Copyright Huawei Limited, 2016
> + *
> + * Authors:
> + *  Rick Song 
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  
> +See
> + * the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "hw/vfio/vfio-hisi-hnsvf.h"
> +
> +static void hisi_hnsvf_realize(DeviceState *dev, Error **errp) {
> +VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(dev);
> +VFIOHisiHnsvfDeviceClass *k = 
> +VFIO_HISI_HNSVF_DEVICE_GET_CLASS(dev);
> +
> +vdev->compat = g_strdup("hisilicon,hnsvf-v2");
> +
> +k->parent_realize(dev, errp);
> +}
> +
> +static const VMStateDescription vfio_platform_hisi_hnsvf_vmstate = {
> +.name = TYPE_VFIO_HISI_HNSVF,
> +.unmigratable = 1,
> +};
> +
> +static void vfio_hisi_hnsvf_class_init(ObjectClass *klass, void 
> +*data) {
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +VFIOHisiHnsvfDeviceClass *vcxc =
> +VFIO_HISI_HNSVF_DEVICE_CLASS(klass);
> +vcxc->parent_realize = dc->realize;
> +dc->realize = hisi_hnsvf_realize;
> +dc->desc = "VFIO HISI HNSVF";
> +dc->vmsd = &vfio_platform_hisi_hnsvf_vmstate;
> +}
> +
> +static const TypeInfo vfio_hisi_hnsvf_dev_info = {
> +.name = TYPE_VFIO_HISI_HNSVF,
> +.parent = TYPE_VFIO_PLATFORM,
> +.instance_size = sizeof(VFIOHisiHnsvfDevice),
> +.class_init = vfio_hisi_hnsvf_class_init,
> +.class_size = sizeof(VFIOHisiHnsvfDeviceClass), };
> +
> +static void register_hisi_hnsvf_dev_type(void)
> +{
> +type_register_static(&vfio_hisi_hnsvf_dev_info);
> +}
> +
> +type_init(register_hisi_hnsvf_dev_type)
> diff --git a/include/hw/vfio/vfio-hisi-hnsvf.h 
> b/include/hw/vfio/vfio-hisi-hnsvf.h
> new file mode 100644
> index 000..9208656
> --- /dev/null
> +++ b/include/hw/vfio/vfio-hisi-hnsvf.h
> @@ -0,0 +1,51 @@
> +/*
> + * VFIO Hisilicon HNS Virtual Function device
> + *
> + * Copyright Hisilicon Limited, 2016
> + *
> + * Authors:
> + *  Rick Song 
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  
> +See
> + * the COPYING file in the top-level directory.
> + *
> + */
> +
> +#ifndef HW_VFIO_VFIO_HISI_HNSVF_H
> +#define HW_VFIO_VFIO_HISI_HNSVF_H
> +
> +#include "hw/vfio/vfio-platform.h"
> +
> +#define TYPE_VFIO_HISI_HNSVF "vfio-hisi-hnsvf"
> +
> +/**
> + * This device exposes:
> + * - 5 MMIO regions: MAC, PCS, SerDes Rx/Tx regs,
> + SerDes Integration Registers 1/2 & 2/2
> + * - 2 level sensitive IRQs and optional DMA channel IRQs  */ struct 
> +VFIOHisiHnsvfDevice {
> +VFIOPlatformDevice vdev;
> +};
> +
> +typedef struct VFIOHisiHnsvfDevice VFIOHisiHnsvfDevice;
> +
> +struct VFIOHisiHnsvfDeviceClass {
> +/*< private >*/
> +VFIOPlatformDeviceClass parent_class;
> +/*< public >*/
> +DeviceRealize parent_realize;
> +};
> +
> +typedef struct VFIOHisiHnsvfDeviceClass VFIOHisiHnsvfDeviceClass;
> +
> +#define VFIO_HISI_HNSVF_DEVICE(obj) \
> + OBJECT_CHECK(VFIOHisiHnsvfDevice, (obj), TYPE_VFIO_HISI_HNSVF) 
> +#define VFIO_HISI_HNSVF_DEVICE_CLASS(klass) \
> + OBJECT_CLASS_CHECK(VFIOHisiHnsvfDeviceClass, (klass), \
> +TYPE_VFIO_HISI_HNSVF) #define 
> +VFIO_HISI_HNSVF_DEVICE_GET_CLASS(obj) \
> + OBJECT_GET_CLASS(

Re: [Qemu-devel] [PATCH v3] ivshmem: Fix 64 bit memory bar configuration

[Markus Armbruster]

Zhuangyanying  writes:

> From: Zhuang Yanying 
>
> Device ivshmem property use64=0 is designed to make the device
> expose a 32 bit shared memory BAR instead of 64 bit one.  The
> default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit
> BAR.  A 32 bit BAR can support only up to 1 GiB of shared memory.
>
> This worked as designed until commit 5400c02 accidentally flipped
> its sense: since then, we misinterpret use64=0 as use64=1 and vice
> versa.  Worse, the default got flipped as well.  Devices
> ivshmem-plain and ivshmem-doorbell are not affected.
>
> Fix by restoring the test of IVShmemState member not_legacy_32bit
> that got messed up in commit 5400c02.  Also update its
> initialization for devices ivhsmem-plain and ivshmem-doorbell.
> Without that, they'd regress to 32 bit BARs.
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Zhuang Yanying 
> Reviewed-by: Gonglei 
> Reviewed-by: Marc-Andr. Lureau 

Commit message should not be indented, and Marc-André's name got
mangled.  Both could be touched up on commit.

Thanks again for cleaning up my mess.

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH for-2.9 1/2] qom: Remove release function from class properties

[Eduardo Habkost]

On Thu, Nov 17, 2016 at 01:33:34PM +0100, Markus Armbruster wrote:
> Eduardo Habkost  writes:
> 
> > The release functions are never called for class properties, and
> > their semantics aren't even defined clearly (should the release
> > function be called when an instance is destroyed, or when a class
> > is destroyed?). Remove the unused functionality.
> >
> > Signed-off-by: Eduardo Habkost 
[...]
> >  g_hash_table_insert(klass->properties, g_strdup(name), prop);
> > @@ -1808,7 +1806,6 @@ void object_class_property_add_str(ObjectClass 
> > *klass, const char *name,
> >  object_class_property_add(klass, name, "string",
> >get ? property_get_str : NULL,
> >set ? property_set_str : NULL,
> > -  property_release_str,
> >prop, &local_err);
> >  if (local_err) {
> >  error_propagate(errp, local_err);
> 
> Here, you drop property_release_str(), which calls g_free().  Assuming
> you claim that it's never called is correct, this is again no functional
> change.  But that begs the question why not freeing the stuff
> property_release_str() frees is correct.  Can you explain?

property_release_str() frees prop. The only right moment to free
prop is on class destruction or class property removal, but we
have no mechanisms for class destruction or class property
removal today.

> 
> > @@ -1897,7 +1894,6 @@ void object_class_property_add_bool(ObjectClass 
> > *klass, const char *name,
> >  object_class_property_add(klass, name, "bool",
> >get ? property_get_bool : NULL,
> >set ? property_set_bool : NULL,
> > -  property_release_bool,
> >prop, &local_err);
> >  if (local_err) {
> >  error_propagate(errp, local_err);
> > @@ -1985,7 +1981,6 @@ void object_class_property_add_enum(ObjectClass 
> > *klass, const char *name,
> >  object_class_property_add(klass, name, typename,
> >get ? property_get_enum : NULL,
> >set ? property_set_enum : NULL,
> > -  property_release_enum,
> >prop, &local_err);
> >  if (local_err) {
> >  error_propagate(errp, local_err);
> > @@ -2082,7 +2077,6 @@ void object_class_property_add_tm(ObjectClass *klass, 
> > const char *name,
> >  
> >  object_class_property_add(klass, name, "struct tm",
> >get ? property_get_tm : NULL, NULL,
> > -  property_release_tm,
> >prop, &local_err);
> >  if (local_err) {
> >  error_propagate(errp, local_err);
> 
> Likewise.

Same as above.

> [...]

-- 
Eduardo

Re: [Qemu-devel] [Qemu-ppc] Problem with QEMU PPC test image

[Thomas Huth]

On 17.11.2016 03:25, Programmingkid wrote:
> When I run this test disk image: 
> http://wiki.qemu.org/download/ppc-virtexml507-linux-2_6_34.tgz
> 
> I see these error messages:
> /selftest.sh: line 6: /usr/bin/sha1test: not found
> /selftest.sh: line 7: /usr/bin/hmactest: not found
> 
> Maybe /usr/bin/sha1sum is what the first test should be. I don't see anything 
> that looked like hmactest in the image file.

I guess these were test programs from the OpenSSL suite:

https://github.com/openssl/openssl/blob/master/test/sha1test.c
https://github.com/openssl/openssl/blob/master/test/hmactest.c

... but apparently have not been included in the image anymore. So I'd
suggest that you simply disable them in the selftest.sh script.

 Thomas


PS: Why is the qemu-ppc list called "l...@suse.de:PowerPC list:PowerPC"
in the "To:" field of your mail?

Re: [Qemu-devel] [PATCH for-2.9 2/2] qdev: Change signature of PropertyInfo::release

[Eduardo Habkost]

On Thu, Nov 17, 2016 at 01:26:47PM +0100, Markus Armbruster wrote:
[...]
> The transformation looks correct to me, but I'm not sure it's
> worthwhile.
> 
> Moreover, it creates an inconsistency between set()/get() and release(),
> both here and in the concrete implementations.  For instance,
> get_string() and set_string() continue to take obj, name, opaque, while
> release_string() is changed to take dev, prop.  I don't like that.

My main goal was just to make it more difficult to mistakenly use
the qdev propery release functions (that should be called at
object destruction time) as the release functions for class
properties (that should be called at class destruction time). But
this is not as important if patch 1/2 removes the class property
release functions. We can drop this patch.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v7 02/10] hcd-xhci: check & correct param before using it

[Markus Armbruster]

Cao jin  writes:

> usb_xhci_realize() corrects invalid values of property "intrs"
> automatically, but the uncorrected value is passed to msi_init(),
> which chokes on invalid values.  Delay that until after the
> correction.
>
> Resources allocated by usb_xhci_init() are leaked when msi_init()
> fails.  Fix by calling it after msi_init().
>
> CC: Gerd Hoffmann 
> CC: Markus Armbruster 
> CC: Marcel Apfelbaum 
> CC: Michael S. Tsirkin 
> Signed-off-by: Cao jin 
> ---
> In previous rounds, usb_xhci_init() is moved too far from its original place,
> which results the segfault(XHCIState->numports is initialized in this func),
> now move it adjacent to msi_init code hunk.

Thanks for explaining what you changed.

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [Qemu-block] [PATCH] block: split large discard requests from block frontend

[Olaf Hering]

On Fri, May 06, Max Reitz wrote:

> On 01.04.2016 19:49, Olaf Hering wrote:
> > On Fri, Apr 01, Max Reitz wrote:
> > 
> >> In any case, do you have a test case where a guest was able to submit a
> >> request that led to the overflow error you described in the commit message?
> > 
> > mkfs -t ext4 /dev/sdb1 in a xen guest with qcow2 as backing device.
> > When I added discard support to libxl I worked with raw images, so I did
> > not notice this. Not sure why it happens to work in kvm guests. I assume
> > the frontend driver just works around the qemu bug by limiting its
> > request size.
> 
> Sorry for not having replied in so long.
> 
> I know next to nothing about Xen, but I'm very much inclined to think
> the Xen block driver (hw/block/xen_disk.c) is at fault here. The
> blkif_request_discard structure it uses for accepting discard requests
> apparently has a uint64_t nr_sectors field.

Thanks for the pointer.

Looking at current master, BLKIF_OP_DISCARD is indeed broken. The values
passed from the guest are u64 and get stashed into signed values. I will
add a loop to repeatedly call blk_aio_pdiscard with small chunks of
BDRV_REQUEST_MAX_SECTORS.

We quickly checked other users of blk_aio_pdiscard and it appears they
are not affected because they notify the guest abuilt the limits.

Olaf

[Qemu-devel] [PATCH] trace: fix generated code build break

[Greg Kurz]

If the QEMU source dir is

/var/tmp/aaa-qemu-clone

and the build dir is

/var/tmp/qemu-aio-poll-v2

Then I get an error as:

trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events"
 on integer constant
 TraceEvent *2_trace_events[] = {
 ^
trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ before
 numeric constant
trace/generated-tracers.c: In function ‘trace_2_register_events’:
trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" on
 integer constant
 trace_event_register_group(2_trace_events);
^
make: *** [trace/generated-tracers.o] Error 1

This patch fixes the issue.

Reported-by: Fam Zheng 
Signed-off-by: Greg Kurz 
---
 scripts/tracetool.py |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/tracetool.py b/scripts/tracetool.py
index fe9c9e904b03..c9e47371d3c6 100755
--- a/scripts/tracetool.py
+++ b/scripts/tracetool.py
@@ -70,7 +70,7 @@ def make_group_name(filename):
 
 if dirname == "":
 return "common"
-return re.sub(r"[^A-Za-z0-9]", "_", dirname)
+return "_" + re.sub(r"[^A-Za-z0-9]", "_", dirname)
 
 def main(args):
 global _SCRIPT

Re: [Qemu-devel] [PULL 0/1] tags/xen-20161108-tag

[Wei Liu]

Hi Peter and Stefan, can you merge this pull request? We want to
backport this patch once it is merged.

Thanks
Wei.

On Tue, Nov 08, 2016 at 11:59:46AM -0800, Stefano Stabellini wrote:
> The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e:
> 
>   Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into 
> staging (2016-11-07 14:02:15 +)
> 
> are available in the git repository at:
> 
> 
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161108-tag
> 
> for you to fetch changes up to 804ba7c10bbc66bb8a8aa73ecc60f620da7423d5:
> 
>   xen: Fix xenpv machine initialisation (2016-11-08 11:17:30 -0800)
> 
> 
> Xen 2016/11/08
> 
> 
> Anthony PERARD (1):
>   xen: Fix xenpv machine initialisation
> 
>  xen-common.c | 6 --
>  xen-hvm.c| 4 
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 

Re: [Qemu-devel] [qemu patch V2 2/2] kvmclock: reduce kvmclock difference on migration

[Paolo Bonzini]

On 17/11/2016 15:11, Eduardo Habkost wrote:
> On Thu, Nov 17, 2016 at 11:24:13AM -0200, Marcelo Tosatti wrote:
>> Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
>> indicates that KVM_GET_CLOCK returns a value as seen by the guest at
>> that moment.
>>
>> For new machine types, use this value rather than reading 
>> from guest memory.
>>
>> This reduces kvmclock difference on migration from 5s to 0.1s
>> (when max_downtime == 5s).
>>
>> Signed-off-by: Marcelo Tosatti 
>>
>> ---
>>  hw/i386/kvm/clock.c|  108 
>> ++---
>>  include/hw/i386/pc.h   |5 ++
>>  target-i386/kvm.c  |7 +++
>>  target-i386/kvm_i386.h |1 
>>  4 files changed, 107 insertions(+), 14 deletions(-)
>>
>> v2: 
>> - improve variable names (Juan)
>> - consolidate code on kvm_get_clock function (Paolo)
>> - return mach_use_reliable_get_clock from needed function (Paolo)
>>
>> Index: qemu-mig-advance-clock/hw/i386/kvm/clock.c
>> ===
>> --- qemu-mig-advance-clock.orig/hw/i386/kvm/clock.c  2016-11-14 
>> 10:40:39.748116312 -0200
>> +++ qemu-mig-advance-clock/hw/i386/kvm/clock.c   2016-11-14 
>> 13:38:29.299955042 -0200
>> @@ -36,6 +36,12 @@
>>  
>>  uint64_t clock;
>>  bool clock_valid;
>> +
>> +/* whether machine supports reliable KVM_GET_CLOCK */
>> +bool mach_use_reliable_get_clock;
>> +
>> +/* whether source host supported reliable KVM_GET_CLOCK */
>> +bool src_use_reliable_get_clock;
>>  } KVMClockState;
>>  
>>  struct pvclock_vcpu_time_info {
>> @@ -81,6 +87,19 @@
>>  return nsec + time.system_time;
>>  }
>>  
>> +static uint64_t kvm_get_clock(void)
>> +{
>> +struct kvm_clock_data data;
>> +int ret;
>> +
>> +ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
>> +if (ret < 0) {
>> +fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
>> +abort();
>> +}
>> +return data.clock;
>> +}
>> +
>>  static void kvmclock_vm_state_change(void *opaque, int running,
>>   RunState state)
>>  {
>> @@ -91,15 +110,37 @@
>>  
>>  if (running) {
>>  struct kvm_clock_data data = {};
>> -uint64_t time_at_migration = kvmclock_current_nsec(s);
>> +uint64_t pvclock_via_mem = 0;
>>  
>> -s->clock_valid = false;
>> +/* local (running VM) restore */
>> +if (s->clock_valid) {
>> +/*
>> + * if host does not support reliable KVM_GET_CLOCK,
>> + * read kvmclock value from memory
>> + */
>> +if (!kvm_has_adjust_clock_stable()) {
>> +pvclock_via_mem = kvmclock_current_nsec(s);
>> +}
>> +/* migration/savevm/init restore */
>> +} else {
>> +/*
>> + * use s->clock in case machine uses reliable
>> + * get clock and source host supported
>> + * reliable get clock
>> + */
>> +if (!(s->mach_use_reliable_get_clock &&
>> +  s->src_use_reliable_get_clock)) {
>> +pvclock_via_mem = kvmclock_current_nsec(s);
>> +}
> 
> The s->mach_use_reliable_get_clock check seems redundant.
> src_use_reliable_get_clock is set only if
> mach_use_reliable_get_clock is true.
> 
>> +}
>>  
>> -/* We can't rely on the migrated clock value, just discard it */
>> -if (time_at_migration) {
>> -s->clock = time_at_migration;
>> +/* We can't rely on the saved clock value, just discard it */
>> +if (pvclock_via_mem) {
>> +s->clock = pvclock_via_mem;
>>  }
>>  
>> +s->clock_valid = false;
>> +
>>  data.clock = s->clock;
>>  ret = kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
>>  if (ret < 0) {
>> @@ -120,8 +161,6 @@
>>  }
>>  }
>>  } else {
>> -struct kvm_clock_data data;
>> -int ret;
>>  
>>  if (s->clock_valid) {
>>  return;
>> @@ -129,13 +168,7 @@
>>  
>>  kvm_synchronize_all_tsc();
>>  
>> -ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
>> -if (ret < 0) {
>> -fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
>> -abort();
>> -}
>> -s->clock = data.clock;
>> -
>> +s->clock = kvm_get_clock();
>>  /*
>>   * If the VM is stopped, declare the clock state valid to
>>   * avoid re-reading it on next vmsave (which would return
>> @@ -152,22 +185,69 @@
>>  qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
>>  }
>>  
>> +static bool kvmclock_src_use_reliable_get_clock(void *opaque)
>> +{
>> +KVMClockState *s = opaque;
>> +
>> +/*
>> + * On machine types that support reliable KVM_GET_CLOCK,
>> + * if host kernel does provide reliable KVM_GET_CLOCK,
>> + * set src_use_relia

Re: [Qemu-devel] [qemu patch V2 2/2] kvmclock: reduce kvmclock difference on migration

[Eduardo Habkost]

On Thu, Nov 17, 2016 at 11:24:13AM -0200, Marcelo Tosatti wrote:
> Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
> indicates that KVM_GET_CLOCK returns a value as seen by the guest at
> that moment.
> 
> For new machine types, use this value rather than reading 
> from guest memory.
> 
> This reduces kvmclock difference on migration from 5s to 0.1s
> (when max_downtime == 5s).
> 
> Signed-off-by: Marcelo Tosatti 
> 
> ---
>  hw/i386/kvm/clock.c|  108 
> ++---
>  include/hw/i386/pc.h   |5 ++
>  target-i386/kvm.c  |7 +++
>  target-i386/kvm_i386.h |1 
>  4 files changed, 107 insertions(+), 14 deletions(-)
> 
> v2: 
> - improve variable names (Juan)
> - consolidate code on kvm_get_clock function (Paolo)
> - return mach_use_reliable_get_clock from needed function (Paolo)
> 
> Index: qemu-mig-advance-clock/hw/i386/kvm/clock.c
> ===
> --- qemu-mig-advance-clock.orig/hw/i386/kvm/clock.c   2016-11-14 
> 10:40:39.748116312 -0200
> +++ qemu-mig-advance-clock/hw/i386/kvm/clock.c2016-11-14 
> 13:38:29.299955042 -0200
> @@ -36,6 +36,12 @@
>  
>  uint64_t clock;
>  bool clock_valid;
> +
> +/* whether machine supports reliable KVM_GET_CLOCK */
> +bool mach_use_reliable_get_clock;
> +
> +/* whether source host supported reliable KVM_GET_CLOCK */
> +bool src_use_reliable_get_clock;
>  } KVMClockState;
>  
>  struct pvclock_vcpu_time_info {
> @@ -81,6 +87,19 @@
>  return nsec + time.system_time;
>  }
>  
> +static uint64_t kvm_get_clock(void)
> +{
> +struct kvm_clock_data data;
> +int ret;
> +
> +ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
> +if (ret < 0) {
> +fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
> +abort();
> +}
> +return data.clock;
> +}
> +
>  static void kvmclock_vm_state_change(void *opaque, int running,
>   RunState state)
>  {
> @@ -91,15 +110,37 @@
>  
>  if (running) {
>  struct kvm_clock_data data = {};
> -uint64_t time_at_migration = kvmclock_current_nsec(s);
> +uint64_t pvclock_via_mem = 0;
>  
> -s->clock_valid = false;
> +/* local (running VM) restore */
> +if (s->clock_valid) {
> +/*
> + * if host does not support reliable KVM_GET_CLOCK,
> + * read kvmclock value from memory
> + */
> +if (!kvm_has_adjust_clock_stable()) {
> +pvclock_via_mem = kvmclock_current_nsec(s);
> +}
> +/* migration/savevm/init restore */
> +} else {
> +/*
> + * use s->clock in case machine uses reliable
> + * get clock and source host supported
> + * reliable get clock
> + */
> +if (!(s->mach_use_reliable_get_clock &&
> +  s->src_use_reliable_get_clock)) {
> +pvclock_via_mem = kvmclock_current_nsec(s);
> +}

The s->mach_use_reliable_get_clock check seems redundant.
src_use_reliable_get_clock is set only if
mach_use_reliable_get_clock is true.

> +}
>  
> -/* We can't rely on the migrated clock value, just discard it */
> -if (time_at_migration) {
> -s->clock = time_at_migration;
> +/* We can't rely on the saved clock value, just discard it */
> +if (pvclock_via_mem) {
> +s->clock = pvclock_via_mem;
>  }
>  
> +s->clock_valid = false;
> +
>  data.clock = s->clock;
>  ret = kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
>  if (ret < 0) {
> @@ -120,8 +161,6 @@
>  }
>  }
>  } else {
> -struct kvm_clock_data data;
> -int ret;
>  
>  if (s->clock_valid) {
>  return;
> @@ -129,13 +168,7 @@
>  
>  kvm_synchronize_all_tsc();
>  
> -ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data);
> -if (ret < 0) {
> -fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret));
> -abort();
> -}
> -s->clock = data.clock;
> -
> +s->clock = kvm_get_clock();
>  /*
>   * If the VM is stopped, declare the clock state valid to
>   * avoid re-reading it on next vmsave (which would return
> @@ -152,22 +185,69 @@
>  qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
>  }
>  
> +static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> +{
> +KVMClockState *s = opaque;
> +
> +/*
> + * On machine types that support reliable KVM_GET_CLOCK,
> + * if host kernel does provide reliable KVM_GET_CLOCK,
> + * set src_use_reliable_get_clock=true so that destination
> + * avoids reading kvmclock from memory.
> + */
> +if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable()) {
> +s->src_

Re: [Qemu-devel] [PATCH v2 0/4] aio: experimental virtio-blk polling mode

[Karl Rister]

I think these results look a bit more in line with expectations on the
quick sniff test:

QEMU_AIO_POLL_MAX_NS  IOPs
   unset26,299
   125,929
   225,753
   427,214
   827,053
  1626,861
  3224,752
  6425,058
 12824,732
 25625,560
 51224,614
   1,02425,186
   2,04825,829
   4,09625,671
   8,19227,896
  16,38438,086
  32,76835,493
  65,53638,496
 131,07238,296

I did a spot check of CPU utilization when the polling started having
benefits.

Without polling (QEMU_AIO_POLL_MAX_NS=unset) the iothread's CPU usage
looked like this:

user time:   25.94%
system time: 22.11%

With polling and QEMU_AIO_POLL_MAX_NS=16384 the iothread's CPU usage
looked like this:

user time:   78.92%
system time: 20.80%

Karl

On 11/16/2016 11:46 AM, Stefan Hajnoczi wrote:
> v2:
>  * Uninitialized node->deleted gone [Fam]
>  * Removed 1024 polling loop iteration qemu_clock_get_ns() optimization which
>created a weird step pattern [Fam]
>  * Unified with AioHandler, dropped AioPollHandler struct [Paolo]
>(actually I think Paolo had more in mind but this is the first step)
>  * Only poll when all event loop resources support it [Paolo]
>  * Added run_poll_handlers_begin/end trace events for perf analysis
>  * Sorry, Christian, no virtqueue kick suppression yet
> 
> Recent performance investigation work done by Karl Rister shows that the
> guest->host notification takes around 20 us.  This is more than the "overhead"
> of QEMU itself (e.g. block layer).
> 
> One way to avoid the costly exit is to use polling instead of notification.
> The main drawback of polling is that it consumes CPU resources.  In order to
> benefit performance the host must have extra CPU cycles available on physical
> CPUs that aren't used by the guest.
> 
> This is an experimental AioContext polling implementation.  It adds a polling
> callback into the event loop.  Polling functions are implemented for 
> virtio-blk
> virtqueue guest->host kick and Linux AIO completion.
> 
> The QEMU_AIO_POLL_MAX_NS environment variable sets the number of nanoseconds 
> to
> poll before entering the usual blocking poll(2) syscall.  Try setting this
> variable to the time from old request completion to new virtqueue kick.
> 
> By default no polling is done.  The QEMU_AIO_POLL_MAX_NS must be set to get 
> any
> polling!
> 
> Stefan Hajnoczi (4):
>   aio: add AioPollFn and io_poll() interface
>   aio: add polling mode to AioContext
>   virtio: poll virtqueues for new buffers
>   linux-aio: poll ring for completions
> 
>  aio-posix.c | 115 
> ++--
>  async.c |  14 +-
>  block/curl.c|   8 +--
>  block/iscsi.c   |   3 +-
>  block/linux-aio.c   |  19 +++-
>  block/nbd-client.c  |   8 +--
>  block/nfs.c |   7 +--
>  block/sheepdog.c|  26 +-
>  block/ssh.c |   4 +-
>  block/win32-aio.c   |   4 +-
>  hw/virtio/virtio.c  |  18 ++-
>  include/block/aio.h |   8 ++-
>  iohandler.c |   2 +-
>  nbd/server.c|   9 ++--
>  stubs/set-fd-handler.c  |   1 +
>  tests/test-aio.c|   4 +-
>  trace-events|   4 ++
>  util/event_notifier-posix.c |   2 +-
>  18 files changed, 207 insertions(+), 49 deletions(-)
> 


-- 
Karl Rister 

Re: [Qemu-devel] [PULL v2 00/34] virtio, vhost, pc, pci: tests, documentation, fixes and cleanups

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PULL v2 00/34] virtio, vhost, pc, pci: tests, 
documentation, fixes and cleanups
Type: series
Message-id: 1478887767-31980-1-git-send-email-...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
45f34d2 docs: add PCIe devices placement guidelines
df1e6a9 virtio: drop virtio_queue_get_ring_{size, addr}()
eb0df16 vhost: drop legacy vring layout bits
818af64 vhost: adapt vhost_verify_ring_mappings() to virtio 1 ring layout
308b194 nvdimm acpi: introduce NVDIMM_DSM_MEMORY_SIZE
5ac8f61 nvdimm acpi: use aml_name_decl to define named object
b603da1 nvdimm acpi: rename nvdimm_dsm_reserved_root
7ce6581 nvdimm acpi: fix two comments
d99e1c8 nvdimm acpi: define DSM return codes
ef66dc6 nvdimm acpi: rename nvdimm_acpi_hotplug
09f6d99 nvdimm acpi: cleanup nvdimm_build_fit
c0a7b88 nvdimm acpi: rename nvdimm_plugged_device_list
814cf09 docs: improve the doc of Read FIT method
bfeb57f nvdimm acpi: clean up nvdimm_build_acpi
68edcd7 pc: memhp: stop handling nvdimm hotplug in pc_dimm_unplug
5263390 pc: memhp: move nvdimm hotplug out of memory hotplug
e7941d1 nvdimm acpi: drop the lock of fit buffer
32f27c8 qdev: hotplug: drop HotplugHandler.post_plug callback
1e6d47a vhost: migration blocker only if shared log is used
1420f16 virtio-net: mark VIRTIO_NET_F_GSO as legacy
b7f1187 virtio: allow per-device-class legacy features
618ddad acpi: fix DMAR device scope for IOAPIC
9a7a369 intel_iommu: fix incorrect assert
5afe773 intel_iommu: fix several incorrect endianess and bit fields
3996250 virtio-crypto: tag as not hotpluggable and migration
5fef2e2 virtio: make virtqueue_alloc_element static
729797a virtio: rename virtqueue_discard to virtqueue_unpop
02b2113 intel_iommu: fixing source id during IOTLB hash key calculation
19767b7 tests/vhost-user-bridge: use contrib/libvhost-user
c191724 contrib: add libvhost-user
fb24b50 tests/vhost-user-bridge: do not accept more than one connection
4669d69 tests/vhost-user-bridge: indicate peer disconnected
437db77 tests/vhost-user-bridge: remove unnecessary dispatcher_remove
5cb40ef tests/vhost-user-bridge: remove false comment

=== OUTPUT BEGIN ===
Checking PATCH 1/34: tests/vhost-user-bridge: remove false comment...
Checking PATCH 2/34: tests/vhost-user-bridge: remove unnecessary 
dispatcher_remove...
Checking PATCH 3/34: tests/vhost-user-bridge: indicate peer disconnected...
Checking PATCH 4/34: tests/vhost-user-bridge: do not accept more than one 
connection...
Checking PATCH 5/34: contrib: add libvhost-user...
ERROR: Invalid UTF-8, patch and commit message should be encoded in UTF-8
#75: FILE: contrib/libvhost-user/libvhost-user.c:9:
+ *  Marc-Andr Lureau 
  ^

ERROR: Invalid UTF-8, patch and commit message should be encoded in UTF-8
#1579: FILE: contrib/libvhost-user/libvhost-user.h:8:
+ *  Marc-Andr Lureau 
  ^

total: 2 errors, 0 warnings, 1950 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 6/34: tests/vhost-user-bridge: use contrib/libvhost-user...
Checking PATCH 7/34: intel_iommu: fixing source id during IOTLB hash key 
calculation...
Checking PATCH 8/34: virtio: rename virtqueue_discard to virtqueue_unpop...
Checking PATCH 9/34: virtio: make virtqueue_alloc_element static...
WARNING: line over 80 characters
#24: FILE: hw/virtio/virtio.c:635:
+static void *virtqueue_alloc_element(size_t sz, unsigned out_num, unsigned 
in_num)

total: 0 errors, 1 warnings, 15 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 10/34: virtio-crypto: tag as not hotpluggable and migration...
Checking PATCH 11/34: intel_iommu: fix several incorrect endianess and bit 
fields...
Checking PATCH 12/34: intel_iommu: fix incorrect assert...
Checking PATCH 13/34: acpi: fix DMAR device scope for IOAPIC...
Checking PATCH 14/34: virtio: allow per-device-class legacy features...
Checking PATCH 15/34: virtio-net: mark VIRTIO_NET_F_GSO as legacy...
Checking PATCH 16/34: vhost: migration blocker only if shared log is used...
Checking PATCH 17/34: qdev: hotplug: drop HotplugHandler.post_plug callback...
Checking PATCH 18/34: nvdimm acpi: drop the lock of fit

Re: [Qemu-devel] [PATCH] trace: fix generated code build break

[Fam Zheng]

On Thu, 11/17 14:59, Greg Kurz wrote:
> If the QEMU source dir is
> 
> /var/tmp/aaa-qemu-clone
> 
> and the build dir is
> 
> /var/tmp/qemu-aio-poll-v2
> 
> Then I get an error as:
> 
> trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events"
>  on integer constant
>  TraceEvent *2_trace_events[] = {
>  ^
> trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ before
>  numeric constant
> trace/generated-tracers.c: In function ‘trace_2_register_events’:
> trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" on
>  integer constant
>  trace_event_register_group(2_trace_events);
> ^
> make: *** [trace/generated-tracers.o] Error 1
> 
> This patch fixes the issue.
> 
> Reported-by: Fam Zheng 
> Signed-off-by: Greg Kurz 
> ---
>  scripts/tracetool.py |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/tracetool.py b/scripts/tracetool.py
> index fe9c9e904b03..c9e47371d3c6 100755
> --- a/scripts/tracetool.py
> +++ b/scripts/tracetool.py
> @@ -70,7 +70,7 @@ def make_group_name(filename):
>  
>  if dirname == "":
>  return "common"
> -return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> +return "_" + re.sub(r"[^A-Za-z0-9]", "_", dirname)
>  
>  def main(args):
>  global _SCRIPT
> 
> 

What make_group_name does here (returning substring of build dir based on source
dir) doesn't make sense to me at all, maybe it's because the patchset Dan is
working on was only partly merged.  But as a bandage for 2.8, it makes things
better on top of the previous attemp 630b210b9 'Fix build for less common build
directories names'. Thanks!

Tested-by: Fam Zheng 

Re: [Qemu-devel] [RFC PATCH 5/8] quorum: Inline quorum_aio_cb()

[Alberto Garcia]

On Thu 10 Nov 2016 06:19:06 PM CET, Kevin Wolf wrote:
> This is a conversion to a more natural coroutine style and improves the
> readability of the driver.
>
> Signed-off-by: Kevin Wolf 

With this patch read_quorum_children_entry() and write_quorum_entry()
become identical (except for bdrv_co_{preadv,pwritev} of course), so
maybe we can factor them out.

But that can be left for a separate patch.

Reviewed-by: Alberto Garcia 

Berto

Re: [Qemu-devel] [PATCH] trace: fix generated code build break

[Daniel P. Berrange]

On Thu, Nov 17, 2016 at 10:22:00PM +0800, Fam Zheng wrote:
> On Thu, 11/17 14:59, Greg Kurz wrote:
> > If the QEMU source dir is
> > 
> > /var/tmp/aaa-qemu-clone
> > 
> > and the build dir is
> > 
> > /var/tmp/qemu-aio-poll-v2
> > 
> > Then I get an error as:
> > 
> > trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events"
> >  on integer constant
> >  TraceEvent *2_trace_events[] = {
> >  ^
> > trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ before
> >  numeric constant
> > trace/generated-tracers.c: In function ‘trace_2_register_events’:
> > trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" on
> >  integer constant
> >  trace_event_register_group(2_trace_events);
> > ^
> > make: *** [trace/generated-tracers.o] Error 1
> > 
> > This patch fixes the issue.
> > 
> > Reported-by: Fam Zheng 
> > Signed-off-by: Greg Kurz 
> > ---
> >  scripts/tracetool.py |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/scripts/tracetool.py b/scripts/tracetool.py
> > index fe9c9e904b03..c9e47371d3c6 100755
> > --- a/scripts/tracetool.py
> > +++ b/scripts/tracetool.py
> > @@ -70,7 +70,7 @@ def make_group_name(filename):
> >  
> >  if dirname == "":
> >  return "common"
> > -return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> > +return "_" + re.sub(r"[^A-Za-z0-9]", "_", dirname)
> >  
> >  def main(args):
> >  global _SCRIPT
> > 
> > 
> 
> What make_group_name does here (returning substring of build dir based on 
> source
> dir) doesn't make sense to me at all, maybe it's because the patchset Dan is
> working on was only partly merged.  But as a bandage for 2.8, it makes things
> better on top of the previous attemp 630b210b9 'Fix build for less common 
> build
> directories names'. Thanks!

As a quick hack for 2.8 this is fine by me. We can trivially revert it
after merging the rest of the patches in 2.9 if needed.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

[Qemu-devel] [PATCH] ppc: BOOK3E: nothing should be done when MSR:PR is set

[Vladimir Svoboda]

The server architecture (BOOK3S) specifies that any instruction that
sets MSR:PR will also set MSR:EE, IR and DR.
However there is no such behavior specification for the embedded
architecture (BOOK3E).

Signed-off-by: Vladimir Svoboda 
---
 target-ppc/helper_regs.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/target-ppc/helper_regs.h b/target-ppc/helper_regs.h
index bb9ce60..6213816 100644
--- a/target-ppc/helper_regs.h
+++ b/target-ppc/helper_regs.h
@@ -131,11 +131,14 @@ static inline int hreg_store_msr(CPUPPCState *env, 
target_ulong value,
 }
 /* If PR=1 then EE, IR and DR must be 1
  *
- * Note: We only enforce this on 64-bit processors. It appears that
- * 32-bit implementations supports PR=1 and EE/DR/IR=0 and MacOS
- * exploits it.
+ * Note: We only enforce this on 64-bit server processors.
+ * It appears that:
+ * - 32-bit implementations supports PR=1 and EE/DR/IR=0 and MacOS
+ *   exploits it.
+ * - 64-bit embedded implementations do not need any operation to be
+ *   performed when PR is set.
  */
-if ((env->insns_flags & PPC_64B) && ((value >> MSR_PR) & 1)) {
+if ((env->insns_flags & PPC_SEGMENT_64B) && ((value >> MSR_PR) & 1)) {
 value |= (1 << MSR_EE) | (1 << MSR_DR) | (1 << MSR_IR);
 }
 #endif
-- 
2.10.2

[Qemu-devel] [Bug 1642421] [NEW] qemu-system-x86_64: ipv6 and dns is broken with netdev user

[manut]

Public bug reported:

Hi,

dhcp inside qemu returns an ipv6 address as dns-server. However this is not
working. If i replace it with the ipv4 address '10.0.0.2' dns is working
again. I would expect that the qemu emulated dhcp server responds either an
ipv4 configuration that is working or its dns server/forwarder listens on the
ipv6 address returned by the emulated dhcp server.

I used latest qemu from git ( b0bcc86d2a87456f5a276f941dc775b265b309cf)
and used the following commands:

$ ./qemu-system-x86_64 -enable-kvm -M pc -device virtio-rng-pci -device
virtio-net-pci,netdev=user.0 -drive file=buildenv.img,if=virtio,bus=1,unit=0
-no-reboot -netdev user,id=user.0,hostfwd=tcp::5022-:22,hostfwd=tcp::7587-:7588
-m 1024 -usb -nographic -smp 4

buildenv.img is a debian jessie amd64 installation.

Inside qemu the network is configured to use dhcp:

$ cat /etc/network/interfaces
allow-hotplug eth0
iface eth0 inet dhcp

$ ifconfig eth0
eth0  Link encap:Ethernet  HWaddr 52:54:00:12:34:56
  inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
  inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link
  inet6 addr: fec0::5054:ff:fe12:3456/64 Scope:Site
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:10 errors:0 dropped:0 overruns:0 frame:0
  TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3215 (3.1 KiB)  TX bytes:3638 (3.5 KiB)

$ cat /etc/resolv.conf
nameserver fec0::3

$ arp google.de
google.de: Host name lookup failure

$ strace -f arp google.de
...
socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, 
"fec0::3", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)= 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, 
MSG_NOSIGNAL, NULL, 0) = 27
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 0)= 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, 
MSG_NOSIGNAL, NULL, 0) = 27
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
close(4)= 0
...

$ echo nameserver 10.0.0.2 > /etc/resolv.conf

$ arp google.de
google.de (216.58.208.35) -- no entry

Note: I reported this bug also to debian: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=844566

Regards,

  Manuel

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu-system-x86_64: ipv6 and dns is broken with netdev user

Status in QEMU:
  New

Bug description:
  Hi,

  dhcp inside qemu returns an ipv6 address as dns-server. However this is not
  working. If i replace it with the ipv4 address '10.0.0.2' dns is working
  again. I would expect that the qemu emulated dhcp server responds either an
  ipv4 configuration that is working or its dns server/forwarder listens on the
  ipv6 address returned by the emulated dhcp server.

  I used latest qemu from git (
  b0bcc86d2a87456f5a276f941dc775b265b309cf) and used the following
  commands:

  $ ./qemu-system-x86_64 -enable-kvm -M pc -device virtio-rng-pci -device
  virtio-net-pci,netdev=user.0 -drive file=buildenv.img,if=virtio,bus=1,unit=0
  -no-reboot -netdev 
user,id=user.0,hostfwd=tcp::5022-:22,hostfwd=tcp::7587-:7588
  -m 1024 -usb -nographic -smp 4

  buildenv.img is a debian jessie amd64 installation.

  Inside qemu the network is configured to use dhcp:

  $ cat /etc/network/interfaces
  allow-hotplug eth0
  iface eth0 inet dhcp

  $ ifconfig eth0
  eth0  Link encap:Ethernet  HWaddr 52:54:00:12:34:56
inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link
inet6 addr: fec0::5054:ff:fe12:3456/64 Scope:Site
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3215 (3.1 KiB)  TX bytes:3638 (3.5 KiB)

  $ cat /etc/resolv.conf
  nameserver fec0::3

  $ arp google.de
  google.de: Host name lookup failure

  $ strace -f arp google.de
  ...
  socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
  connect(4, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, 
"fec0::3", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
  poll([{fd=4, events=POLLOUT}], 1, 0)= 1 ([{fd=4, revents=POLLOUT}])
  sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, 
MSG_NOSIGNAL, NULL, 0) = 27
  poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
  poll([{fd=4, events=POLLOUT}], 1, 0)= 1 ([{fd=4, revents=POLLOUT}])
  sendt

[Qemu-devel] [PATCH 0/4] Add support for the Epson RX8900 RTC to the aspeed board

[Alastair D'Silva]

From: Alastair D'Silva 

This patch series adds support for the Epson RX8900 RTC to the
Aspeed board.

The tests use the existing imx25 infrastructure, and some minor
changes have been made to uniquely identify the I2C buses.

Support for named interrupts has been implemented in qtest to
facilitate testing.

Alastair D'Silva (4):
  arm: Uniquely name imx25 I2C buses.
  qtest: Support named interrupts
  hw/timer: Add Epson RX8900 RTC support
  arm: Add an RX8900 RTC to the ASpeed board

 default-configs/arm-softmmu.mak |   1 +
 hw/arm/aspeed.c |   8 +
 hw/arm/imx25_pdk.c  |   2 +-
 hw/i2c/imx_i2c.c|   6 +-
 hw/timer/Makefile.objs  |   2 +
 hw/timer/rx8900.c   | 891 
 hw/timer/rx8900_regs.h  | 125 ++
 qtest.c |  98 +++--
 tests/Makefile.include  |   2 +
 tests/libqtest.c|  87 +++-
 tests/libqtest.h|  59 +++
 tests/rx8900-test.c | 800 
 12 files changed, 2051 insertions(+), 30 deletions(-)
 create mode 100644 hw/timer/rx8900.c
 create mode 100644 hw/timer/rx8900_regs.h
 create mode 100644 tests/rx8900-test.c

-- 
2.7.4

[Qemu-devel] [PATCH 1/4] arm: Uniquely name imx25 I2C buses.

[Alastair D'Silva]

From: Alastair D'Silva 

The imx25 chip provides 3 i2c buses, but they have all been named
"i2c", which makes it difficult to predict which bus a device will
be connected to when specified on the command line.

This patch addresses the issue by naming the buses uniquely:
  i2c.0 i2c.1 i2c.2

Signed-off-by: Alastair D'Silva 
---
 hw/arm/imx25_pdk.c | 2 +-
 hw/i2c/imx_i2c.c   | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/arm/imx25_pdk.c b/hw/arm/imx25_pdk.c
index 025b608..1f7512c 100644
--- a/hw/arm/imx25_pdk.c
+++ b/hw/arm/imx25_pdk.c
@@ -139,7 +139,7 @@ static void imx25_pdk_init(MachineState *machine)
  * of simple qtest. See "make check" for details.
  */
 i2c_create_slave((I2CBus *)qdev_get_child_bus(DEVICE(&s->soc.i2c[0]),
-  "i2c"),
+  "i2c.0"),
  "ds1338", 0x68);
 }
 }
diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
index 37e5a62..7be10fb 100644
--- a/hw/i2c/imx_i2c.c
+++ b/hw/i2c/imx_i2c.c
@@ -305,12 +305,16 @@ static const VMStateDescription imx_i2c_vmstate = {
 static void imx_i2c_realize(DeviceState *dev, Error **errp)
 {
 IMXI2CState *s = IMX_I2C(dev);
+static int bus_count;
+char name[16];
+
+snprintf(name, sizeof(name), "i2c.%d", bus_count++);
 
 memory_region_init_io(&s->iomem, OBJECT(s), &imx_i2c_ops, s, TYPE_IMX_I2C,
   IMX_I2C_MEM_SIZE);
 sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->iomem);
 sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
-s->bus = i2c_init_bus(DEVICE(dev), "i2c");
+s->bus = i2c_init_bus(DEVICE(dev), name);
 }
 
 static void imx_i2c_class_init(ObjectClass *klass, void *data)
-- 
2.7.4

Re: [Qemu-devel] [PATCH] tftp: fake support for netascii protocol

[Vincent Bernat]

 ❦ 17 novembre 2016 13:20 +0100, Vincent Bernat  :

> Some network equipments are requesting a file using the netascii
> protocol and this is not configurable. Currently, qemu's tftpd only
> supports the octet protocol. This commit makes it accept the netascii
> protocol as well but do not perform the requested transformation (LF ->
> CR,LF) as it would be far more complex. The current implementation is
> good enough. A user has always the choice to preencode the served file
> correctly.

Signed-off-by: Vincent Bernat 

(forgot to do that in the original patch)
-- 
Vincent Bernat — vincent.ber...@exoscale.ch
❬❱ https://www.exoscale.ch

[Qemu-devel] [PATCH 3/4] hw/timer: Add Epson RX8900 RTC support

[Alastair D'Silva]

From: Alastair D'Silva 

This patch adds support for the Epson RX8900 RTC chip.

Signed-off-by: Alastair D'Silva 
---
 default-configs/arm-softmmu.mak |   1 +
 hw/timer/Makefile.objs  |   2 +
 hw/timer/rx8900.c   | 891 
 hw/timer/rx8900_regs.h  | 125 ++
 tests/Makefile.include  |   2 +
 tests/rx8900-test.c | 800 
 6 files changed, 1821 insertions(+)
 create mode 100644 hw/timer/rx8900.c
 create mode 100644 hw/timer/rx8900_regs.h
 create mode 100644 tests/rx8900-test.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 6de3e16..adb600e 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -29,6 +29,7 @@ CONFIG_SMC91C111=y
 CONFIG_ALLWINNER_EMAC=y
 CONFIG_IMX_FEC=y
 CONFIG_DS1338=y
+CONFIG_RX8900=y
 CONFIG_PFLASH_CFI01=y
 CONFIG_PFLASH_CFI02=y
 CONFIG_MICRODRIVE=y
diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index 7ba8c23..fa028ac 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -3,6 +3,7 @@ common-obj-$(CONFIG_ARM_MPTIMER) += arm_mptimer.o
 common-obj-$(CONFIG_A9_GTIMER) += a9gtimer.o
 common-obj-$(CONFIG_CADENCE) += cadence_ttc.o
 common-obj-$(CONFIG_DS1338) += ds1338.o
+common-obj-$(CONFIG_RX8900) += rx8900.o
 common-obj-$(CONFIG_HPET) += hpet.o
 common-obj-$(CONFIG_I8254) += i8254_common.o i8254.o
 common-obj-$(CONFIG_M48T59) += m48t59.o
@@ -17,6 +18,7 @@ common-obj-$(CONFIG_IMX) += imx_epit.o
 common-obj-$(CONFIG_IMX) += imx_gpt.o
 common-obj-$(CONFIG_LM32) += lm32_timer.o
 common-obj-$(CONFIG_MILKYMIST) += milkymist-sysctl.o
+common-obj-$(CONFIG_RX8900) += rx8900.o
 
 obj-$(CONFIG_EXYNOS4) += exynos4210_mct.o
 obj-$(CONFIG_EXYNOS4) += exynos4210_pwm.o
diff --git a/hw/timer/rx8900.c b/hw/timer/rx8900.c
new file mode 100644
index 000..208a31b
--- /dev/null
+++ b/hw/timer/rx8900.c
@@ -0,0 +1,891 @@
+/*
+ * Epson RX8900SA/CE Realtime Clock Module
+ *
+ * Copyright (c) 2016 IBM Corporation
+ * Authors:
+ *  Alastair D'Silva 
+ *
+ * This code is licensed under the GPL version 2 or later.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Datasheet available at:
+ *  https://support.epson.biz/td/api/doc_check.php?dl=app_RX8900CE&lang=en
+ *
+ * Not implemented:
+ *  Implement Timer Counters
+ *  Implement i2c timeout
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "hw/i2c/i2c.h"
+#include "hw/timer/rx8900_regs.h"
+#include "hw/ptimer.h"
+#include "qemu/main-loop.h"
+#include "qemu/bcd.h"
+#include "qemu/error-report.h"
+#include "qemu/log.h"
+#include "qapi/error.h"
+#include "qapi/visitor.h"
+
+ #include 
+
+ #include 
+
+#define TYPE_RX8900 "rx8900"
+#define RX8900(obj) OBJECT_CHECK(RX8900State, (obj), TYPE_RX8900)
+
+static bool log;
+
+typedef struct RX8900State {
+I2CSlave parent_obj;
+
+ptimer_state *sec_timer; /* triggered once per second */
+ptimer_state *fout_timer;
+ptimer_state *countdown_timer;
+bool fout;
+int64_t offset;
+uint8_t weekday; /* Saved for deferred offset calculation, 0-6 */
+uint8_t wday_offset;
+uint8_t nvram[RX8900_NVRAM_SIZE];
+int32_t ptr; /* Wrapped to stay within RX8900_NVRAM_SIZE */
+bool addr_byte;
+uint8_t last_interrupt_seconds;
+uint8_t last_update_interrupt_minutes;
+qemu_irq interrupt_pin;
+qemu_irq fout_pin;
+} RX8900State;
+
+static const VMStateDescription vmstate_rx8900 = {
+.name = "rx8900",
+.version_id = 2,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_I2C_SLAVE(parent_obj, RX8900State),
+VMSTATE_PTIMER(sec_timer, RX8900State),
+VMSTATE_PTIMER(fout_timer, RX8900State),
+VMSTATE_PTIMER(countdown_timer, RX8900State),
+VMSTATE_BOOL(fout, RX8900State),
+VMSTATE_INT64(offset, RX8900State),
+VMSTATE_UINT8_V(weekday, RX8900State, 2),
+VMSTATE_UINT8_V(wday_offset, RX8900State, 2),
+VMSTATE_UINT8_ARRAY(nvram, RX8900State, RX8900_NVRAM_SIZE),
+VMSTATE_INT32(ptr, RX8900State),
+VMSTATE_BOOL(addr_byte, RX8900State),
+VMSTATE_UINT8_V(last_interrupt_seconds, RX8900State, 2),
+VMSTATE_UINT8_V(last_update_interrupt_minutes, RX8900State, 2),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static void rx8900_reset(DeviceState *dev);
+static void disable_countdown_timer(RX8900State *s);
+static void enable_countdown_timer(RX8900State *s);
+static void disable_timer(RX8900State *s);
+static void enable_timer(RX8900State *s);
+
+#ifdef RX8900_TRACE
+#define RX8900_TRACE_BUF_SIZE 256
+/**
+ * Emit a trace message
+ * @param file the source filename
+ * @param line the line number the message was emitted from
+ * @param dev the RX8900 device
+ * @param fmt a printf style format
+ */
+static void trace(const char *file, int line, const char *func,
+I2CSlave *dev, const char *fmt, ...)
+{
+va_list ap;
+char buf[RX8900_

[Qemu-devel] [PATCH 2/4] qtest: Support named interrupts

[Alastair D'Silva]

From: Alastair D'Silva 

The QTest framework cannot work with named interrupts. This patch
adds support for them, as well as the ability to manipulate them
from within a test.

Read actions are via callbacks, which allows for pulsed interrupts
to be read (the polled method used for the unnamed interrupts
cannot read pulsed interrupts as the value is reverted before the
test sees the changes).

Signed-off-by: Alastair D'Silva 
---
 qtest.c  | 98 ++--
 tests/libqtest.c | 87 ++---
 tests/libqtest.h | 59 ++
 3 files changed, 216 insertions(+), 28 deletions(-)

diff --git a/qtest.c b/qtest.c
index 46b99ae..a56503b 100644
--- a/qtest.c
+++ b/qtest.c
@@ -40,7 +40,6 @@ static DeviceState *irq_intercept_dev;
 static FILE *qtest_log_fp;
 static CharBackend qtest_chr;
 static GString *inbuf;
-static int irq_levels[MAX_IRQ];
 static qemu_timeval start_time;
 static bool qtest_opened;
 
@@ -160,10 +159,16 @@ static bool qtest_opened;
  *
  *  IRQ raise NUM
  *  IRQ lower NUM
+ *  IRQ_NAMED NAME NUM LEVEL
  *
  * where NUM is an IRQ number.  For the PC, interrupts can be intercepted
  * simply with "irq_intercept_in ioapic" (note that IRQ0 comes out with
  * NUM=0 even though it is remapped to GSI 2).
+ *
+ *  > irq_set NAME NUM LEVEL
+ *  < OK
+ *
+ *  Set the named input IRQ to the level (0/1)
  */
 
 static int hex2nib(char ch)
@@ -243,17 +248,31 @@ static void GCC_FMT_ATTR(2, 3) qtest_sendf(CharBackend 
*chr,
 va_end(ap);
 }
 
+typedef struct qtest_irq {
+qemu_irq old_irq;
+char *name;
+bool last_level;
+} qtest_irq;
+
 static void qtest_irq_handler(void *opaque, int n, int level)
 {
-qemu_irq old_irq = *(qemu_irq *)opaque;
-qemu_set_irq(old_irq, level);
+qtest_irq *data = (qtest_irq *)opaque;
+level = !!level;
+
+qemu_set_irq(data->old_irq, level);
 
-if (irq_levels[n] != level) {
+if (level != data->last_level) {
 CharBackend *chr = &qtest_chr;
-irq_levels[n] = level;
 qtest_send_prefix(chr);
-qtest_sendf(chr, "IRQ %s %d\n",
-level ? "raise" : "lower", n);
+
+if (data->name) {
+qtest_sendf(chr, "IRQ_NAMED %s %d %d\n",
+data->name, n, level);
+} else {
+qtest_sendf(chr, "IRQ %s %d\n", level ? "raise" : "lower", n);
+}
+
+data->last_level = level;
 }
 }
 
@@ -289,7 +308,7 @@ static void qtest_process_command(CharBackend *chr, gchar 
**words)
 if (!dev) {
 qtest_send_prefix(chr);
 qtest_send(chr, "FAIL Unknown device\n");
-   return;
+return;
 }
 
 if (irq_intercept_dev) {
@@ -299,33 +318,69 @@ static void qtest_process_command(CharBackend *chr, gchar 
**words)
 } else {
 qtest_send(chr, "OK\n");
 }
-   return;
+return;
 }
 
 QLIST_FOREACH(ngl, &dev->gpios, node) {
-/* We don't support intercept of named GPIOs yet */
-if (ngl->name) {
-continue;
-}
 if (words[0][14] == 'o') {
 int i;
 for (i = 0; i < ngl->num_out; ++i) {
-qemu_irq *disconnected = g_new0(qemu_irq, 1);
-qemu_irq icpt = qemu_allocate_irq(qtest_irq_handler,
-  disconnected, i);
+qtest_irq *data = g_new0(qtest_irq, 1);
+data->name = ngl->name;
+qemu_irq icpt = qemu_allocate_irq(qtest_irq_handler, data,
+i);
 
-*disconnected = qdev_intercept_gpio_out(dev, icpt,
+data->old_irq = qdev_intercept_gpio_out(dev, icpt,
 ngl->name, i);
 }
 } else {
-qemu_irq_intercept_in(ngl->in, qtest_irq_handler,
-  ngl->num_in);
+qtest_irq *data = g_new0(qtest_irq, 1);
+data->old_irq = *ngl->in;
+data->name = ngl->name;
+qemu_irq_intercept_in(ngl->in, qtest_irq_handler, ngl->num_in);
 }
 }
 irq_intercept_dev = dev;
 qtest_send_prefix(chr);
 qtest_send(chr, "OK\n");
 
+} else if (strcmp(words[0], "irq_set") == 0) {
+DeviceState *dev;
+NamedGPIOList *ngl;
+int level;
+qemu_irq irq = NULL;
+int irq_num;
+
+g_assert(words[1]); /* device */
+g_assert(words[2]); /* gpio list */
+g_assert(words[3]); /* gpio line in list */
+g_assert(words[4]); /* level */
+dev = DEVICE(object_resolve_path(words[1], NULL));
+if (!dev) {
+qtest_send_prefix(chr);
+qtest_send(chr, "FAIL Unkn

[Qemu-devel] [PATCH] tftp: fake support for netascii protocol

[Vincent Bernat]

From: Vincent Bernat 

Some network equipments are requesting a file using the netascii
protocol and this is not configurable. Currently, qemu's tftpd only
supports the octet protocol. This commit makes it accept the netascii
protocol as well but do not perform the requested transformation (LF ->
CR,LF) as it would be far more complex. The current implementation is
good enough. A user has always the choice to preencode the served file
correctly.
---
 slirp/tftp.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/slirp/tftp.c b/slirp/tftp.c
index c1859066ccb2..ab1c05d5d42c 100644
--- a/slirp/tftp.c
+++ b/slirp/tftp.c
@@ -326,13 +326,15 @@ static void tftp_handle_rrq(Slirp *slirp, struct 
sockaddr_storage *srcsas,
 return;
   }
 
-  if (strcasecmp(&tp->x.tp_buf[k], "octet") != 0) {
+  if (strcasecmp(&tp->x.tp_buf[k], "octet") == 0) {
+  k += 6;
+  } else if (strcasecmp(&tp->x.tp_buf[k], "netascii") == 0) {
+  k += 9;
+  } else {
   tftp_send_error(spt, 4, "Unsupported transfer mode", tp);
   return;
   }
 
-  k += 6; /* skipping octet */
-
   /* do sanity checks on the filename */
   if (!strncmp(req_fname, "../", 3) ||
   req_fname[strlen(req_fname) - 1] == '/' ||
-- 
2.10.2

[Qemu-devel] [PATCH 4/4] arm: Add an RX8900 RTC to the ASpeed board

[Alastair D'Silva]

From: Alastair D'Silva 

Connect an RX8900 RTC to i2c12 of the AST2500 SOC at address 0x32

Signed-off-by: Alastair D'Silva 
---
 hw/arm/aspeed.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index c7206fd..554ae20 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -100,6 +100,8 @@ static void aspeed_board_init(MachineState *machine,
 {
 AspeedBoardState *bmc;
 AspeedSoCClass *sc;
+I2CBus *i2c12;
+DeviceState *rx8900;
 
 bmc = g_new0(AspeedBoardState, 1);
 object_initialize(&bmc->soc, (sizeof(bmc->soc)), cfg->soc_name);
@@ -137,6 +139,12 @@ static void aspeed_board_init(MachineState *machine,
 aspeed_board_binfo.ram_size = ram_size;
 aspeed_board_binfo.loader_start = sc->info->sdram_base;
 
+i2c12 = aspeed_i2c_get_bus((DeviceState *)&bmc->soc.i2c, 11);
+rx8900 = i2c_create_slave(i2c12, "rx8900", 0x32);
+
+qdev_connect_gpio_out_named(rx8900, "rx8900-interrupt-out", 0,
+qdev_get_gpio_in(DEVICE(&bmc->soc.vic), 22));
+
 arm_load_kernel(ARM_CPU(first_cpu), &aspeed_board_binfo);
 }
 
-- 
2.7.4

Re: [Qemu-devel] [PATCH 10/25] target-tricore: Use clz opcode

[Bastian Koppelmann]

On 11/16/2016 08:25 PM, Richard Henderson wrote:
> diff --git a/target-tricore/translate.c b/target-tricore/translate.c
> index 36f734a..69cdfb9 100644
> --- a/target-tricore/translate.c
> +++ b/target-tricore/translate.c
> @@ -6367,7 +6367,8 @@ static void decode_rr_logical_shift(CPUTriCoreState 
> *env, DisasContext *ctx)
>  tcg_gen_andc_tl(cpu_gpr_d[r3], cpu_gpr_d[r1], cpu_gpr_d[r2]);
>  break;
>  case OPC2_32_RR_CLO:
> -gen_helper_clo(cpu_gpr_d[r3], cpu_gpr_d[r1]);
> +tcg_gen_not_tl(cpu_gpr_d[r3], cpu_gpr_d[r1]);
> +tcg_gen_clzi_tl(cpu_gpr_d[r3], cpu_gpr_d[r3], TARGET_LONG_BITS);

This doesn't work for r1 = 0. It returns 0x1f, but should return 0. I
guess the error is not here, but I couldn't figure out where exactly it is.

Cheers,
Bastian

Re: [Qemu-devel] [PATCH] trace: fix generated code build break

[Greg Kurz]

On Thu, 17 Nov 2016 22:22:00 +0800
Fam Zheng  wrote:

> On Thu, 11/17 14:59, Greg Kurz wrote:
> > If the QEMU source dir is
> > 
> > /var/tmp/aaa-qemu-clone
> > 
> > and the build dir is
> > 
> > /var/tmp/qemu-aio-poll-v2
> > 
> > Then I get an error as:
> > 
> > trace/generated-tracers.c:15950:13: error: invalid suffix "_trace_events"
> >  on integer constant
> >  TraceEvent *2_trace_events[] = {
> >  ^
> > trace/generated-tracers.c:15950:13: error: expected identifier or ‘(’ before
> >  numeric constant
> > trace/generated-tracers.c: In function ‘trace_2_register_events’:
> > trace/generated-tracers.c:17949:32: error: invalid suffix "_trace_events" on
> >  integer constant
> >  trace_event_register_group(2_trace_events);
> > ^
> > make: *** [trace/generated-tracers.o] Error 1
> > 
> > This patch fixes the issue.
> > 
> > Reported-by: Fam Zheng 
> > Signed-off-by: Greg Kurz 
> > ---
> >  scripts/tracetool.py |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/scripts/tracetool.py b/scripts/tracetool.py
> > index fe9c9e904b03..c9e47371d3c6 100755
> > --- a/scripts/tracetool.py
> > +++ b/scripts/tracetool.py
> > @@ -70,7 +70,7 @@ def make_group_name(filename):
> >  
> >  if dirname == "":
> >  return "common"
> > -return re.sub(r"[^A-Za-z0-9]", "_", dirname)
> > +return "_" + re.sub(r"[^A-Za-z0-9]", "_", dirname)
> >  
> >  def main(args):
> >  global _SCRIPT
> > 
> >   
> 
> What make_group_name does here (returning substring of build dir based on 
> source
> dir) doesn't make sense to me at all, maybe it's because the patchset Dan is
> working on was only partly merged.

This is exactly what's happening, as stated by Dan himself in this message:

<20161018153124.gb15...@redhat.com>

> But as a bandage for 2.8, it makes things
> better on top of the previous attemp 630b210b9 'Fix build for less common 
> build
> directories names'. Thanks!
> 
> Tested-by: Fam Zheng 

Cheers.

--
Greg

Re: [Qemu-devel] [PATCH] ppc: BOOK3E: nothing should be done when MSR:PR is set

[Thomas Huth]

On 17.11.2016 14:49, Vladimir Svoboda wrote:
> The server architecture (BOOK3S) specifies that any instruction that
> sets MSR:PR will also set MSR:EE, IR and DR.
> However there is no such behavior specification for the embedded
> architecture (BOOK3E).
> 
> Signed-off-by: Vladimir Svoboda 
> ---
>  target-ppc/helper_regs.h | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/target-ppc/helper_regs.h b/target-ppc/helper_regs.h
> index bb9ce60..6213816 100644
> --- a/target-ppc/helper_regs.h
> +++ b/target-ppc/helper_regs.h
> @@ -131,11 +131,14 @@ static inline int hreg_store_msr(CPUPPCState *env, 
> target_ulong value,
>  }
>  /* If PR=1 then EE, IR and DR must be 1
>   *
> - * Note: We only enforce this on 64-bit processors. It appears that
> - * 32-bit implementations supports PR=1 and EE/DR/IR=0 and MacOS
> - * exploits it.
> + * Note: We only enforce this on 64-bit server processors.
> + * It appears that:
> + * - 32-bit implementations supports PR=1 and EE/DR/IR=0 and MacOS
> + *   exploits it.
> + * - 64-bit embedded implementations do not need any operation to be
> + *   performed when PR is set.
>   */
> -if ((env->insns_flags & PPC_64B) && ((value >> MSR_PR) & 1)) {
> +if ((env->insns_flags & PPC_SEGMENT_64B) && ((value >> MSR_PR) & 1)) {
>  value |= (1 << MSR_EE) | (1 << MSR_DR) | (1 << MSR_IR);
>  }
>  #endif
> 

Reviewed-by: Thomas Huth 

Re: [Qemu-devel] [PATCH for-2.9 1/2] qom: Remove release function from class properties

[Markus Armbruster]

Eduardo Habkost  writes:

> On Thu, Nov 17, 2016 at 01:33:34PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost  writes:
>> 
>> > The release functions are never called for class properties, and
>> > their semantics aren't even defined clearly (should the release
>> > function be called when an instance is destroyed, or when a class
>> > is destroyed?). Remove the unused functionality.
>> >
>> > Signed-off-by: Eduardo Habkost 
> [...]
>> >  g_hash_table_insert(klass->properties, g_strdup(name), prop);
>> > @@ -1808,7 +1806,6 @@ void object_class_property_add_str(ObjectClass 
>> > *klass, const char *name,
>> >  object_class_property_add(klass, name, "string",
>> >get ? property_get_str : NULL,
>> >set ? property_set_str : NULL,
>> > -  property_release_str,
>> >prop, &local_err);
>> >  if (local_err) {
>> >  error_propagate(errp, local_err);
>> 
>> Here, you drop property_release_str(), which calls g_free().  Assuming
>> you claim that it's never called is correct, this is again no functional
>> change.  But that begs the question why not freeing the stuff
>> property_release_str() frees is correct.  Can you explain?
>
> property_release_str() frees prop. The only right moment to free
> prop is on class destruction or class property removal, but we
> have no mechanisms for class destruction or class property
> removal today.

Would be a nice addition to the commit message.

>> > @@ -1897,7 +1894,6 @@ void object_class_property_add_bool(ObjectClass 
>> > *klass, const char *name,
>> >  object_class_property_add(klass, name, "bool",
>> >get ? property_get_bool : NULL,
>> >set ? property_set_bool : NULL,
>> > -  property_release_bool,
>> >prop, &local_err);
>> >  if (local_err) {
>> >  error_propagate(errp, local_err);
>> > @@ -1985,7 +1981,6 @@ void object_class_property_add_enum(ObjectClass 
>> > *klass, const char *name,
>> >  object_class_property_add(klass, name, typename,
>> >get ? property_get_enum : NULL,
>> >set ? property_set_enum : NULL,
>> > -  property_release_enum,
>> >prop, &local_err);
>> >  if (local_err) {
>> >  error_propagate(errp, local_err);
>> > @@ -2082,7 +2077,6 @@ void object_class_property_add_tm(ObjectClass 
>> > *klass, const char *name,
>> >  
>> >  object_class_property_add(klass, name, "struct tm",
>> >get ? property_get_tm : NULL, NULL,
>> > -  property_release_tm,
>> >prop, &local_err);
>> >  if (local_err) {
>> >  error_propagate(errp, local_err);
>> 
>> Likewise.
>
> Same as above.
>
>> [...]

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [RFC PATCH 6/8] quorum: Avoid bdrv_aio_writev() for rewrites

[Alberto Garcia]

On Thu 10 Nov 2016 06:19:07 PM CET, Kevin Wolf wrote:
> Replacing it with bdrv_co_pwritev() prepares us for byte granularity
> requests and gets us rid of the last bdrv_aio_*() user in quorum.
>
> Signed-off-by: Kevin Wolf 
> ---
>  block/quorum.c | 52 +---
>  1 file changed, 33 insertions(+), 19 deletions(-)
>
> diff --git a/block/quorum.c b/block/quorum.c
> index b2bb3af..1426115 100644
> --- a/block/quorum.c
> +++ b/block/quorum.c
> @@ -134,6 +134,11 @@ struct QuorumAIOCB {
>  int children_read;  /* how many children have been read from */
>  };
>  
> +typedef struct QuorumCo {
> +QuorumAIOCB *acb;
> +int i;
> +} QuorumCo;

What Eric said: this could be up here in the first patch already.

> -static void quorum_rewrite_aio_cb(void *opaque, int ret)
> -{
> -QuorumAIOCB *acb = opaque;
> -
> -/* one less rewrite to do */
> -acb->rewrite_count--;
> -qemu_coroutine_enter_if_inactive(acb->co);
> -}

You're moving this logic to quorum_rewrite_entry(), but the comment in
quorum_rewrite_bad_versions() still refers to this function.

> +static void quorum_rewrite_entry(void *opaque)
> +{
> +QuorumCo *co = opaque;
> +QuorumAIOCB *acb = co->acb;
> +BDRVQuorumState *s = acb->bs->opaque;
> +int ret;
> +
> +ret = bdrv_co_pwritev(s->children[co->i],
> +  acb->sector_num * BDRV_SECTOR_SIZE,
> +  acb->nb_sectors * BDRV_SECTOR_SIZE,
> +  acb->qiov, 0);
> +(void) ret;

Why do you need 'ret' at all? If it's a placeholder to remind us to do
something with this value in the future, you can simply add a FIXME
comment.

> +/* one less rewrite to do */
> +acb->rewrite_count--;
> +qemu_coroutine_enter_if_inactive(acb->co);

I think you should only enter acb->co when acb->rewrite_count reaches
zero.

In all other cases the main coroutine simply iterates inside the while()
loop, verifies that the number is still positive and yields again.

The same applies to all other cases of qemu_coroutine_enter_if_inactive,
by the way (I failed to notice it in patch #5).

Berto

[Qemu-devel] [PULL for-2.8 0/2] target-alpha update

[Richard Henderson]

I had been going to delay this pull until after the mttcg merge in 2.9,
but there's really no point in that.  One *can* play with non-parallel
smp in the meantime, and it gives us a basis for comparison later.


r~


The following changes since commit b0bcc86d2a87456f5a276f941dc775b265b309cf:

  Update version for v2.8.0-rc0 release (2016-11-15 20:55:12 +)

are available in the git repository at:

  git://github.com/rth7680/qemu.git tags/pull-axp-20161117

for you to fetch changes up to 022f52e040807363213c8752ce61a7d0f57e3078:

  target-alpha: Log cpuid with -d int (2016-11-17 15:56:31 +0100)


Update alpha palcode for smp


Richard Henderson (2):
  target-alpha: Update palcode for smp
  target-alpha: Log cpuid with -d int

 pc-bios/palcode-clipper | Bin 133550 -> 152680 bytes
 roms/qemu-palcode   |   2 +-
 target-alpha/helper.c   |   6 --
 3 files changed, 5 insertions(+), 3 deletions(-)

[Qemu-devel] [PULL for-2.8 2/2] target-alpha: Log cpuid with -d int

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target-alpha/helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target-alpha/helper.c b/target-alpha/helper.c
index 2ef6cbe..a5c3088 100644
--- a/target-alpha/helper.c
+++ b/target-alpha/helper.c
@@ -307,8 +307,10 @@ void alpha_cpu_do_interrupt(CPUState *cs)
 name = "call_pal";
 break;
 }
-qemu_log("INT %6d: %s(%#x) pc=%016" PRIx64 " sp=%016" PRIx64 "\n",
- ++count, name, env->error_code, env->pc, env->ir[IR_SP]);
+qemu_log("INT %6d: %s(%#x) cpu=%d pc=%016"
+ PRIx64 " sp=%016" PRIx64 "\n",
+ ++count, name, env->error_code, cs->cpu_index,
+ env->pc, env->ir[IR_SP]);
 }
 
 cs->exception_index = -1;
-- 
2.7.4

Re: [Qemu-devel] [PATCH v1] qemu: command: rework cpu feature argument support

[Markus Armbruster]

Eduardo Habkost  writes:

> CCing qemu-devel.
>
> CCing Markus, in case he has any insights about the interface
> introspection.
>
> On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote:
>> On Mon, Nov 14, 2016 at 18:02:29 -0200, Eduardo Habkost wrote:
>> > On Mon, Nov 14, 2016 at 02:26:03PM -0500, Collin L. Walling wrote:
>> > > cpu features are passed to the qemu command with feature=on/off
>> > > instead of +/-feature.
>> > > 
>> > > Signed-off-by: Collin L. Walling 
>> > 
>> > If I'm not mistaken, the "feature=on|off" syntax was added on
>> > QEMU 2.0.0. Does current libvirt support older QEMU versions?
>> 
>> Of course it does. I'd love to switch to feature=on|off, but how can we
>> check if QEMU supports it? We can't really start using this syntax
>> without it.
>
> Actually, I was wrong, this was added in v2.4.0. "feat=on|off"
> needs two things to work (in x86):
>
> * Translation of all "foo=bar" options to QOM property setting.
>   This was added in v2.0.0-rc0~162^2
> * The actual QOM properties for feature names to be present. They
>   were added in v2.4.0-rc0~101^2~1
>
> So you can be sure "feat=on" is supported by checking if the
> feature flags are present in device-list-properties output for
> the CPU model. But device-list-properties is also messy[1].
>
> Maybe we can use the availability of query-cpu-model-expansion to
> check if we can safely use the new "feat=on|off" system? It's
> easier than taking all the variables above into account.
>
> ---
>
> [1] * device-list-properties support for x86 CPU QOM classes
>   will be in QEMU 2.8.
> * device-list-properties on x86 CPU QOM classes returns
>   an error on QEMU 2.5-2.7.
> * device-list-properties on x86 CPU classes may crash QEMU in
>   QEMU older than 2.5 (see commit 4c315c27).
>   But:
> * query-cpu-definitions will probably return the CPU QOM
>   typename in QEMU 2.9+ only.

In other words:

* feature=on|off works since 2.4, but what's the best way to probe for
  it?

* device-list-properties can act as a witness, but there are two
  problems: you need to map between CPU model and QOM typename to use
  it, and it can fail or even crash before 2.8.

* 2.9 will take provide the information to map between CPU model and QOM
  typename.

I guess the sane choice is to probe for the CPU model - QOM typename
mapping information, and if it's there, assume device-list-properties
and feature=on|off work.  Eduardo, what do you think?

[Qemu-devel] [PULL 1/1] ivshmem: Fix 64 bit memory bar configuration

[Marc-André Lureau]

From: Zhuang Yanying 

Device ivshmem property use64=0 is designed to make the device
expose a 32 bit shared memory BAR instead of 64 bit one.  The
default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit
BAR.  A 32 bit BAR can support only up to 1 GiB of shared memory.

This worked as designed until commit 5400c02 accidentally flipped
its sense: since then, we misinterpret use64=0 as use64=1 and vice
versa.  Worse, the default got flipped as well.  Devices
ivshmem-plain and ivshmem-doorbell are not affected.

Fix by restoring the test of IVShmemState member not_legacy_32bit
that got messed up in commit 5400c02.  Also update its
initialization for devices ivhsmem-plain and ivshmem-doorbell.
Without that, they'd regress to 32 bit BARs.

Signed-off-by: Zhuang Yanying 
Reviewed-by: Gonglei 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
Signed-off-by: Marc-André Lureau 
Message-Id: <1479385863-7648-1-git-send-email-ann.zhuangyany...@huawei.com>
---
 hw/misc/ivshmem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 230e51b..abeaf3d 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -858,7 +858,7 @@ static void ivshmem_common_realize(PCIDevice *dev, Error 
**errp)
 pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY,
  &s->ivshmem_mmio);
 
-if (!s->not_legacy_32bit) {
+if (s->not_legacy_32bit) {
 attr |= PCI_BASE_ADDRESS_MEM_TYPE_64;
 }
 
@@ -1045,6 +1045,7 @@ static void ivshmem_plain_init(Object *obj)
  ivshmem_check_memdev_is_busy,
  OBJ_PROP_LINK_UNREF_ON_RELEASE,
  &error_abort);
+s->not_legacy_32bit = 1;
 }
 
 static void ivshmem_plain_realize(PCIDevice *dev, Error **errp)
@@ -1116,6 +1117,7 @@ static void ivshmem_doorbell_init(Object *obj)
 
 s->features |= (1 << IVSHMEM_MSI);
 s->legacy_size = SIZE_MAX;  /* whatever the server sends */
+s->not_legacy_32bit = 1;
 }
 
 static void ivshmem_doorbell_realize(PCIDevice *dev, Error **errp)
-- 
2.10.0

[Qemu-devel] [PULL 0/1] ivshmem fix for 2.8

[Marc-André Lureau]

The following changes since commit b0bcc86d2a87456f5a276f941dc775b265b309cf:

  Update version for v2.8.0-rc0 release (2016-11-15 20:55:12 +)

are available in the git repository at:

  g...@github.com:elmarco/qemu.git tags/ivshmem-pull-request

for you to fetch changes up to b2b79a696052040389e0f9980801a880ce5a6ae3:

  ivshmem: Fix 64 bit memory bar configuration (2016-11-17 18:39:59 +0400)





Zhuang Yanying (1):
  ivshmem: Fix 64 bit memory bar configuration

 hw/misc/ivshmem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.10.0

Re: [Qemu-devel] [PATCH] tftp: fake support for netascii protocol

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PATCH] tftp: fake support for netascii protocol
Type: series
Message-id: 20161117122000.22577-1-vincent.ber...@exoscale.ch

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20161117122000.22577-1-vincent.ber...@exoscale.ch 
-> patchew/20161117122000.22577-1-vincent.ber...@exoscale.ch
Switched to a new branch 'test'
bfea015 tftp: fake support for netascii protocol

=== OUTPUT BEGIN ===
Checking PATCH 1/1: tftp: fake support for netascii protocol...
ERROR: suspect code indent for conditional statements (2, 6)
#24: FILE: slirp/tftp.c:329:
+  if (strcasecmp(&tp->x.tp_buf[k], "octet") == 0) {
+  k += 6;

ERROR: suspect code indent for conditional statements (2, 6)
#26: FILE: slirp/tftp.c:331:
+  } else if (strcasecmp(&tp->x.tp_buf[k], "netascii") == 0) {
+  k += 9;

ERROR: Missing Signed-off-by: line(s)

total: 3 errors, 0 warnings, 18 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

Re: [Qemu-devel] [PATCH v14 12/22] vfio: Add notifier callback to parent's ops structure of mdev

[Alex Williamson]

On Thu, 17 Nov 2016 20:35:38 +0800
Jike Song  wrote:

> On 11/17/2016 04:46 AM, Kirti Wankhede wrote:
> > Add a notifier calback to parent's ops structure of mdev device so that per
> > device notifer for vfio module is registered through vfio_mdev module.
> > 
> > Signed-off-by: Kirti Wankhede 
> > Signed-off-by: Neo Jia 
> > Change-Id: Iafa6f1721aecdd6e50eb93b153b5621e6d29b637
> > ---
> >  drivers/vfio/mdev/vfio_mdev.c | 34 +-
> >  include/linux/mdev.h  |  9 +
> >  2 files changed, 42 insertions(+), 1 deletion(-)
> > 
> 
> Hi Alex, Kirti,
> 
> Since everyone agreed we should let the vendor driver call 
> vfio_register_notifier
> directly, can you drop this patch from merging? So that I don't need to send a
> reverse patch.

This seems like a reasonable request to me, this patch drops cleanly
from the series.  Any objection Kirti?  It seems like it removes a
little bit of pre-release churn from the API.  Thanks,

Alex

Re: [Qemu-devel] [RFC PATCH 7/8] quorum: Implement .bdrv_co_preadv/pwritev()

[Alberto Garcia]

On Fri 11 Nov 2016 10:58:57 AM CET, Kevin Wolf wrote:

>> > Note that the QMP events emitted by the driver are an external API
>> > that we were careless enough to define as sector based. The offset
>> > and length of requests reported in events are rounded down
>> > therefore.
>> 
>> Would it be better to round offset down and length up?  A length of 0
>> looks odd.
>
> To be honest, I don't know what these events are used for and what the
> most useful rounding would be. Maybe Berto can tell?

What makes sense if we don't want to break the API is to round as Eric
suggests. Or, more specifically:

sector-num = ROUND_SECTOR_DOWN(offset)
sectors-count = ROUND_SECTOR_UP(offset + length) - sector-num

>> Should we add more fields to the two affected events (QUORUM_FAILURE
>> and QUORUM_REPORT_BAD)? We have to keep the existing fields for
>> back-compat, but we could add new fields that give byte-based
>> locations for management apps smart enough to use the new instead of
>> the old (particularly since the old fields are named 'sector-num' and
>> 'sectors-count').
>
> If there is a user for the new fields, I can do that.

I wouldn't do it until we have a use case.

>> > @@ -462,8 +461,8 @@ static void GCC_FMT_ATTR(2, 3) quorum_err(QuorumAIOCB 
>> > *acb,
>> >  va_list ap;
>> >  
>> >  va_start(ap, fmt);
>> > -fprintf(stderr, "quorum: sector_num=%" PRId64 " nb_sectors=%d ",
>> > -acb->sector_num, acb->nb_sectors);
>> > +fprintf(stderr, "quorum: offset=%" PRIu64 " bytes=%" PRIu64 " ",
>> > +acb->offset, acb->bytes);
>> 
>> Might be worth a separate patch to get rid of fprintf and use correct
>> error reporting.  But not the work for this patch.
>
> What would correct error reporting be in this case? A QMP event?
> Because other than that and stderr, I don't think we have any channels
> for error messages for I/O requests. We could use error_report(), but
> it would be effectively the same thing as fprintf().

I'm not sure what was the original use case of this, but the
functionality should be equivalente to the blkverify driver.

I think it should actually be possible to replace blkverify completely
with quorum:

https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg02817.html

Berto

Re: [Qemu-devel] [PATCH 0/4] Add support for the Epson RX8900 RTC to the aspeed board

[no-reply]

Hi,

Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Subject: [Qemu-devel] [PATCH 0/4] Add support for the Epson RX8900 RTC to the 
aspeed board
Type: series
Message-id: 1479357400-17441-1-git-send-email-alast...@au1.ibm.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
477fb82 arm: Add an RX8900 RTC to the ASpeed board
6e0c516 hw/timer: Add Epson RX8900 RTC support
320decf qtest: Support named interrupts
cd85764 arm: Uniquely name imx25 I2C buses.

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD   centos6
make[1]: Entering directory `/var/tmp/patchew-tester-tmp-ie51qv7a/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=1e95015cd9c9
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
COLO support  yes
RDMA support  no
TCG interpreter   no
fd