Re: [PATCH 3/4] python/qmp-shell: relicense as LGPLv2+

[Luiz Capitulino]

On Fri, Mar 25, 2022 at 4:04 PM John Snow  wrote:

> qmp-shell is presently licensed as GPLv2 (only). I intend to include
> this tool as an add-on to an LGPLv2+ library package hosted on
> PyPI.org. I've selected LGPLv2+ to maximize compatibility with other
> licenses while retaining a copyleft license.
>
> To keep licensing matters simple, I'd like to relicense this tool as
> LGPLv2+ as well in order to keep the resultant license of the hosted
> release files simple -- even if library users won't "link against" this
> command line tool.
>
> Therefore, I am asking permission from the current authors of this
> tool to loosen the license. At present, those people are:
>
> - John Snow (me!), 411/609
> - Luiz Capitulino, Author, 97/609
> - Daniel Berrangé, 81/609
> - Eduardo Habkost, 10/609
> - Marc-André Lureau, 6/609
> - Fam Zheng, 3/609
> - Cleber Rosa, 1/609
>
> (All of which appear to have been written under redhat.com addresses.)
>
> Eduardo's fixes are largely automated from 2to3 conversion tools and may
> not necessarily constitute authorship, but his signature would put to
> rest any questions.
>
> Cleber's changes concern a single import statement change. Also won't
> hurt to ask.
>
> CC: Luiz Capitulino 
> CC: Daniel Berrange 
> CC: Eduardo Habkost 
> CC: Marc-André Lureau 
> CC: Fam Zheng 
> CC: Cleber Rosa 
>
> Signed-off-by: John Snow 
>

Acked-by: Luiz Capitulino 

Thank you John and everybody who's contributing, it's very reassuring to see
these things are in good hands!

- Luiz

---
>  python/qemu/aqmp/qmp_shell.py | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/python/qemu/aqmp/qmp_shell.py b/python/qemu/aqmp/qmp_shell.py
> index 35691494d0..c23f1b1928 100644
> --- a/python/qemu/aqmp/qmp_shell.py
> +++ b/python/qemu/aqmp/qmp_shell.py
> @@ -1,11 +1,12 @@
>  #
> -# Copyright (C) 2009, 2010 Red Hat Inc.
> +# Copyright (C) 2009-2022 Red Hat Inc.
>  #
>  # Authors:
>  #  Luiz Capitulino 
> +#  John Snow 
>  #
> -# This work is licensed under the terms of the GNU GPL, version 2.  See
> -# the COPYING file in the top-level directory.
> +# This work is licensed under the terms of the GNU LGPL, version 2 or
> +# later. See the COPYING file in the top-level directory.
>  #
>
>  """
> --
> 2.34.1
>
>

Re: [Qemu-devel] Aborts in iotest 169

[Luiz Capitulino]

On Wed, 23 Jan 2019 17:12:35 +0100
Max Reitz  wrote:

> On 23.01.19 17:04, Luiz Capitulino wrote:
> > On Wed, 23 Jan 2019 16:48:49 +0100
> > Max Reitz  wrote:
> >   
> >> Hi,
> >>
> >> When running 169 in parallel (e.g. like so:
> >>
> >> $ while TEST_DIR=/tmp/t0 ./check -T -qcow2 169; do; done
> >> $ while TEST_DIR=/tmp/t1 ./check -T -qcow2 169; do; done
> >> $ while TEST_DIR=/tmp/t2 ./check -T -qcow2 169; do; done
> >> $ while TEST_DIR=/tmp/t3 ./check -T -qcow2 169; do; done
> >>
> >> in four different shells), I get aborts:  
> > 
> > OK, is this part of a test-suite that's also running migration
> > tests in parallel or in sequence? In other words, what does
> > iotests have to do with migration (sorry if this is stupid
> > question, but it's been years I don't do qemu).  
> 
> They run migration tests in sequence, but if you run multiple test
> instances in parallel, well, then they will be run in parallel.
> 
> The only reason I CC'd you was because you were so prominent in git
> blame. O:-)

Yeah, that's often the case with me :-)

> > When this happened in the past it meant some QEMU code skipped a
> > transition, but I can't tell what this has to do with iotests.  
> 
> Well, this iotest (which tests a migration configuration) sometimes
> apparently results in this invalid transition.  But that can't be just
> the test's fault, as qemu should handle that gracefully.

Does iotest run a guest or does it only executes parts of qemu
code? If it's the latter, then I'd guess the test code is missing
calling qemu code that sets the appropriate state between
running and postmigrate states.

> It's probably an issue in the migration code and not so much in vl.c, yes...

Yeah, I'll let the migration people jump in.

Re: [Qemu-devel] Aborts in iotest 169

[Luiz Capitulino]

On Wed, 23 Jan 2019 16:48:49 +0100
Max Reitz  wrote:

> Hi,
> 
> When running 169 in parallel (e.g. like so:
> 
> $ while TEST_DIR=/tmp/t0 ./check -T -qcow2 169; do; done
> $ while TEST_DIR=/tmp/t1 ./check -T -qcow2 169; do; done
> $ while TEST_DIR=/tmp/t2 ./check -T -qcow2 169; do; done
> $ while TEST_DIR=/tmp/t3 ./check -T -qcow2 169; do; done
> 
> in four different shells), I get aborts:

OK, is this part of a test-suite that's also running migration
tests in parallel or in sequence? In other words, what does
iotests have to do with migration (sorry if this is stupid
question, but it's been years I don't do qemu).

More below.

[...]

> The backtrace always goes like this:
> 
> (gdb) bt
> #0  0x7f0acf5cc53f in raise () at /lib64/libc.so.6
> #1  0x7f0acf5b6895 in abort () at /lib64/libc.so.6
> #2  0x55a46ebbb1a6 in runstate_set (new_state=RUN_STATE_POSTMIGRATE)
> at vl.c:742
> #3  0x55a46ebbb1a6 in runstate_set
> (new_state=new_state@entry=RUN_STATE_POSTMIGRATE) at vl.c:730
> #4  0x55a46ed39129 in migration_iteration_finish (s=0x55a4708be000)
> at migration/migration.c:2972
> #5  0x55a46ed39129 in migration_thread
> (opaque=opaque@entry=0x55a4708be000) at migration/migration.c:3130
> #6  0x55a46eea665a in qemu_thread_start (args=) at
> util/qemu-thread-posix.c:502
> 
> 
> #7  0x7f0acf76258e in start_thread () at /lib64/libpthread.so.0
> #8  0x7f0acf6916a3 in clone () at /lib64/libc.so.6
> (gdb) frame 2
> #2  0x55a46ebbb1a6 in runstate_set (new_state=RUN_STATE_POSTMIGRATE)
> at vl.c:742
> 742 abort();
> (gdb) print current_run_state
> $1 = RUN_STATE_RUNNING
> 
> 
> Neither of migration or runstates are my strong suite, so I thought I'd
> report it before diving into it.

So, the problem seems to be that qemu is going from running state to
postmigrate state. IIRC, this is is an invalid state transition. The
valid states to transition to depends if this guest is the source or
target for migration.

When this happened in the past it meant some QEMU code skipped a
transition, but I can't tell what this has to do with iotests.

Re: [Qemu-devel] [PATCH] qemu: Add virtio pmem device

[Luiz Capitulino]

On Thu, 13 Sep 2018 03:06:27 -0400 (EDT)
Pankaj Gupta  wrote:

> >   
> > >  This patch adds virtio-pmem Qemu device.
> > > 
> > >  This device presents memory address range information to guest
> > >  which is backed by file backend type. It acts like persistent
> > >  memory device for KVM guest. Guest can perform read and
> > >  persistent write operations on this memory range with the help
> > >  of DAX capable filesystem.
> > > 
> > >  Persistent guest writes are assured with the help of virtio
> > >  based flushing interface. When guest userspace space performs
> > >  fsync on file fd on pmem device, a flush command is send to
> > >  Qemu over VIRTIO and host side flush/sync is done on backing
> > >  image file.
> > > 
> > > Signed-off-by: Pankaj Gupta 
> > > ---
> > > Changes from RFC v3:
> > > - Return EIO for host fsync failure instead of errno - Luiz, Stefan
> > > - Change version for inclusion to Qemu 3.1 - Eric
> > > 
> > > Changes from RFC v2:
> > > - Use aio_worker() to avoid Qemu from hanging with blocking fsync
> > >   call - Stefan
> > > - Use virtio_st*_p() for endianess - Stefan
> > > - Correct indentation in qapi/misc.json - Eric
> > > 
> > >  hw/virtio/Makefile.objs |   3 +
> > >  hw/virtio/virtio-pci.c  |  44 +
> > >  hw/virtio/virtio-pci.h  |  14 ++
> > >  hw/virtio/virtio-pmem.c | 241
> > >  
> > >  include/hw/pci/pci.h|   1 +
> > >  include/hw/virtio/virtio-pmem.h |  42 +
> > >  include/standard-headers/linux/virtio_ids.h |   1 +
> > >  qapi/misc.json  |  26 ++-
> > >  8 files changed, 371 insertions(+), 1 deletion(-)
> > >  create mode 100644 hw/virtio/virtio-pmem.c
> > >  create mode 100644 include/hw/virtio/virtio-pmem.h
> > > 
> > > diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
> > > index 1b2799cfd8..7f914d45d0 100644
> > > --- a/hw/virtio/Makefile.objs
> > > +++ b/hw/virtio/Makefile.objs
> > > @@ -10,6 +10,9 @@ obj-$(CONFIG_VIRTIO_CRYPTO) += virtio-crypto.o
> > >  obj-$(call land,$(CONFIG_VIRTIO_CRYPTO),$(CONFIG_VIRTIO_PCI)) +=
> > >  virtio-crypto-pci.o
> > >  
> > >  obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
> > > +ifeq ($(CONFIG_MEM_HOTPLUG),y)
> > > +obj-$(CONFIG_LINUX) += virtio-pmem.o
> > > +endif
> > >  obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
> > >  endif
> > >  
> > > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > > index 3a01fe90f0..93d3fc05c7 100644
> > > --- a/hw/virtio/virtio-pci.c
> > > +++ b/hw/virtio/virtio-pci.c
> > > @@ -2521,6 +2521,49 @@ static const TypeInfo virtio_rng_pci_info = {
> > >  .class_init= virtio_rng_pci_class_init,
> > >  };
> > >  
> > > +/* virtio-pmem-pci */
> > > +
> > > +static void virtio_pmem_pci_realize(VirtIOPCIProxy *vpci_dev, Error
> > > **errp)
> > > +{
> > > +VirtIOPMEMPCI *vpmem = VIRTIO_PMEM_PCI(vpci_dev);
> > > +DeviceState *vdev = DEVICE(>vdev);
> > > +
> > > +qdev_set_parent_bus(vdev, BUS(_dev->bus));
> > > +object_property_set_bool(OBJECT(vdev), true, "realized", errp);
> > > +}
> > > +
> > > +static void virtio_pmem_pci_class_init(ObjectClass *klass, void *data)
> > > +{
> > > +DeviceClass *dc = DEVICE_CLASS(klass);
> > > +VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > > +PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > > +k->realize = virtio_pmem_pci_realize;
> > > +set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> > > +pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > +pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_PMEM;
> > > +pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
> > > +pcidev_k->class_id = PCI_CLASS_OTHERS;
> > > +}
> > > +
> > > +static void virtio_pmem_pci_instance_init(Object *obj)
> > > +{
> > > +VirtIOPMEMPCI *dev = VIRTIO_PMEM_PCI(obj);
> > > +
> > > +virtio_instance_init_common(obj, >vdev, sizeof(dev->vdev),
> > > +TYPE_VIRTIO_PMEM);
> > > +object_property_add_alias(obj, "memdev", OBJECT(>vdev), 
> > > "memdev",
> > > +  _abort);
> > > +}
> > > +
> > > +static const TypeInfo virtio_pmem_pci_info = {
> > > +.name  = TYPE_VIRTIO_PMEM_PCI,
> > > +.parent= TYPE_VIRTIO_PCI,
> > > +.instance_size = sizeof(VirtIOPMEMPCI),
> > > +.instance_init = virtio_pmem_pci_instance_init,
> > > +.class_init= virtio_pmem_pci_class_init,
> > > +};
> > > +
> > > +
> > >  /* virtio-input-pci */
> > >  
> > >  static Property virtio_input_pci_properties[] = {
> > > @@ -2714,6 +2757,7 @@ static void virtio_pci_register_types(void)
> > >  type_register_static(_balloon_pci_info);
> > >  type_register_static(_serial_pci_info);
> > >  type_register_static(_net_pci_info);
> > > +type_register_static(_pmem_pci_info);
> > >  #ifdef CONFIG_VHOST_SCSI
> > >  type_register_static(_scsi_pci_info);
> > >  

Re: [Qemu-devel] [PATCH 3/3] virtio-pmem: Add virtio pmem driver

[Luiz Capitulino]

On Thu, 13 Sep 2018 02:58:21 -0400 (EDT)
Pankaj Gupta  wrote:

> Hi Luiz,
> 
> Thanks for the review.
> 
> >   
> > > This patch adds virtio-pmem driver for KVM guest.
> > > 
> > > Guest reads the persistent memory range information from
> > > Qemu over VIRTIO and registers it on nvdimm_bus. It also
> > > creates a nd_region object with the persistent memory
> > > range information so that existing 'nvdimm/pmem' driver
> > > can reserve this into system memory map. This way
> > > 'virtio-pmem' driver uses existing functionality of pmem
> > > driver to register persistent memory compatible for DAX
> > > capable filesystems.
> > > 
> > > This also provides function to perform guest flush over
> > > VIRTIO from 'pmem' driver when userspace performs flush
> > > on DAX memory range.
> > > 
> > > Signed-off-by: Pankaj Gupta 
> > > ---
> > >  drivers/virtio/Kconfig   |   9 ++
> > >  drivers/virtio/Makefile  |   1 +
> > >  drivers/virtio/virtio_pmem.c | 255
> > >  +++
> > >  include/uapi/linux/virtio_ids.h  |   1 +
> > >  include/uapi/linux/virtio_pmem.h |  40 ++
> > >  5 files changed, 306 insertions(+)
> > >  create mode 100644 drivers/virtio/virtio_pmem.c
> > >  create mode 100644 include/uapi/linux/virtio_pmem.h
> > > 
> > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > index 3589764..a331e23 100644
> > > --- a/drivers/virtio/Kconfig
> > > +++ b/drivers/virtio/Kconfig
> > > @@ -42,6 +42,15 @@ config VIRTIO_PCI_LEGACY
> > >  
> > > If unsure, say Y.
> > >  
> > > +config VIRTIO_PMEM
> > > + tristate "Support for virtio pmem driver"
> > > + depends on VIRTIO
> > > + help
> > > + This driver provides support for virtio based flushing interface
> > > + for persistent memory range.
> > > +
> > > + If unsure, say M.
> > > +
> > >  config VIRTIO_BALLOON
> > >   tristate "Virtio balloon driver"
> > >   depends on VIRTIO
> > > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > > index 3a2b5c5..cbe91c6 100644
> > > --- a/drivers/virtio/Makefile
> > > +++ b/drivers/virtio/Makefile
> > > @@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
> > >  virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
> > >  obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
> > >  obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
> > > +obj-$(CONFIG_VIRTIO_PMEM) += virtio_pmem.o
> > > diff --git a/drivers/virtio/virtio_pmem.c b/drivers/virtio/virtio_pmem.c
> > > new file mode 100644
> > > index 000..c22cc87
> > > --- /dev/null
> > > +++ b/drivers/virtio/virtio_pmem.c
> > > @@ -0,0 +1,255 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * virtio_pmem.c: Virtio pmem Driver
> > > + *
> > > + * Discovers persistent memory range information
> > > + * from host and provides a virtio based flushing
> > > + * interface.
> > > + */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +struct virtio_pmem_request {
> > > + /* Host return status corresponding to flush request */
> > > + int ret;
> > > +
> > > + /* command name*/
> > > + char name[16];
> > > +
> > > + /* Wait queue to process deferred work after ack from host */
> > > + wait_queue_head_t host_acked;
> > > + bool done;
> > > +
> > > + /* Wait queue to process deferred work after virt queue buffer avail */
> > > + wait_queue_head_t wq_buf;
> > > + bool wq_buf_avail;
> > > + struct list_head list;
> > > +};
> > > +
> > > +struct virtio_pmem {
> > > + struct virtio_device *vdev;
> > > +
> > > + /* Virtio pmem request queue */
> > > + struct virtqueue *req_vq;
> > > +
> > > + /* nvdimm bus registers virtio pmem device */
> > > + struct nvdimm_bus *nvdimm_bus;
> > > + struct nvdimm_bus_descriptor nd_desc;
> > > +
> > > + /* List to store deferred work if virtqueue is full */
> > > + struct list_head req_list;
> > > +
> > > + /* Synchronize virtqueue data */
> > > + spinlock_t pmem_lock;
> > > +
> > > + /* Memory region information */
> > > + uint64_t start;
> > > + uint64_t size;
> > > +};
> > > +
> > > +static struct virtio_device_id id_table[] = {
> > > + { VIRTIO_ID_PMEM, VIRTIO_DEV_ANY_ID },
> > > + { 0 },
> > > +};
> > > +
> > > + /* The interrupt handler */
> > > +static void host_ack(struct virtqueue *vq)
> > > +{
> > > + unsigned int len;
> > > + unsigned long flags;
> > > + struct virtio_pmem_request *req, *req_buf;
> > > + struct virtio_pmem *vpmem = vq->vdev->priv;
> > > +
> > > + spin_lock_irqsave(>pmem_lock, flags);
> > > + while ((req = virtqueue_get_buf(vq, )) != NULL) {
> > > + req->done = true;
> > > + wake_up(>host_acked);
> > > +
> > > + if (!list_empty(>req_list)) {
> > > + req_buf = list_first_entry(>req_list,
> > > + struct virtio_pmem_request, list);
> > > + list_del(>req_list);
> > > + req_buf->wq_buf_avail = true;
> > > +   

Re: [Qemu-devel] [PATCH] qemu: Add virtio pmem device

[Luiz Capitulino]

On Fri, 31 Aug 2018 19:00:19 +0530
Pankaj Gupta  wrote:

>  This patch adds virtio-pmem Qemu device.
> 
>  This device presents memory address range information to guest
>  which is backed by file backend type. It acts like persistent
>  memory device for KVM guest. Guest can perform read and 
>  persistent write operations on this memory range with the help 
>  of DAX capable filesystem.
> 
>  Persistent guest writes are assured with the help of virtio 
>  based flushing interface. When guest userspace space performs 
>  fsync on file fd on pmem device, a flush command is send to 
>  Qemu over VIRTIO and host side flush/sync is done on backing 
>  image file.
> 
> Signed-off-by: Pankaj Gupta 
> ---
> Changes from RFC v3:
> - Return EIO for host fsync failure instead of errno - Luiz, Stefan
> - Change version for inclusion to Qemu 3.1 - Eric
> 
> Changes from RFC v2:
> - Use aio_worker() to avoid Qemu from hanging with blocking fsync
>   call - Stefan
> - Use virtio_st*_p() for endianess - Stefan
> - Correct indentation in qapi/misc.json - Eric
> 
>  hw/virtio/Makefile.objs |   3 +
>  hw/virtio/virtio-pci.c  |  44 +
>  hw/virtio/virtio-pci.h  |  14 ++
>  hw/virtio/virtio-pmem.c | 241 
> 
>  include/hw/pci/pci.h|   1 +
>  include/hw/virtio/virtio-pmem.h |  42 +
>  include/standard-headers/linux/virtio_ids.h |   1 +
>  qapi/misc.json  |  26 ++-
>  8 files changed, 371 insertions(+), 1 deletion(-)
>  create mode 100644 hw/virtio/virtio-pmem.c
>  create mode 100644 include/hw/virtio/virtio-pmem.h
> 
> diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
> index 1b2799cfd8..7f914d45d0 100644
> --- a/hw/virtio/Makefile.objs
> +++ b/hw/virtio/Makefile.objs
> @@ -10,6 +10,9 @@ obj-$(CONFIG_VIRTIO_CRYPTO) += virtio-crypto.o
>  obj-$(call land,$(CONFIG_VIRTIO_CRYPTO),$(CONFIG_VIRTIO_PCI)) += 
> virtio-crypto-pci.o
>  
>  obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
> +ifeq ($(CONFIG_MEM_HOTPLUG),y)
> +obj-$(CONFIG_LINUX) += virtio-pmem.o
> +endif
>  obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
>  endif
>  
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 3a01fe90f0..93d3fc05c7 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -2521,6 +2521,49 @@ static const TypeInfo virtio_rng_pci_info = {
>  .class_init= virtio_rng_pci_class_init,
>  };
>  
> +/* virtio-pmem-pci */
> +
> +static void virtio_pmem_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> +{
> +VirtIOPMEMPCI *vpmem = VIRTIO_PMEM_PCI(vpci_dev);
> +DeviceState *vdev = DEVICE(>vdev);
> +
> +qdev_set_parent_bus(vdev, BUS(_dev->bus));
> +object_property_set_bool(OBJECT(vdev), true, "realized", errp);
> +}
> +
> +static void virtio_pmem_pci_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> +PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> +k->realize = virtio_pmem_pci_realize;
> +set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> +pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> +pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_PMEM;
> +pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
> +pcidev_k->class_id = PCI_CLASS_OTHERS;
> +}
> +
> +static void virtio_pmem_pci_instance_init(Object *obj)
> +{
> +VirtIOPMEMPCI *dev = VIRTIO_PMEM_PCI(obj);
> +
> +virtio_instance_init_common(obj, >vdev, sizeof(dev->vdev),
> +TYPE_VIRTIO_PMEM);
> +object_property_add_alias(obj, "memdev", OBJECT(>vdev), "memdev",
> +  _abort);
> +}
> +
> +static const TypeInfo virtio_pmem_pci_info = {
> +.name  = TYPE_VIRTIO_PMEM_PCI,
> +.parent= TYPE_VIRTIO_PCI,
> +.instance_size = sizeof(VirtIOPMEMPCI),
> +.instance_init = virtio_pmem_pci_instance_init,
> +.class_init= virtio_pmem_pci_class_init,
> +};
> +
> +
>  /* virtio-input-pci */
>  
>  static Property virtio_input_pci_properties[] = {
> @@ -2714,6 +2757,7 @@ static void virtio_pci_register_types(void)
>  type_register_static(_balloon_pci_info);
>  type_register_static(_serial_pci_info);
>  type_register_static(_net_pci_info);
> +type_register_static(_pmem_pci_info);
>  #ifdef CONFIG_VHOST_SCSI
>  type_register_static(_scsi_pci_info);
>  #endif
> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> index 813082b0d7..fe74fcad3f 100644
> --- a/hw/virtio/virtio-pci.h
> +++ b/hw/virtio/virtio-pci.h
> @@ -19,6 +19,7 @@
>  #include "hw/virtio/virtio-blk.h"
>  #include "hw/virtio/virtio-net.h"
>  #include "hw/virtio/virtio-rng.h"
> +#include "hw/virtio/virtio-pmem.h"
>  #include "hw/virtio/virtio-serial.h"
>  #include "hw/virtio/virtio-scsi.h"
>  #include "hw/virtio/virtio-balloon.h"
> @@ -57,6 +58,7 @@ typedef 

Re: [Qemu-devel] [PATCH 3/3] virtio-pmem: Add virtio pmem driver

[Luiz Capitulino]

On Fri, 31 Aug 2018 19:00:18 +0530
Pankaj Gupta  wrote:

> This patch adds virtio-pmem driver for KVM guest.
> 
> Guest reads the persistent memory range information from
> Qemu over VIRTIO and registers it on nvdimm_bus. It also
> creates a nd_region object with the persistent memory
> range information so that existing 'nvdimm/pmem' driver
> can reserve this into system memory map. This way
> 'virtio-pmem' driver uses existing functionality of pmem
> driver to register persistent memory compatible for DAX
> capable filesystems.
> 
> This also provides function to perform guest flush over
> VIRTIO from 'pmem' driver when userspace performs flush
> on DAX memory range.
> 
> Signed-off-by: Pankaj Gupta 
> ---
>  drivers/virtio/Kconfig   |   9 ++
>  drivers/virtio/Makefile  |   1 +
>  drivers/virtio/virtio_pmem.c | 255 
> +++
>  include/uapi/linux/virtio_ids.h  |   1 +
>  include/uapi/linux/virtio_pmem.h |  40 ++
>  5 files changed, 306 insertions(+)
>  create mode 100644 drivers/virtio/virtio_pmem.c
>  create mode 100644 include/uapi/linux/virtio_pmem.h
> 
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 3589764..a331e23 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -42,6 +42,15 @@ config VIRTIO_PCI_LEGACY
>  
> If unsure, say Y.
>  
> +config VIRTIO_PMEM
> + tristate "Support for virtio pmem driver"
> + depends on VIRTIO
> + help
> + This driver provides support for virtio based flushing interface
> + for persistent memory range.
> +
> + If unsure, say M.
> +
>  config VIRTIO_BALLOON
>   tristate "Virtio balloon driver"
>   depends on VIRTIO
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index 3a2b5c5..cbe91c6 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
>  virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
>  obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
>  obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
> +obj-$(CONFIG_VIRTIO_PMEM) += virtio_pmem.o
> diff --git a/drivers/virtio/virtio_pmem.c b/drivers/virtio/virtio_pmem.c
> new file mode 100644
> index 000..c22cc87
> --- /dev/null
> +++ b/drivers/virtio/virtio_pmem.c
> @@ -0,0 +1,255 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * virtio_pmem.c: Virtio pmem Driver
> + *
> + * Discovers persistent memory range information
> + * from host and provides a virtio based flushing
> + * interface.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct virtio_pmem_request {
> + /* Host return status corresponding to flush request */
> + int ret;
> +
> + /* command name*/
> + char name[16];
> +
> + /* Wait queue to process deferred work after ack from host */
> + wait_queue_head_t host_acked;
> + bool done;
> +
> + /* Wait queue to process deferred work after virt queue buffer avail */
> + wait_queue_head_t wq_buf;
> + bool wq_buf_avail;
> + struct list_head list;
> +};
> +
> +struct virtio_pmem {
> + struct virtio_device *vdev;
> +
> + /* Virtio pmem request queue */
> + struct virtqueue *req_vq;
> +
> + /* nvdimm bus registers virtio pmem device */
> + struct nvdimm_bus *nvdimm_bus;
> + struct nvdimm_bus_descriptor nd_desc;
> +
> + /* List to store deferred work if virtqueue is full */
> + struct list_head req_list;
> +
> + /* Synchronize virtqueue data */
> + spinlock_t pmem_lock;
> +
> + /* Memory region information */
> + uint64_t start;
> + uint64_t size;
> +};
> +
> +static struct virtio_device_id id_table[] = {
> + { VIRTIO_ID_PMEM, VIRTIO_DEV_ANY_ID },
> + { 0 },
> +};
> +
> + /* The interrupt handler */
> +static void host_ack(struct virtqueue *vq)
> +{
> + unsigned int len;
> + unsigned long flags;
> + struct virtio_pmem_request *req, *req_buf;
> + struct virtio_pmem *vpmem = vq->vdev->priv;
> +
> + spin_lock_irqsave(>pmem_lock, flags);
> + while ((req = virtqueue_get_buf(vq, )) != NULL) {
> + req->done = true;
> + wake_up(>host_acked);
> +
> + if (!list_empty(>req_list)) {
> + req_buf = list_first_entry(>req_list,
> + struct virtio_pmem_request, list);
> + list_del(>req_list);
> + req_buf->wq_buf_avail = true;
> + wake_up(_buf->wq_buf);
> + }
> + }
> + spin_unlock_irqrestore(>pmem_lock, flags);
> +}
> + /* Initialize virt queue */
> +static int init_vq(struct virtio_pmem *vpmem)
> +{
> + struct virtqueue *vq;
> +
> + /* single vq */
> + vpmem->req_vq = vq = virtio_find_single_vq(vpmem->vdev,
> + host_ack, "flush_queue");
> + if (IS_ERR(vq))
> + 

Re: [Qemu-devel] [RFC v3] qemu: Add virtio pmem device

[Luiz Capitulino]

On Thu, 19 Jul 2018 15:58:20 +0200
David Hildenbrand  wrote:

> On 19.07.2018 14:16, Stefan Hajnoczi wrote:
> > On Thu, Jul 19, 2018 at 01:48:13AM -0400, Pankaj Gupta wrote:  
> >>  
> >>>  
>   This patch adds virtio-pmem Qemu device.
> 
>   This device presents memory address range information to guest
>   which is backed by file backend type. It acts like persistent
>   memory device for KVM guest. Guest can perform read and persistent
>   write operations on this memory range with the help of DAX capable
>   filesystem.
> 
>   Persistent guest writes are assured with the help of virtio based
>   flushing interface. When guest userspace space performs fsync on
>   file fd on pmem device, a flush command is send to Qemu over VIRTIO
>   and host side flush/sync is done on backing image file.
> 
>  Changes from RFC v2:
>  - Use aio_worker() to avoid Qemu from hanging with blocking fsync
>    call - Stefan
>  - Use virtio_st*_p() for endianess - Stefan
>  - Correct indentation in qapi/misc.json - Eric
> 
>  Signed-off-by: Pankaj Gupta 
>  ---
>   hw/virtio/Makefile.objs |   3 +
>   hw/virtio/virtio-pci.c  |  44 +
>   hw/virtio/virtio-pci.h  |  14 ++
>   hw/virtio/virtio-pmem.c | 241
>   
>   include/hw/pci/pci.h|   1 +
>   include/hw/virtio/virtio-pmem.h |  42 +
>   include/standard-headers/linux/virtio_ids.h |   1 +
>   qapi/misc.json  |  26 ++-
>   8 files changed, 371 insertions(+), 1 deletion(-)
>   create mode 100644 hw/virtio/virtio-pmem.c
>   create mode 100644 include/hw/virtio/virtio-pmem.h
> 
>  diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
>  index 1b2799cfd8..7f914d45d0 100644
>  --- a/hw/virtio/Makefile.objs
>  +++ b/hw/virtio/Makefile.objs
>  @@ -10,6 +10,9 @@ obj-$(CONFIG_VIRTIO_CRYPTO) += virtio-crypto.o
>   obj-$(call land,$(CONFIG_VIRTIO_CRYPTO),$(CONFIG_VIRTIO_PCI)) +=
>   virtio-crypto-pci.o
>   
>   obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
>  +ifeq ($(CONFIG_MEM_HOTPLUG),y)
>  +obj-$(CONFIG_LINUX) += virtio-pmem.o
>  +endif
>   obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
>   endif
>   
>  diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
>  index 3a01fe90f0..93d3fc05c7 100644
>  --- a/hw/virtio/virtio-pci.c
>  +++ b/hw/virtio/virtio-pci.c
>  @@ -2521,6 +2521,49 @@ static const TypeInfo virtio_rng_pci_info = {
>   .class_init= virtio_rng_pci_class_init,
>   };
>   
>  +/* virtio-pmem-pci */
>  +
>  +static void virtio_pmem_pci_realize(VirtIOPCIProxy *vpci_dev, Error
>  **errp)
>  +{
>  +VirtIOPMEMPCI *vpmem = VIRTIO_PMEM_PCI(vpci_dev);
>  +DeviceState *vdev = DEVICE(>vdev);
>  +
>  +qdev_set_parent_bus(vdev, BUS(_dev->bus));
>  +object_property_set_bool(OBJECT(vdev), true, "realized", errp);
>  +}
>  +
>  +static void virtio_pmem_pci_class_init(ObjectClass *klass, void *data)
>  +{
>  +DeviceClass *dc = DEVICE_CLASS(klass);
>  +VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
>  +PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
>  +k->realize = virtio_pmem_pci_realize;
>  +set_bit(DEVICE_CATEGORY_MISC, dc->categories);
>  +pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
>  +pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_PMEM;
>  +pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
>  +pcidev_k->class_id = PCI_CLASS_OTHERS;
>  +}
>  +
>  +static void virtio_pmem_pci_instance_init(Object *obj)
>  +{
>  +VirtIOPMEMPCI *dev = VIRTIO_PMEM_PCI(obj);
>  +
>  +virtio_instance_init_common(obj, >vdev, sizeof(dev->vdev),
>  +TYPE_VIRTIO_PMEM);
>  +object_property_add_alias(obj, "memdev", OBJECT(>vdev), 
>  "memdev",
>  +  _abort);
>  +}
>  +
>  +static const TypeInfo virtio_pmem_pci_info = {
>  +.name  = TYPE_VIRTIO_PMEM_PCI,
>  +.parent= TYPE_VIRTIO_PCI,
>  +.instance_size = sizeof(VirtIOPMEMPCI),
>  +.instance_init = virtio_pmem_pci_instance_init,
>  +.class_init= virtio_pmem_pci_class_init,
>  +};
>  +
>  +
>   /* virtio-input-pci */
>   
>   static Property virtio_input_pci_properties[] = {
>  @@ -2714,6 +2757,7 @@ static void virtio_pci_register_types(void)
>   type_register_static(_balloon_pci_info);
>   type_register_static(_serial_pci_info);
>   type_register_static(_net_pci_info);
>  +type_register_static(_pmem_pci_info);
>   #ifdef CONFIG_VHOST_SCSI
> 

Re: [Qemu-devel] [RFC v3] qemu: Add virtio pmem device

[Luiz Capitulino]

On Thu, 19 Jul 2018 08:48:19 -0400
Luiz Capitulino  wrote:

> > It will be necessary to define specific constants for virtio-pmem
> > instead of passing errno from the host to guest.  
> 
> Yes, defining your own constants work. But I think the only fsync()
> error that will make sense for the guest is EIO. The other errors
> only make sense for the host.

Just to clarify: of course you'll return an error to guest on any
fsync() error. But maybe you should always return EIO even if the error
was EBADF for example. Or just signal the error with some constant,
and let the guest implementation pick any errno it prefers (this was
my first suggestion).

Re: [Qemu-devel] [RFC v3] qemu: Add virtio pmem device

[Luiz Capitulino]

On Thu, 19 Jul 2018 13:16:35 +0100
Stefan Hajnoczi  wrote:

> On Thu, Jul 19, 2018 at 01:48:13AM -0400, Pankaj Gupta wrote:
> >   
> > >   
> > > >  This patch adds virtio-pmem Qemu device.
> > > > 
> > > >  This device presents memory address range information to guest
> > > >  which is backed by file backend type. It acts like persistent
> > > >  memory device for KVM guest. Guest can perform read and persistent
> > > >  write operations on this memory range with the help of DAX capable
> > > >  filesystem.
> > > > 
> > > >  Persistent guest writes are assured with the help of virtio based
> > > >  flushing interface. When guest userspace space performs fsync on
> > > >  file fd on pmem device, a flush command is send to Qemu over VIRTIO
> > > >  and host side flush/sync is done on backing image file.
> > > > 
> > > > Changes from RFC v2:
> > > > - Use aio_worker() to avoid Qemu from hanging with blocking fsync
> > > >   call - Stefan
> > > > - Use virtio_st*_p() for endianess - Stefan
> > > > - Correct indentation in qapi/misc.json - Eric
> > > > 
> > > > Signed-off-by: Pankaj Gupta 
> > > > ---
> > > >  hw/virtio/Makefile.objs |   3 +
> > > >  hw/virtio/virtio-pci.c  |  44 +
> > > >  hw/virtio/virtio-pci.h  |  14 ++
> > > >  hw/virtio/virtio-pmem.c | 241
> > > >  
> > > >  include/hw/pci/pci.h|   1 +
> > > >  include/hw/virtio/virtio-pmem.h |  42 +
> > > >  include/standard-headers/linux/virtio_ids.h |   1 +
> > > >  qapi/misc.json  |  26 ++-
> > > >  8 files changed, 371 insertions(+), 1 deletion(-)
> > > >  create mode 100644 hw/virtio/virtio-pmem.c
> > > >  create mode 100644 include/hw/virtio/virtio-pmem.h
> > > > 
> > > > diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
> > > > index 1b2799cfd8..7f914d45d0 100644
> > > > --- a/hw/virtio/Makefile.objs
> > > > +++ b/hw/virtio/Makefile.objs
> > > > @@ -10,6 +10,9 @@ obj-$(CONFIG_VIRTIO_CRYPTO) += virtio-crypto.o
> > > >  obj-$(call land,$(CONFIG_VIRTIO_CRYPTO),$(CONFIG_VIRTIO_PCI)) +=
> > > >  virtio-crypto-pci.o
> > > >  
> > > >  obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
> > > > +ifeq ($(CONFIG_MEM_HOTPLUG),y)
> > > > +obj-$(CONFIG_LINUX) += virtio-pmem.o
> > > > +endif
> > > >  obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
> > > >  endif
> > > >  
> > > > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > > > index 3a01fe90f0..93d3fc05c7 100644
> > > > --- a/hw/virtio/virtio-pci.c
> > > > +++ b/hw/virtio/virtio-pci.c
> > > > @@ -2521,6 +2521,49 @@ static const TypeInfo virtio_rng_pci_info = {
> > > >  .class_init= virtio_rng_pci_class_init,
> > > >  };
> > > >  
> > > > +/* virtio-pmem-pci */
> > > > +
> > > > +static void virtio_pmem_pci_realize(VirtIOPCIProxy *vpci_dev, Error
> > > > **errp)
> > > > +{
> > > > +VirtIOPMEMPCI *vpmem = VIRTIO_PMEM_PCI(vpci_dev);
> > > > +DeviceState *vdev = DEVICE(>vdev);
> > > > +
> > > > +qdev_set_parent_bus(vdev, BUS(_dev->bus));
> > > > +object_property_set_bool(OBJECT(vdev), true, "realized", errp);
> > > > +}
> > > > +
> > > > +static void virtio_pmem_pci_class_init(ObjectClass *klass, void *data)
> > > > +{
> > > > +DeviceClass *dc = DEVICE_CLASS(klass);
> > > > +VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > > > +PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > > > +k->realize = virtio_pmem_pci_realize;
> > > > +set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> > > > +pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > > +pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_PMEM;
> > > > +pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
> > > > +pcidev_k->class_id = PCI_CLASS_OTHERS;
> > > > +}
> > > > +
> > > > +static void virtio_pmem_pci_instance_init(Object *obj)
> > > > +{
> > > > +VirtIOPMEMPCI *dev = VIRTIO_PMEM_PCI(obj);
> > > > +
> > > > +virtio_instance_init_common(obj, >vdev, sizeof(dev->vdev),
> > > > +TYPE_VIRTIO_PMEM);
> > > > +object_property_add_alias(obj, "memdev", OBJECT(>vdev), 
> > > > "memdev",
> > > > +  _abort);
> > > > +}
> > > > +
> > > > +static const TypeInfo virtio_pmem_pci_info = {
> > > > +.name  = TYPE_VIRTIO_PMEM_PCI,
> > > > +.parent= TYPE_VIRTIO_PCI,
> > > > +.instance_size = sizeof(VirtIOPMEMPCI),
> > > > +.instance_init = virtio_pmem_pci_instance_init,
> > > > +.class_init= virtio_pmem_pci_class_init,
> > > > +};
> > > > +
> > > > +
> > > >  /* virtio-input-pci */
> > > >  
> > > >  static Property virtio_input_pci_properties[] = {
> > > > @@ -2714,6 +2757,7 @@ static void virtio_pci_register_types(void)
> > > >  type_register_static(_balloon_pci_info);
> > > >  type_register_static(_serial_pci_info);
> > > >  type_register_static(_net_pci_info);
> > > > +

Re: [Qemu-devel] [RFC v3] qemu: Add virtio pmem device

[Luiz Capitulino]

On Thu, 19 Jul 2018 01:48:13 -0400 (EDT)
Pankaj Gupta  wrote:

> >   
> > >  This patch adds virtio-pmem Qemu device.
> > > 
> > >  This device presents memory address range information to guest
> > >  which is backed by file backend type. It acts like persistent
> > >  memory device for KVM guest. Guest can perform read and persistent
> > >  write operations on this memory range with the help of DAX capable
> > >  filesystem.
> > > 
> > >  Persistent guest writes are assured with the help of virtio based
> > >  flushing interface. When guest userspace space performs fsync on
> > >  file fd on pmem device, a flush command is send to Qemu over VIRTIO
> > >  and host side flush/sync is done on backing image file.
> > > 
> > > Changes from RFC v2:
> > > - Use aio_worker() to avoid Qemu from hanging with blocking fsync
> > >   call - Stefan
> > > - Use virtio_st*_p() for endianess - Stefan
> > > - Correct indentation in qapi/misc.json - Eric
> > > 
> > > Signed-off-by: Pankaj Gupta 
> > > ---
> > >  hw/virtio/Makefile.objs |   3 +
> > >  hw/virtio/virtio-pci.c  |  44 +
> > >  hw/virtio/virtio-pci.h  |  14 ++
> > >  hw/virtio/virtio-pmem.c | 241
> > >  
> > >  include/hw/pci/pci.h|   1 +
> > >  include/hw/virtio/virtio-pmem.h |  42 +
> > >  include/standard-headers/linux/virtio_ids.h |   1 +
> > >  qapi/misc.json  |  26 ++-
> > >  8 files changed, 371 insertions(+), 1 deletion(-)
> > >  create mode 100644 hw/virtio/virtio-pmem.c
> > >  create mode 100644 include/hw/virtio/virtio-pmem.h
> > > 
> > > diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
> > > index 1b2799cfd8..7f914d45d0 100644
> > > --- a/hw/virtio/Makefile.objs
> > > +++ b/hw/virtio/Makefile.objs
> > > @@ -10,6 +10,9 @@ obj-$(CONFIG_VIRTIO_CRYPTO) += virtio-crypto.o
> > >  obj-$(call land,$(CONFIG_VIRTIO_CRYPTO),$(CONFIG_VIRTIO_PCI)) +=
> > >  virtio-crypto-pci.o
> > >  
> > >  obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
> > > +ifeq ($(CONFIG_MEM_HOTPLUG),y)
> > > +obj-$(CONFIG_LINUX) += virtio-pmem.o
> > > +endif
> > >  obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
> > >  endif
> > >  
> > > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > > index 3a01fe90f0..93d3fc05c7 100644
> > > --- a/hw/virtio/virtio-pci.c
> > > +++ b/hw/virtio/virtio-pci.c
> > > @@ -2521,6 +2521,49 @@ static const TypeInfo virtio_rng_pci_info = {
> > >  .class_init= virtio_rng_pci_class_init,
> > >  };
> > >  
> > > +/* virtio-pmem-pci */
> > > +
> > > +static void virtio_pmem_pci_realize(VirtIOPCIProxy *vpci_dev, Error
> > > **errp)
> > > +{
> > > +VirtIOPMEMPCI *vpmem = VIRTIO_PMEM_PCI(vpci_dev);
> > > +DeviceState *vdev = DEVICE(>vdev);
> > > +
> > > +qdev_set_parent_bus(vdev, BUS(_dev->bus));
> > > +object_property_set_bool(OBJECT(vdev), true, "realized", errp);
> > > +}
> > > +
> > > +static void virtio_pmem_pci_class_init(ObjectClass *klass, void *data)
> > > +{
> > > +DeviceClass *dc = DEVICE_CLASS(klass);
> > > +VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> > > +PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> > > +k->realize = virtio_pmem_pci_realize;
> > > +set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> > > +pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> > > +pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_PMEM;
> > > +pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
> > > +pcidev_k->class_id = PCI_CLASS_OTHERS;
> > > +}
> > > +
> > > +static void virtio_pmem_pci_instance_init(Object *obj)
> > > +{
> > > +VirtIOPMEMPCI *dev = VIRTIO_PMEM_PCI(obj);
> > > +
> > > +virtio_instance_init_common(obj, >vdev, sizeof(dev->vdev),
> > > +TYPE_VIRTIO_PMEM);
> > > +object_property_add_alias(obj, "memdev", OBJECT(>vdev), 
> > > "memdev",
> > > +  _abort);
> > > +}
> > > +
> > > +static const TypeInfo virtio_pmem_pci_info = {
> > > +.name  = TYPE_VIRTIO_PMEM_PCI,
> > > +.parent= TYPE_VIRTIO_PCI,
> > > +.instance_size = sizeof(VirtIOPMEMPCI),
> > > +.instance_init = virtio_pmem_pci_instance_init,
> > > +.class_init= virtio_pmem_pci_class_init,
> > > +};
> > > +
> > > +
> > >  /* virtio-input-pci */
> > >  
> > >  static Property virtio_input_pci_properties[] = {
> > > @@ -2714,6 +2757,7 @@ static void virtio_pci_register_types(void)
> > >  type_register_static(_balloon_pci_info);
> > >  type_register_static(_serial_pci_info);
> > >  type_register_static(_net_pci_info);
> > > +type_register_static(_pmem_pci_info);
> > >  #ifdef CONFIG_VHOST_SCSI
> > >  type_register_static(_scsi_pci_info);
> > >  #endif
> > > diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> > > index 813082b0d7..fe74fcad3f 100644
> > > --- a/hw/virtio/virtio-pci.h
> > > +++ 

Re: [Qemu-devel] [RFC v3] qemu: Add virtio pmem device

[Luiz Capitulino]

On Fri, 13 Jul 2018 13:22:32 +0530
Pankaj Gupta  wrote:

>  This patch adds virtio-pmem Qemu device.
> 
>  This device presents memory address range information to guest
>  which is backed by file backend type. It acts like persistent
>  memory device for KVM guest. Guest can perform read and persistent
>  write operations on this memory range with the help of DAX capable
>  filesystem.
> 
>  Persistent guest writes are assured with the help of virtio based
>  flushing interface. When guest userspace space performs fsync on
>  file fd on pmem device, a flush command is send to Qemu over VIRTIO
>  and host side flush/sync is done on backing image file.
> 
> Changes from RFC v2:
> - Use aio_worker() to avoid Qemu from hanging with blocking fsync
>   call - Stefan
> - Use virtio_st*_p() for endianess - Stefan
> - Correct indentation in qapi/misc.json - Eric
> 
> Signed-off-by: Pankaj Gupta 
> ---
>  hw/virtio/Makefile.objs |   3 +
>  hw/virtio/virtio-pci.c  |  44 +
>  hw/virtio/virtio-pci.h  |  14 ++
>  hw/virtio/virtio-pmem.c | 241 
> 
>  include/hw/pci/pci.h|   1 +
>  include/hw/virtio/virtio-pmem.h |  42 +
>  include/standard-headers/linux/virtio_ids.h |   1 +
>  qapi/misc.json  |  26 ++-
>  8 files changed, 371 insertions(+), 1 deletion(-)
>  create mode 100644 hw/virtio/virtio-pmem.c
>  create mode 100644 include/hw/virtio/virtio-pmem.h
> 
> diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
> index 1b2799cfd8..7f914d45d0 100644
> --- a/hw/virtio/Makefile.objs
> +++ b/hw/virtio/Makefile.objs
> @@ -10,6 +10,9 @@ obj-$(CONFIG_VIRTIO_CRYPTO) += virtio-crypto.o
>  obj-$(call land,$(CONFIG_VIRTIO_CRYPTO),$(CONFIG_VIRTIO_PCI)) += 
> virtio-crypto-pci.o
>  
>  obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
> +ifeq ($(CONFIG_MEM_HOTPLUG),y)
> +obj-$(CONFIG_LINUX) += virtio-pmem.o
> +endif
>  obj-$(CONFIG_VHOST_VSOCK) += vhost-vsock.o
>  endif
>  
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 3a01fe90f0..93d3fc05c7 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -2521,6 +2521,49 @@ static const TypeInfo virtio_rng_pci_info = {
>  .class_init= virtio_rng_pci_class_init,
>  };
>  
> +/* virtio-pmem-pci */
> +
> +static void virtio_pmem_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> +{
> +VirtIOPMEMPCI *vpmem = VIRTIO_PMEM_PCI(vpci_dev);
> +DeviceState *vdev = DEVICE(>vdev);
> +
> +qdev_set_parent_bus(vdev, BUS(_dev->bus));
> +object_property_set_bool(OBJECT(vdev), true, "realized", errp);
> +}
> +
> +static void virtio_pmem_pci_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> +PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> +k->realize = virtio_pmem_pci_realize;
> +set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> +pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> +pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_PMEM;
> +pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
> +pcidev_k->class_id = PCI_CLASS_OTHERS;
> +}
> +
> +static void virtio_pmem_pci_instance_init(Object *obj)
> +{
> +VirtIOPMEMPCI *dev = VIRTIO_PMEM_PCI(obj);
> +
> +virtio_instance_init_common(obj, >vdev, sizeof(dev->vdev),
> +TYPE_VIRTIO_PMEM);
> +object_property_add_alias(obj, "memdev", OBJECT(>vdev), "memdev",
> +  _abort);
> +}
> +
> +static const TypeInfo virtio_pmem_pci_info = {
> +.name  = TYPE_VIRTIO_PMEM_PCI,
> +.parent= TYPE_VIRTIO_PCI,
> +.instance_size = sizeof(VirtIOPMEMPCI),
> +.instance_init = virtio_pmem_pci_instance_init,
> +.class_init= virtio_pmem_pci_class_init,
> +};
> +
> +
>  /* virtio-input-pci */
>  
>  static Property virtio_input_pci_properties[] = {
> @@ -2714,6 +2757,7 @@ static void virtio_pci_register_types(void)
>  type_register_static(_balloon_pci_info);
>  type_register_static(_serial_pci_info);
>  type_register_static(_net_pci_info);
> +type_register_static(_pmem_pci_info);
>  #ifdef CONFIG_VHOST_SCSI
>  type_register_static(_scsi_pci_info);
>  #endif
> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> index 813082b0d7..fe74fcad3f 100644
> --- a/hw/virtio/virtio-pci.h
> +++ b/hw/virtio/virtio-pci.h
> @@ -19,6 +19,7 @@
>  #include "hw/virtio/virtio-blk.h"
>  #include "hw/virtio/virtio-net.h"
>  #include "hw/virtio/virtio-rng.h"
> +#include "hw/virtio/virtio-pmem.h"
>  #include "hw/virtio/virtio-serial.h"
>  #include "hw/virtio/virtio-scsi.h"
>  #include "hw/virtio/virtio-balloon.h"
> @@ -57,6 +58,7 @@ typedef struct VirtIOInputHostPCI VirtIOInputHostPCI;
>  typedef struct VirtIOGPUPCI VirtIOGPUPCI;
>  typedef struct VHostVSockPCI VHostVSockPCI;
>  typedef struct 

Re: [Qemu-devel] [RFC v3 2/2] virtio-pmem: Add virtio pmem driver

[Luiz Capitulino]

On Mon, 16 Jul 2018 07:46:30 -0400 (EDT)
Pankaj Gupta  wrote:

> >   
> > > This patch adds virtio-pmem driver for KVM guest.
> > > 
> > > Guest reads the persistent memory range information from Qemu over
> > > VIRTIO and registers it on nvdimm_bus. It also creates a nd_region
> > > object with the persistent memory range information so that existing
> > > 'nvdimm/pmem' driver can reserve this into system memory map. This way
> > > 'virtio-pmem' driver uses existing functionality of pmem driver to
> > > register persistent memory compatible for DAX capable filesystems.
> > > 
> > > This also provides function to perform guest flush over VIRTIO from
> > > 'pmem' driver when userspace performs flush on DAX memory range.
> > > 
> > > Signed-off-by: Pankaj Gupta 
> > > ---
> > >  drivers/virtio/Kconfig   |   9 ++
> > >  drivers/virtio/Makefile  |   1 +
> > >  drivers/virtio/virtio_pmem.c | 190
> > >  +++
> > >  include/linux/virtio_pmem.h  |  44 +
> > >  include/uapi/linux/virtio_ids.h  |   1 +
> > >  include/uapi/linux/virtio_pmem.h |  40 +
> > >  6 files changed, 285 insertions(+)
> > >  create mode 100644 drivers/virtio/virtio_pmem.c
> > >  create mode 100644 include/linux/virtio_pmem.h
> > >  create mode 100644 include/uapi/linux/virtio_pmem.h
> > > 
> > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > index 3589764..a331e23 100644
> > > --- a/drivers/virtio/Kconfig
> > > +++ b/drivers/virtio/Kconfig
> > > @@ -42,6 +42,15 @@ config VIRTIO_PCI_LEGACY
> > >  
> > > If unsure, say Y.
> > >  
> > > +config VIRTIO_PMEM
> > > + tristate "Support for virtio pmem driver"
> > > + depends on VIRTIO
> > > + help
> > > + This driver provides support for virtio based flushing interface
> > > + for persistent memory range.
> > > +
> > > + If unsure, say M.
> > > +
> > >  config VIRTIO_BALLOON
> > >   tristate "Virtio balloon driver"
> > >   depends on VIRTIO
> > > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > > index 3a2b5c5..cbe91c6 100644
> > > --- a/drivers/virtio/Makefile
> > > +++ b/drivers/virtio/Makefile
> > > @@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
> > >  virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
> > >  obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
> > >  obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
> > > +obj-$(CONFIG_VIRTIO_PMEM) += virtio_pmem.o
> > > diff --git a/drivers/virtio/virtio_pmem.c b/drivers/virtio/virtio_pmem.c
> > > new file mode 100644
> > > index 000..6200b5e
> > > --- /dev/null
> > > +++ b/drivers/virtio/virtio_pmem.c
> > > @@ -0,0 +1,190 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * virtio_pmem.c: Virtio pmem Driver
> > > + *
> > > + * Discovers persistent memory range information
> > > + * from host and provides a virtio based flushing
> > > + * interface.
> > > + */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +static struct virtio_device_id id_table[] = {
> > > + { VIRTIO_ID_PMEM, VIRTIO_DEV_ANY_ID },
> > > + { 0 },
> > > +};
> > > +
> > > + /* The interrupt handler */
> > > +static void host_ack(struct virtqueue *vq)
> > > +{
> > > + unsigned int len;
> > > + unsigned long flags;
> > > + struct virtio_pmem_request *req;
> > > + struct virtio_pmem *vpmem = vq->vdev->priv;
> > > +
> > > + spin_lock_irqsave(>pmem_lock, flags);
> > > + while ((req = virtqueue_get_buf(vq, )) != NULL) {
> > > + req->done = true;
> > > + wake_up(>acked);
> > > + }
> > > + spin_unlock_irqrestore(>pmem_lock, flags);  
> > 
> > Honest question: why do you need to disable interrupts here?  
> 
> To avoid interrupt for VQ trying to take same spinlock already taken by 
> process 
> context and resulting in deadlock. Looks like interrupts are already disabled 
> in 
> function call, see [1]. But still to protect with any future work. 
> 
> [1]
>vp_interrupt
>vp_vring_interrupt
>vring_interrupt

I think you're right, and I think I may have caused some confusion. See
below.

> >   
> > > +}
> > > + /* Initialize virt queue */
> > > +static int init_vq(struct virtio_pmem *vpmem)
> > > +{
> > > + struct virtqueue *vq;
> > > +
> > > + /* single vq */
> > > + vpmem->req_vq = vq = virtio_find_single_vq(vpmem->vdev,
> > > + host_ack, "flush_queue");
> > > + if (IS_ERR(vq))
> > > + return PTR_ERR(vq);
> > > + spin_lock_init(>pmem_lock);
> > > +
> > > + return 0;
> > > +};
> > > +
> > > + /* The request submission function */
> > > +static int virtio_pmem_flush(struct device *dev)
> > > +{
> > > + int err;
> > > + unsigned long flags;
> > > + struct scatterlist *sgs[2], sg, ret;
> > > + struct virtio_device *vdev = dev_to_virtio(dev->parent->parent);
> > > + struct virtio_pmem *vpmem = vdev->priv;
> > > + struct virtio_pmem_request *req = kmalloc(sizeof(*req), GFP_KERNEL);  
> > 
> > Not checking kmalloc() return.  
> 
> Will add it.
> >   

Re: [Qemu-devel] [RFC v3 2/2] virtio-pmem: Add virtio pmem driver

[Luiz Capitulino]

On Fri, 13 Jul 2018 13:22:31 +0530
Pankaj Gupta  wrote:

> This patch adds virtio-pmem driver for KVM guest.
> 
> Guest reads the persistent memory range information from Qemu over 
> VIRTIO and registers it on nvdimm_bus. It also creates a nd_region 
> object with the persistent memory range information so that existing 
> 'nvdimm/pmem' driver can reserve this into system memory map. This way 
> 'virtio-pmem' driver uses existing functionality of pmem driver to 
> register persistent memory compatible for DAX capable filesystems.
> 
> This also provides function to perform guest flush over VIRTIO from 
> 'pmem' driver when userspace performs flush on DAX memory range.
> 
> Signed-off-by: Pankaj Gupta 
> ---
>  drivers/virtio/Kconfig   |   9 ++
>  drivers/virtio/Makefile  |   1 +
>  drivers/virtio/virtio_pmem.c | 190 
> +++
>  include/linux/virtio_pmem.h  |  44 +
>  include/uapi/linux/virtio_ids.h  |   1 +
>  include/uapi/linux/virtio_pmem.h |  40 +
>  6 files changed, 285 insertions(+)
>  create mode 100644 drivers/virtio/virtio_pmem.c
>  create mode 100644 include/linux/virtio_pmem.h
>  create mode 100644 include/uapi/linux/virtio_pmem.h
> 
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 3589764..a331e23 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -42,6 +42,15 @@ config VIRTIO_PCI_LEGACY
>  
> If unsure, say Y.
>  
> +config VIRTIO_PMEM
> + tristate "Support for virtio pmem driver"
> + depends on VIRTIO
> + help
> + This driver provides support for virtio based flushing interface
> + for persistent memory range.
> +
> + If unsure, say M.
> +
>  config VIRTIO_BALLOON
>   tristate "Virtio balloon driver"
>   depends on VIRTIO
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index 3a2b5c5..cbe91c6 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
>  virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
>  obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
>  obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
> +obj-$(CONFIG_VIRTIO_PMEM) += virtio_pmem.o
> diff --git a/drivers/virtio/virtio_pmem.c b/drivers/virtio/virtio_pmem.c
> new file mode 100644
> index 000..6200b5e
> --- /dev/null
> +++ b/drivers/virtio/virtio_pmem.c
> @@ -0,0 +1,190 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * virtio_pmem.c: Virtio pmem Driver
> + *
> + * Discovers persistent memory range information
> + * from host and provides a virtio based flushing
> + * interface.
> + */
> +#include 
> +#include 
> +#include 
> +
> +static struct virtio_device_id id_table[] = {
> + { VIRTIO_ID_PMEM, VIRTIO_DEV_ANY_ID },
> + { 0 },
> +};
> +
> + /* The interrupt handler */
> +static void host_ack(struct virtqueue *vq)
> +{
> + unsigned int len;
> + unsigned long flags;
> + struct virtio_pmem_request *req;
> + struct virtio_pmem *vpmem = vq->vdev->priv;
> +
> + spin_lock_irqsave(>pmem_lock, flags);
> + while ((req = virtqueue_get_buf(vq, )) != NULL) {
> + req->done = true;
> + wake_up(>acked);
> + }
> + spin_unlock_irqrestore(>pmem_lock, flags);

Honest question: why do you need to disable interrupts here?

> +}
> + /* Initialize virt queue */
> +static int init_vq(struct virtio_pmem *vpmem)
> +{
> + struct virtqueue *vq;
> +
> + /* single vq */
> + vpmem->req_vq = vq = virtio_find_single_vq(vpmem->vdev,
> + host_ack, "flush_queue");
> + if (IS_ERR(vq))
> + return PTR_ERR(vq);
> + spin_lock_init(>pmem_lock);
> +
> + return 0;
> +};
> +
> + /* The request submission function */
> +static int virtio_pmem_flush(struct device *dev)
> +{
> + int err;
> + unsigned long flags;
> + struct scatterlist *sgs[2], sg, ret;
> + struct virtio_device *vdev = dev_to_virtio(dev->parent->parent);
> + struct virtio_pmem *vpmem = vdev->priv;
> + struct virtio_pmem_request *req = kmalloc(sizeof(*req), GFP_KERNEL);

Not checking kmalloc() return.

> +
> + req->done = false;
> + init_waitqueue_head(>acked);
> + spin_lock_irqsave(>pmem_lock, flags);

Why do you need spin_lock_irqsave()? There are two points consider:

1. Will virtio_pmem_flush() ever be called with interrupts disabled?
   If yes, then it's broken since you should be using GFP_ATOMIC in the
   kmalloc() call and you can't call wait_event()

2. If virtio_pmem_flush() is never called with interrupts disabled, do
   you really need to disable interrupts? If yes, why?

Another point to consider is whether or not virtio_pmem_flush()
can be called from atomic context. nvdimm_flush() itself is called
from a few atomic sites, but I can't tell if virtio_pmem_flush()
will ever be called from those sites. If it can be called atomic
context, then item 1 applies here. 

Re: [Qemu-devel] [RFC v3 1/2] libnvdimm: Add flush callback for virtio pmem

[Luiz Capitulino]

On Fri, 13 Jul 2018 13:22:30 +0530
Pankaj Gupta  wrote:

> This patch adds functionality to perform flush from guest to host
> over VIRTIO. We are registering a callback based on 'nd_region' type.
> As virtio_pmem driver requires this special flush interface, for rest
> of the region types we are registering existing flush function.
> Also report the error returned by virtio flush interface.

This patch doesn't apply against latest upstream. A few more comments
below.

> 
> Signed-off-by: Pankaj Gupta 
> ---
>  drivers/nvdimm/nd.h  |  1 +
>  drivers/nvdimm/pmem.c|  4 ++--
>  drivers/nvdimm/region_devs.c | 24 ++--
>  include/linux/libnvdimm.h|  5 -
>  4 files changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
> index 32e0364..1b62f79 100644
> --- a/drivers/nvdimm/nd.h
> +++ b/drivers/nvdimm/nd.h
> @@ -159,6 +159,7 @@ struct nd_region {
>   struct badblocks bb;
>   struct nd_interleave_set *nd_set;
>   struct nd_percpu_lane __percpu *lane;
> + int (*flush)(struct device *dev);
>   struct nd_mapping mapping[0];
>  };
>  
> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
> index 9d71492..29fd2cd 100644
> --- a/drivers/nvdimm/pmem.c
> +++ b/drivers/nvdimm/pmem.c
> @@ -180,7 +180,7 @@ static blk_qc_t pmem_make_request(struct request_queue 
> *q, struct bio *bio)
>   struct nd_region *nd_region = to_region(pmem);
>  
>   if (bio->bi_opf & REQ_FLUSH)
> - nvdimm_flush(nd_region);
> + bio->bi_status = nvdimm_flush(nd_region);
>  
>   do_acct = nd_iostat_start(bio, );
>   bio_for_each_segment(bvec, bio, iter) {
> @@ -196,7 +196,7 @@ static blk_qc_t pmem_make_request(struct request_queue 
> *q, struct bio *bio)
>   nd_iostat_end(bio, start);
>  
>   if (bio->bi_opf & REQ_FUA)
> - nvdimm_flush(nd_region);
> + bio->bi_status = nvdimm_flush(nd_region);
>  
>   bio_endio(bio);
>   return BLK_QC_T_NONE;
> diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
> index a612be6..124aae7 100644
> --- a/drivers/nvdimm/region_devs.c
> +++ b/drivers/nvdimm/region_devs.c
> @@ -1025,6 +1025,7 @@ static struct nd_region *nd_region_create(struct 
> nvdimm_bus *nvdimm_bus,
>   dev->of_node = ndr_desc->of_node;
>   nd_region->ndr_size = resource_size(ndr_desc->res);
>   nd_region->ndr_start = ndr_desc->res->start;
> + nd_region->flush = ndr_desc->flush;
>   nd_device_register(dev);
>  
>   return nd_region;
> @@ -1065,13 +1066,10 @@ struct nd_region 
> *nvdimm_volatile_region_create(struct nvdimm_bus *nvdimm_bus,
>  }
>  EXPORT_SYMBOL_GPL(nvdimm_volatile_region_create);
>  
> -/**
> - * nvdimm_flush - flush any posted write queues between the cpu and pmem 
> media
> - * @nd_region: blk or interleaved pmem region
> - */
> -void nvdimm_flush(struct nd_region *nd_region)
> +void pmem_flush(struct device *dev)
>  {
> - struct nd_region_data *ndrd = dev_get_drvdata(_region->dev);
> + struct nd_region_data *ndrd = dev_get_drvdata(dev);
> + struct nd_region *nd_region = to_nd_region(dev);
>   int i, idx;
>  
>   /*
> @@ -1094,6 +1092,20 @@ void nvdimm_flush(struct nd_region *nd_region)
>   writeq(1, ndrd_get_flush_wpq(ndrd, i, idx));
>   wmb();
>  }
> +
> +/**
> + * nvdimm_flush - flush any posted write queues between the cpu and pmem 
> media
> + * @nd_region: blk or interleaved pmem region
> + */
> +int nvdimm_flush(struct nd_region *nd_region)
> +{
> + if (nd_region->flush)
> + return(nd_region->flush(_region->dev));
> +
> + pmem_flush(_region->dev);

IMHO, a better way of doing this would be to allow nvdimm_flush() to
be overridden. That is, in nd_region_create() you set nd_region->flush
to the original nvdimm_flush() if ndr_desc->flush is NULL. And then
always call nd_region->flush() where nvdimm_flush() is called today.

> +
> + return 0;
> +}
>  EXPORT_SYMBOL_GPL(nvdimm_flush);
>  
>  /**
> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
> index 097072c..33b617f 100644
> --- a/include/linux/libnvdimm.h
> +++ b/include/linux/libnvdimm.h
> @@ -126,6 +126,7 @@ struct nd_region_desc {
>   int numa_node;
>   unsigned long flags;
>   struct device_node *of_node;
> + int (*flush)(struct device *dev);
>  };
>  
>  struct device;
> @@ -201,7 +202,9 @@ unsigned long nd_blk_memremap_flags(struct nd_blk_region 
> *ndbr);
>  unsigned int nd_region_acquire_lane(struct nd_region *nd_region);
>  void nd_region_release_lane(struct nd_region *nd_region, unsigned int lane);
>  u64 nd_fletcher64(void *addr, size_t len, bool le);
> -void nvdimm_flush(struct nd_region *nd_region);
> +int nvdimm_flush(struct nd_region *nd_region);
> +void pmem_set_flush(struct nd_region *nd_region, void (*flush)
> + (struct device *));

It seems pmem_set_flush() doesn't exist.

>  int 

Re: [Qemu-devel] [PATCH 3/3] qmp: add architecture specific cpu data for query-cpus-fast

[Luiz Capitulino]

On Tue, 13 Feb 2018 13:30:02 +0100
Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:

> On 12.02.2018 19:15, Luiz Capitulino wrote:
> > On Mon, 12 Feb 2018 13:14:32 +0100
> > Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
> >   
> >> -{ 'struct': 'CpuInfoFast',
> >> -  'data': {'cpu-index': 'int', 'qom-path': 'str',
> >> -   'thread-id': 'int', '*props': 'CpuInstanceProperties' } }
> >> +{ 'union': 'CpuInfoFast',
> >> +  'base': {'cpu-index': 'int', 'qom-path': 'str',
> >> +   'thread-id': 'int', '*props': 'CpuInstanceProperties',
> >> +   'arch': 'CpuInfoArch' },
> >> +  'discriminator': 'arch',
> >> +  'data': { 'x86': 'CpuInfoOther',
> >> +'sparc': 'CpuInfoOther',
> >> +'ppc': 'CpuInfoOther',
> >> +'mips': 'CpuInfoOther',
> >> +'tricore': 'CpuInfoOther',
> >> +'s390': 'CpuInfoS390Fast',
> >> +'other': 'CpuInfoOther' } }  
> > 
> > Consider this a minor comment (and QMP maintainers can give a much
> > better advice than me), but I think this arch list has problems. For
> > one thing, it's incomplete. And the second problem is the 'other'
> > field. What happens when QEMU starts supporting a new arch? 'other'
> > becomes the new arch. Is this compatible? I don't know.  
> This seems to be the customary approach, see
> https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg01986.html
> > 
> > I don't know if this would work with the QAPI, but you could have
> > a '*arch-data' field in the CpuInfoFast definition, like:
> > 
> > 'data': { ..., '*arch-data': 'CpuInfoFastArchData' }
> > 
> > where 'CpuInfoFastArchData' is defined by each arch that supports
> > the field. An arch supporting the field could also export a
> > query_cpus_fast_arch() function, which is called by qmp_query_cpus_fast().
> >   
> I had it like this in my first reply to your initial patch. However,
> that adds an additional hierarchy level in the return data. This
> prevents clients like libvirt to reuse the data extraction code when
> they switch over to using query-cpus-fast.

OK, fair enough.

Re: [Qemu-devel] [PATCH 3/3] qmp: add architecture specific cpu data for query-cpus-fast

[Luiz Capitulino]

On Mon, 12 Feb 2018 13:14:32 +0100
Viktor Mihajlovski  wrote:

> -{ 'struct': 'CpuInfoFast',
> -  'data': {'cpu-index': 'int', 'qom-path': 'str',
> -   'thread-id': 'int', '*props': 'CpuInstanceProperties' } }
> +{ 'union': 'CpuInfoFast',
> +  'base': {'cpu-index': 'int', 'qom-path': 'str',
> +   'thread-id': 'int', '*props': 'CpuInstanceProperties',
> +   'arch': 'CpuInfoArch' },
> +  'discriminator': 'arch',
> +  'data': { 'x86': 'CpuInfoOther',
> +'sparc': 'CpuInfoOther',
> +'ppc': 'CpuInfoOther',
> +'mips': 'CpuInfoOther',
> +'tricore': 'CpuInfoOther',
> +'s390': 'CpuInfoS390Fast',
> +'other': 'CpuInfoOther' } }

Consider this a minor comment (and QMP maintainers can give a much
better advice than me), but I think this arch list has problems. For
one thing, it's incomplete. And the second problem is the 'other'
field. What happens when QEMU starts supporting a new arch? 'other'
becomes the new arch. Is this compatible? I don't know.

I don't know if this would work with the QAPI, but you could have
a '*arch-data' field in the CpuInfoFast definition, like:

'data': { ..., '*arch-data': 'CpuInfoFastArchData' }

where 'CpuInfoFastArchData' is defined by each arch that supports
the field. An arch supporting the field could also export a
query_cpus_fast_arch() function, which is called by qmp_query_cpus_fast().

Re: [Qemu-devel] [PATCH 1/3] qmp: expose s390-specific CPU info

[Luiz Capitulino]

On Mon, 12 Feb 2018 13:14:30 +0100
Viktor Mihajlovski  wrote:

> Presently s390x is the only architecture not exposing specific
> CPU information via QMP query-cpus. Upstream discussion has shown
> that it could make sense to report the architecture specific CPU
> state, e.g. to detect that a CPU has been stopped.
> 
> With this change the output of query-cpus will look like this on
> s390:
> 
>[
>  {"arch": "s390", "current": true,
>   "props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
>   "qom_path": "/machine/unattached/device[0]",
>   "halted": false, "thread_id": 63115},
>  {"arch": "s390", "current": false,
>   "props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
>   "qom_path": "/machine/unattached/device[1]",
>   "halted": true, "thread_id": 63116}
>]

We're adding the same information to query-cpus-fast. Why do we
need to duplicate this into query-cpus? Do you plan to keep using
query-cpus? If yes, why?

Libvirt for one, should move away from it. We don't want to run
into the risk of having the same issue we had with x86 in other
archs.

> 
> Signed-off-by: Viktor Mihajlovski 
> Acked-by: Eric Blake 
> ---
>  cpus.c |  6 ++
>  hmp.c  |  4 
>  hw/intc/s390_flic.c|  4 ++--
>  hw/s390x/s390-virtio-ccw.c |  2 +-
>  qapi-schema.json   | 28 +++-
>  target/s390x/cpu.c | 24 
>  target/s390x/cpu.h |  7 ++-
>  target/s390x/kvm.c |  8 
>  target/s390x/sigp.c| 38 +++---
>  9 files changed, 77 insertions(+), 44 deletions(-)
> 
> diff --git a/cpus.c b/cpus.c
> index f298b65..6006931 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -2100,6 +2100,9 @@ CpuInfoList *qmp_query_cpus(Error **errp)
>  #elif defined(TARGET_TRICORE)
>  TriCoreCPU *tricore_cpu = TRICORE_CPU(cpu);
>  CPUTriCoreState *env = _cpu->env;
> +#elif defined(TARGET_S390X)
> +S390CPU *s390_cpu = S390_CPU(cpu);
> +CPUS390XState *env = _cpu->env;
>  #endif
>  
>  cpu_synchronize_state(cpu);
> @@ -2127,6 +2130,9 @@ CpuInfoList *qmp_query_cpus(Error **errp)
>  #elif defined(TARGET_TRICORE)
>  info->value->arch = CPU_INFO_ARCH_TRICORE;
>  info->value->u.tricore.PC = env->PC;
> +#elif defined(TARGET_S390X)
> +info->value->arch = CPU_INFO_ARCH_S390;
> +info->value->u.s390.cpu_state = env->cpu_state;
>  #else
>  info->value->arch = CPU_INFO_ARCH_OTHER;
>  #endif
> diff --git a/hmp.c b/hmp.c
> index 7870d6a..a6b94b7 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -392,6 +392,10 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict)
>  case CPU_INFO_ARCH_TRICORE:
>  monitor_printf(mon, " PC=0x%016" PRIx64, 
> cpu->value->u.tricore.PC);
>  break;
> +case CPU_INFO_ARCH_S390:
> +monitor_printf(mon, " state=%s",
> +   CpuS390State_str(cpu->value->u.s390.cpu_state));
> +break;
>  default:
>  break;
>  }
> diff --git a/hw/intc/s390_flic.c b/hw/intc/s390_flic.c
> index a85a149..5f8168f 100644
> --- a/hw/intc/s390_flic.c
> +++ b/hw/intc/s390_flic.c
> @@ -192,8 +192,8 @@ static void qemu_s390_flic_notify(uint32_t type)
>  cs->interrupt_request |= CPU_INTERRUPT_HARD;
>  
>  /* ignore CPUs that are not sleeping */
> -if (s390_cpu_get_state(cpu) != CPU_STATE_OPERATING &&
> -s390_cpu_get_state(cpu) != CPU_STATE_LOAD) {
> +if (s390_cpu_get_state(cpu) != S390_CPU_STATE_OPERATING &&
> +s390_cpu_get_state(cpu) != S390_CPU_STATE_LOAD) {
>  continue;
>  }
>  
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 4abbe89..4d0c3de 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -368,7 +368,7 @@ static void s390_machine_reset(void)
>  
>  /* all cpus are stopped - configure and start the ipl cpu only */
>  s390_ipl_prepare_cpu(ipl_cpu);
> -s390_cpu_set_state(CPU_STATE_OPERATING, ipl_cpu);
> +s390_cpu_set_state(S390_CPU_STATE_OPERATING, ipl_cpu);
>  }
>  
>  static void s390_machine_device_plug(HotplugHandler *hotplug_dev,
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 5c06745..66e0927 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -410,10 +410,12 @@
>  # An enumeration of cpu types that enable additional information during
>  # @query-cpus.
>  #
> +# @s390: since 2.12
> +#
>  # Since: 2.6
>  ##
>  { 'enum': 'CpuInfoArch',
> -  'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
> +  'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 's390', 'other' ] }
>  
>  ##
>  # @CpuInfo:
> @@ -452,6 +454,7 @@
>  'ppc': 'CpuInfoPPC',
>  'mips': 'CpuInfoMIPS',
>  'tricore': 

Re: [Qemu-devel] [PATCH v2] qmp: add query-cpus-fast

[Luiz Capitulino]

On Fri, 9 Feb 2018 15:50:00 +0100
Viktor Mihajlovski  wrote:

> On 09.02.2018 15:27, Eduardo Habkost wrote:
> [...]
> >> I'm keeping it mainly for s390. Viktor, libvirt is still using
> >> this field in s390, no?
> >>
> >> Dropping halted and having management software still using query-cpus
> >> because of halted would be a total failure of query-cpus-fast.  
> > 
> > If I understood correctly, the CpuInfoS390::cpu_state field added
> > by Viktor in another patch[1] would replace "halted" for the s390
> > case.  
> Right, CPUState.halted is derived from CPUS390XState.cpu_state on s390:
> A cpu_state of CPU_STATE_STOPPED or CPU_STATE_CHECK_STOPPED results in
> halted = true. This derivation can be done by libvirt for s390.
> > 
> > I'm assuming QEMU will be able to return that field without
> > interrupting the VCPUs.  Viktor, is that correct?
> > 
> > [1] https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02032.html
> >   
> That's correct.
> >>  
>  Also, the code that sets/clears cpu->halted is target-specific,
>  so I wouldn't be so sure that simply checking for
>  !kvm_irqchip_in_kernel() is enough on all targets.  
> >>
> >> I checked the code and had the impression it was enough, but
> >> I don't have experience with other archs. So, would be nice
> >> if other archs maintainers could review this. I'll try to ping them.  
> > 
> > I think we need to take a step back and rethink:
> > 
> > 1) What the field is supposed to mean?  The semantics of "halted"
> >are completely unclear.  What exactly we want to communicate
> >to libvirt/management?
> > 2) On which cases the information (whatever it means) is really
> >useful/important?  If you are excluding cases with in-kernel
> >irqchip, you are already excluding most users.
> > 
> >   
> Given that nobody (including myself) sees a need for halted we can
> remove it for the fast version of query-cpus without surprising anyone.
> [...]

My conclusion too, I'll drop it.

Re: [Qemu-devel] [PATCH v2] qmp: add query-cpus-fast

[Luiz Capitulino]

On Fri, 9 Feb 2018 08:56:19 +0100
Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:

> On 08.02.2018 21:33, Eduardo Habkost wrote:
> > On Thu, Feb 08, 2018 at 11:17:32AM -0500, Luiz Capitulino wrote:
> > [...]  
> >> The "halted" field is somewhat controversial. On the one hand,
> >> it offers a convenient way to know if a guest CPU is idle or
> >> running. On the other hand, it's a field that can change many
> >> times a second. In fact, the halted state can change even
> >> before query-cpus-fast has returned. This makes one wonder if
> >> this field should be dropped all together. Having the "halted"
> >> field as optional gives a better option for dropping it in
> >> the future, since we can just stop returning it.  
> > 
> > I'd just drop it, unless we find a use case where it's really
> > useful.

I don't think there's any, unless for debugging purposes.

I'm keeping it mainly for s390. Viktor, libvirt is still using
this field in s390, no?

Dropping halted and having management software still using query-cpus
because of halted would be a total failure of query-cpus-fast.

> > Also, the code that sets/clears cpu->halted is target-specific,
> > so I wouldn't be so sure that simply checking for
> > !kvm_irqchip_in_kernel() is enough on all targets.

I checked the code and had the impression it was enough, but
I don't have experience with other archs. So, would be nice
if other archs maintainers could review this. I'll try to ping them.

> Right, the present patch effectively disables halted anyway (including
> s390). 

No, it doesn't. It only disables halted for archs that require going
to the kernel to get it.

> So it may be cleaner to just drop it right now.
> Assuming the presence of architecure-specific data, libvirt can derive a
> halted state (or an equivalent thereof) from query-cpus-fast returned
> information.

This is a different proposal. You're proposing moving the halted state
to a CPU-specific field. This is doable if that's what we want.

Re: [Qemu-devel] [PATCH] S390: Expose s390-specific CPU info

[Luiz Capitulino]

On Thu, 8 Feb 2018 18:02:07 +0100
Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:

> On 08.02.2018 17:22, Luiz Capitulino wrote:
> > On Thu, 8 Feb 2018 16:52:28 +0100
> > Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
> >   
> >> diff --git a/qapi-schema.json b/qapi-schema.json
> >> index 12c7dc8..0b36860 100644
> >> --- a/qapi-schema.json
> >> +++ b/qapi-schema.json
> >> @@ -607,7 +607,27 @@
> >>  ##
> >>  { 'struct': 'CpuInfo2',
> >>'data': {'cpu-index': 'int', '*halted': 'bool', 'qom-path': 'str',
> >> -   'thread-id': 'int', '*props': 'CpuInstanceProperties' } }
> >> +   'thread-id': 'int', '*props': 'CpuInstanceProperties',
> >> +   '*archdata': 'CpuInfoArchData' } }
> >> +
> >> +##
> >> +# @CpuInfoArchData:
> >> +#
> >> +# Architecure specific information about a virtual CPU
> >> +#
> >> +# Since: 2.12
> >> +#
> >> +##
> >> +{ 'union': 'CpuInfoArchData',
> >> +  'base': { 'arch': 'CpuInfoArch' },
> >> +  'discriminator': 'arch',
> >> +  'data': { 'x86': 'CpuInfoOther',
> >> +'sparc': 'CpuInfoOther',
> >> +'ppc': 'CpuInfoOther',
> >> +'mips': 'CpuInfoOther',
> >> +'tricore': 'CpuInfoOther',
> >> +'s390': 'CpuInfoS390',
> >> +'other': 'CpuInfoOther' } }
> >>  
> >>  ##
> >>  # @query-cpus-fast:  
> > 
> > I don't think you need CpuInfoArchData, you can have S390CpuState
> > instead and ignore the other archs. It's not like all archs data
> > can be returned at the same time, and also you start having to
> > replicate that arch string list everywhere. Lastly, the arch name
> > is returned by query-target, so no need to duplicate that one either.
> >   
> I don't think I really understood your suggestion. Was it to assume that
> only s390 will have arch-specific data?. I.e. something along the lines of
> -   'thread-id': 'int', '*props': 'CpuInstanceProperties' } }
> +   'thread-id': 'int', '*props': 'CpuInstanceProperties',
> +   '*archdata': 'CpuInfoS390' } }
> 
> or some kind of in-line, anonymous union? I have to confess I'm pretty
> QAPI-illiterate, so I may have done it overly complicated. At least it
> feels that way.

Yes, what you propose above is what I had in mind. Maybe the QAPI has
some better way to do it though.

Re: [Qemu-devel] [PATCH] S390: Expose s390-specific CPU info

[Luiz Capitulino]

On Thu, 8 Feb 2018 16:52:28 +0100
Viktor Mihajlovski  wrote:

> diff --git a/qapi-schema.json b/qapi-schema.json
> index 12c7dc8..0b36860 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -607,7 +607,27 @@
>  ##
>  { 'struct': 'CpuInfo2',
>'data': {'cpu-index': 'int', '*halted': 'bool', 'qom-path': 'str',
> -   'thread-id': 'int', '*props': 'CpuInstanceProperties' } }
> +   'thread-id': 'int', '*props': 'CpuInstanceProperties',
> +   '*archdata': 'CpuInfoArchData' } }
> +
> +##
> +# @CpuInfoArchData:
> +#
> +# Architecure specific information about a virtual CPU
> +#
> +# Since: 2.12
> +#
> +##
> +{ 'union': 'CpuInfoArchData',
> +  'base': { 'arch': 'CpuInfoArch' },
> +  'discriminator': 'arch',
> +  'data': { 'x86': 'CpuInfoOther',
> +'sparc': 'CpuInfoOther',
> +'ppc': 'CpuInfoOther',
> +'mips': 'CpuInfoOther',
> +'tricore': 'CpuInfoOther',
> +'s390': 'CpuInfoS390',
> +'other': 'CpuInfoOther' } }
>  
>  ##
>  # @query-cpus-fast:

I don't think you need CpuInfoArchData, you can have S390CpuState
instead and ignore the other archs. It's not like all archs data
can be returned at the same time, and also you start having to
replicate that arch string list everywhere. Lastly, the arch name
is returned by query-target, so no need to duplicate that one either.

[Qemu-devel] [PATCH v2] qmp: add query-cpus-fast

[Luiz Capitulino]

The query-cpus command has an extremely serious side effect:
it always interrupts all running vCPUs so that they can run
ioctl calls. This can cause a huge performance degradation for
some workloads. And most of the information retrieved by the
ioctl calls are not even used by query-cpus.

This commit introduces a replacement for query-cpus called
query-cpus-fast, which has the following features:

 o Never interrupt vCPUs threads. query-cpus-fast only returns
   vCPU information maintained by QEMU itself, which should be
   sufficient for most management software needs

 o Make "halted" field optional: we only return it if the
   halted state is maintained by QEMU. But this also gives
   the option of dropping the field in the future (see below)

 o Drop irrelevant fields such as "current", "pc" and "arch"

 o Rename some fields for better clarification & proper naming
   standard

The "halted" field is somewhat controversial. On the one hand,
it offers a convenient way to know if a guest CPU is idle or
running. On the other hand, it's a field that can change many
times a second. In fact, the halted state can change even
before query-cpus-fast has returned. This makes one wonder if
this field should be dropped all together. Having the "halted"
field as optional gives a better option for dropping it in
the future, since we can just stop returning it.

Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
---

o v2

 - Many English and naming corrections by Eric
 - Adopt query-cpus text from Daniel
 - squash query-cpus text change into this patch

 cpus.c   | 44 ++
 hmp-commands-info.hx | 14 ++
 hmp.c| 24 
 hmp.h|  1 +
 qapi-schema.json | 77 
 5 files changed, 160 insertions(+)

diff --git a/cpus.c b/cpus.c
index 182caf764e..905b1f4d79 100644
--- a/cpus.c
+++ b/cpus.c
@@ -2150,6 +2150,50 @@ CpuInfoList *qmp_query_cpus(Error **errp)
 return head;
 }
 
+/*
+ * fast means: we NEVER interrupt vCPU threads to retrieve
+ * information from KVM.
+ */
+CpuInfoFastList *qmp_query_cpus_fast(Error **errp)
+{
+MachineState *ms = MACHINE(qdev_get_machine());
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+CpuInfoFastList *head = NULL, *cur_item = NULL;
+CPUState *cpu;
+
+CPU_FOREACH(cpu) {
+CpuInfoFastList *info = g_malloc0(sizeof(*info));
+info->value = g_malloc0(sizeof(*info->value));
+
+info->value->cpu_index = cpu->cpu_index;
+info->value->qom_path = object_get_canonical_path(OBJECT(cpu));
+info->value->thread_id = cpu->thread_id;
+
+info->value->has_props = !!mc->cpu_index_to_instance_props;
+if (info->value->has_props) {
+CpuInstanceProperties *props;
+props = g_malloc0(sizeof(*props));
+*props = mc->cpu_index_to_instance_props(ms, cpu->cpu_index);
+info->value->props = props;
+}
+
+/* if in kernel irqchip is used, we don't have 'halted' */
+info->value->has_halted = !kvm_irqchip_in_kernel();
+if (info->value->has_halted) {
+info->value->halted = cpu->halted;
+}
+
+if (!cur_item) {
+head = cur_item = info;
+} else {
+cur_item->next = info;
+cur_item = info;
+}
+}
+
+return head;
+}
+
 void qmp_memsave(int64_t addr, int64_t size, const char *filename,
  bool has_cpu, int64_t cpu_index, Error **errp)
 {
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index ad590a4ffb..16ac60285f 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -157,6 +157,20 @@ STEXI
 @item info cpus
 @findex info cpus
 Show infos for each CPU.
+ETEXI
+
+{
+.name   = "cpus_fast",
+.args_type  = "",
+.params = "",
+.help   = "show information for each CPU without interrupting 
them",
+.cmd= hmp_info_cpus_fast,
+},
+
+STEXI
+@item info cpus_fast
+@findex info cpus_fast
+Show infos for each CPU without performance penalty.
 ETEXI
 
 {
diff --git a/hmp.c b/hmp.c
index b3de32d219..90717c13b2 100644
--- a/hmp.c
+++ b/hmp.c
@@ -404,6 +404,30 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict)
 qapi_free_CpuInfoList(cpu_list);
 }
 
+void hmp_info_cpus_fast(Monitor *mon, const QDict *qdict)
+{
+CpuInfoFastList *head, *cpu;
+TargetInfo *target;
+
+target = qmp_query_target(NULL);
+monitor_printf(mon, "CPU architecture is '%s'\n\n", target->arch);
+qapi_free_TargetInfo(target);
+
+head = qmp_query_cpus_fast(NULL);
+
+for (cpu = head; cpu; cpu = cpu->next) {
+monitor_printf(mon, "CPU%" PRId64 

Re: [Qemu-devel] [PATCH] S390: Expose s390-specific CPU info

[Luiz Capitulino]

On Thu, 8 Feb 2018 16:21:26 +0100
Cornelia Huck <coh...@redhat.com> wrote:

> On Thu, 8 Feb 2018 09:09:04 -0500
> Luiz Capitulino <lcapitul...@redhat.com> wrote:
> 
> > On Thu,  8 Feb 2018 10:48:08 +0100
> > Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
> >   
> > > Presently s390x is the only architecture not exposing specific
> > > CPU information via QMP query-cpus. Upstream discussion has shown
> > > that it could make sense to report the architecture specific CPU
> > > state, e.g. to detect that a CPU has been stopped.
> > 
> > I'd very strongly advise against extending query-cpus. Note that the
> > latency problems with query-cpus exists in all archs, it's just a
> > matter of time for it to pop up for s390 use-cases too.
> > 
> > I think there's three options for this change:
> > 
> >  1. If this doesn't require interrupting vCPU threads, then you
> > could rebase this on top of query-cpus-fast  
> 
> From my perspective, rebasing on top of query-cpus-fast looks like a
> good idea. This would imply that we need architecture-specific fields
> for the new interface as well, though.

That's not a problem. I mean, to be honest I think I'd slightly prefer
to keep things separate and add a new command for each arch that needs
its specific information, but that's just personal preference. The only
strong requirement for query-cpus-fast is that it doesn't interrupt
vCPU threads.

> 
> > 
> >  2. If you plan to keep adding s390 state/registers to QMP commands,
> > then you could consider adding a query-s390-cpu-state or add
> > a query-cpu-state command that accepts the arch name as a parameter  
> 
> Personally, I don't see a need for more fields. But maybe I'm just
> unimaginative.
> 
> > 
> >  3. If you end up needing to expose state that actually needs an
> > ioctl, then we should consider porting info registers to QMP
> >   
> > > 
> > > With this change the output of query-cpus will look like this on
> > > s390:
> > > 
> > > [{"arch": "s390", "current": true,
> > >   "props": {"core-id": 0}, "cpu_state": "operating", "CPU": 0,
> > >   "qom_path": "/machine/unattached/device[0]",
> > >   "halted": false, "thread_id": 63115},
> > >  {"arch": "s390", "current": false,
> > >   "props": {"core-id": 1}, "cpu_state": "stopped", "CPU": 1,
> > >   "qom_path": "/machine/unattached/device[1]",
> > >   "halted": true, "thread_id": 63116}]
> > > 
> > > Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>  
> 

Re: [Qemu-devel] [PATCH] S390: Expose s390-specific CPU info

[Luiz Capitulino]

On Thu,  8 Feb 2018 10:48:08 +0100
Viktor Mihajlovski  wrote:

> Presently s390x is the only architecture not exposing specific
> CPU information via QMP query-cpus. Upstream discussion has shown
> that it could make sense to report the architecture specific CPU
> state, e.g. to detect that a CPU has been stopped.

I'd very strongly advise against extending query-cpus. Note that the
latency problems with query-cpus exists in all archs, it's just a
matter of time for it to pop up for s390 use-cases too.

I think there's three options for this change:

 1. If this doesn't require interrupting vCPU threads, then you
could rebase this on top of query-cpus-fast

 2. If you plan to keep adding s390 state/registers to QMP commands,
then you could consider adding a query-s390-cpu-state or add
a query-cpu-state command that accepts the arch name as a parameter

 3. If you end up needing to expose state that actually needs an
ioctl, then we should consider porting info registers to QMP

> 
> With this change the output of query-cpus will look like this on
> s390:
> 
> [{"arch": "s390", "current": true,
>   "props": {"core-id": 0}, "cpu_state": "operating", "CPU": 0,
>   "qom_path": "/machine/unattached/device[0]",
>   "halted": false, "thread_id": 63115},
>  {"arch": "s390", "current": false,
>   "props": {"core-id": 1}, "cpu_state": "stopped", "CPU": 1,
>   "qom_path": "/machine/unattached/device[1]",
>   "halted": true, "thread_id": 63116}]
> 
> Signed-off-by: Viktor Mihajlovski 
> ---
>  cpus.c |  6 ++
>  hmp.c  |  4 
>  hw/s390x/s390-virtio-ccw.c |  2 +-
>  qapi-schema.json   | 25 -
>  target/s390x/cpu.c | 24 
>  target/s390x/cpu.h |  7 ++-
>  target/s390x/kvm.c |  8 
>  target/s390x/sigp.c| 38 +++---
>  8 files changed, 72 insertions(+), 42 deletions(-)
> 
> diff --git a/cpus.c b/cpus.c
> index 2cb0af9..39e46dd 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -2033,6 +2033,9 @@ CpuInfoList *qmp_query_cpus(Error **errp)
>  #elif defined(TARGET_TRICORE)
>  TriCoreCPU *tricore_cpu = TRICORE_CPU(cpu);
>  CPUTriCoreState *env = _cpu->env;
> +#elif defined(TARGET_S390X)
> +S390CPU *s390_cpu = S390_CPU(cpu);
> +CPUS390XState *env = _cpu->env;
>  #endif
>  
>  cpu_synchronize_state(cpu);
> @@ -2060,6 +2063,9 @@ CpuInfoList *qmp_query_cpus(Error **errp)
>  #elif defined(TARGET_TRICORE)
>  info->value->arch = CPU_INFO_ARCH_TRICORE;
>  info->value->u.tricore.PC = env->PC;
> +#elif defined(TARGET_S390X)
> +info->value->arch = CPU_INFO_ARCH_S390;
> +info->value->u.s390.cpu_state = env->cpu_state;
>  #else
>  info->value->arch = CPU_INFO_ARCH_OTHER;
>  #endif
> diff --git a/hmp.c b/hmp.c
> index b3de32d..37e04c3 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -390,6 +390,10 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict)
>  case CPU_INFO_ARCH_TRICORE:
>  monitor_printf(mon, " PC=0x%016" PRIx64, 
> cpu->value->u.tricore.PC);
>  break;
> +case CPU_INFO_ARCH_S390:
> +monitor_printf(mon, " state=%s",
> +   
> CpuInfoS390State_str(cpu->value->u.s390.cpu_state));
> +break;
>  default:
>  break;
>  }
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 3807dcb..3e6360e 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -373,7 +373,7 @@ static void s390_machine_reset(void)
>  
>  /* all cpus are stopped - configure and start the ipl cpu only */
>  s390_ipl_prepare_cpu(ipl_cpu);
> -s390_cpu_set_state(CPU_STATE_OPERATING, ipl_cpu);
> +s390_cpu_set_state(CPU_INFOS390_STATE_OPERATING, ipl_cpu);
>  }
>  
>  static void s390_machine_device_plug(HotplugHandler *hotplug_dev,
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 5c06745..c34880b 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -413,7 +413,7 @@
>  # Since: 2.6
>  ##
>  { 'enum': 'CpuInfoArch',
> -  'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
> +  'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 's390', 'other' ] }
>  
>  ##
>  # @CpuInfo:
> @@ -452,6 +452,7 @@
>  'ppc': 'CpuInfoPPC',
>  'mips': 'CpuInfoMIPS',
>  'tricore': 'CpuInfoTricore',
> +'s390': 'CpuInfoS390',
>  'other': 'CpuInfoOther' } }
>  
>  ##
> @@ -522,6 +523,28 @@
>  { 'struct': 'CpuInfoOther', 'data': { } }
>  
>  ##
> +# @CpuInfoS390State:
> +#
> +# An enumeration of cpu states that can be assumed by a virtual
> +# S390 CPU
> +#
> +# Since: 2.12
> +##
> +{ 'enum': 'CpuInfoS390State',
> +  'data': [ 'uninitialized', 'stopped', 'check_stop', 'operating', 'load' ] }
> +
> +##

Re: [Qemu-devel] [PATCH 2/2] qmp: document query-cpus performance issue

[Luiz Capitulino]

On Thu, 8 Feb 2018 09:29:28 +
Daniel P. Berrangé <berra...@redhat.com> wrote:

> On Wed, Feb 07, 2018 at 12:50:14PM -0500, Luiz Capitulino wrote:
> > Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
> > ---
> >  qapi-schema.json | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index 82d6f12b53..0665a14dba 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -526,6 +526,10 @@
> >  #
> >  # Returns a list of information about each virtual CPU.
> >  #
> > +# WARNING: This command incurs a performance penalty for latency
> > +#  sensitive workloads and hence it's not recommended to
> > +#  to be used in production. Use query-cpus-fast instead  
> 
> I suggest being more explicit about exactly what the problem is, so people
> understand implications if they choose to still use it. ie

I'll add your text.

> 
>   This command causes vCPU threads to exit to userspace, which causes
>   an small interruption guest CPU execution. This will have a negative
>   impact on realtime guests and other latency sensitive guest workloads.
>   It is recommended to use query-cpus-fast instead of this command to
>   avoid the vCPU interruption.
> 
> Regards,
> Daniel

Re: [Qemu-devel] [PATCH 1/2] qmp: add query-cpus-fast

[Luiz Capitulino]

On Thu, 8 Feb 2018 08:41:31 +0100
Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:

> On 07.02.2018 18:50, Luiz Capitulino wrote:
> > The query-cpus command has an extremely serious side effect:
> > it always interrupt all running vCPUs so that they can run
> > ioctl calls. This can cause a huge performance degradation for
> > some workloads. And most of the information retrieved by the
> > ioctl calls are not even used by query-cpus.
> > 
> > This commit introduces a replacement for query-cpus called
> > query-cpus-fast, which has the following features:
> > 
> >  o Never interrupt vCPUs threads. query-cpus-fast only returns
> >vCPU information maintained by QEMU itself, which should be
> >sufficient for most management software needs
> > 
> >  o Make "halted" field optional: we only return it if the
> >halted state is maintained by QEMU. But this also gives
> >the option of dropping the field in the future (see below)
> > 
> >  o Drop irrelevant fields such as "current", "pc" and "arch"  
> I disagree that arch is irrelevant and would strongly suggest to keep
> arch and arch-specific fields. At least in the case of s390 there's a
> cpu_state field that can be obtained cheaply.

The arch name can be queried with query-target. The only other
arch field I'm dropping is pc, which should be considered debug
only if anything.

Also, if this need to query CPU registers increase, then we
probably should port 'info registers' to QMP. Otherwise, we'll
eventually run into the performance problem once again.

> [...]
> > diff --git a/cpus.c b/cpus.c
> > index 2cb0af9b22..3b68a8146c 100644
> > --- a/cpus.c
> > +++ b/cpus.c
> > @@ -2083,6 +2083,50 @@ CpuInfoList *qmp_query_cpus(Error **errp)
> >  return head;
> >  }
> > 
> > +/*
> > + * fast means: we NEVER interrupt vCPU threads to retrieve
> > + * information from KVM.
> > + */
> > +CpuInfo2List *qmp_query_cpus_fast(Error **errp)
> > +{
> > +MachineState *ms = MACHINE(qdev_get_machine());
> > +MachineClass *mc = MACHINE_GET_CLASS(ms);
> > +CpuInfo2List *head = NULL, *cur_item = NULL;
> > +CPUState *cpu;
> > +
> > +CPU_FOREACH(cpu) {
> > +CpuInfo2List *info = g_malloc0(sizeof(*info));
> > +info->value = g_malloc0(sizeof(*info->value));
> > +
> > +info->value->cpu_index = cpu->cpu_index;
> > +info->value->qom_path = object_get_canonical_path(OBJECT(cpu));
> > +info->value->thread_id = cpu->thread_id;
> > +
> > +info->value->has_props = !!mc->cpu_index_to_instance_props;
> > +if (info->value->has_props) {
> > +CpuInstanceProperties *props;
> > +props = g_malloc0(sizeof(*props));
> > +*props = mc->cpu_index_to_instance_props(ms, cpu->cpu_index);
> > +info->value->props = props;
> > +}
> > +
> > +/* if in kernel irqchip is used, we don't have 'halted' */
> > +info->value->has_halted = !kvm_irqchip_in_kernel();  
> This is definitely not true for s390. Externally observable CPU state
> changes are handled by QEMU there. We may still drop halted if we add a
> more appropriate arch-specific field.
> > +if (info->value->has_halted) {
> > +info->value->halted = cpu->halted;
> > +}  
> [...]
> 

Re: [Qemu-devel] [PATCH 2/2] qmp: document query-cpus performance issue

[Luiz Capitulino]

On Wed, 7 Feb 2018 12:50:59 -0600
Eric Blake <ebl...@redhat.com> wrote:

> On 02/07/2018 11:50 AM, Luiz Capitulino wrote:
> > Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
> > ---
> >   qapi-schema.json | 4 
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index 82d6f12b53..0665a14dba 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -526,6 +526,10 @@
> >   #
> >   # Returns a list of information about each virtual CPU.
> >   #
> > +# WARNING: This command incurs a performance penalty for latency
> > +#  sensitive workloads and hence it's not recommended to
> > +#  to be used in production. Use query-cpus-fast instead
> > +#  
> 
> Ah, I asked for this on 1/2.  You could squash these.
> 
> I didn't review the code, just the interface, so if you squash them, you 
> can add the weaker:
> 
> Acked-by: Eric Blake <ebl...@redhat.com>

OK, I'll wait for more review and do the changes you requested.

[Qemu-devel] [PATCH 1/2] qmp: add query-cpus-fast

[Luiz Capitulino]

The query-cpus command has an extremely serious side effect:
it always interrupt all running vCPUs so that they can run
ioctl calls. This can cause a huge performance degradation for
some workloads. And most of the information retrieved by the
ioctl calls are not even used by query-cpus.

This commit introduces a replacement for query-cpus called
query-cpus-fast, which has the following features:

 o Never interrupt vCPUs threads. query-cpus-fast only returns
   vCPU information maintained by QEMU itself, which should be
   sufficient for most management software needs

 o Make "halted" field optional: we only return it if the
   halted state is maintained by QEMU. But this also gives
   the option of dropping the field in the future (see below)

 o Drop irrelevant fields such as "current", "pc" and "arch"

 o Rename some fields for better clarification & proper naming
   standard

The "halted" field is somewhat controversial. On the one hand,
it offers a convenient way to know if a guest CPU is idle or
running. On the other hand, it's a field that can change many
times a second. In fact, the halted state can change even
before query-cpus-fast has returned. This makes one wonder if
this field should be dropped all together. Having the "halted"
field as optional gives a better option for dropping it in
the future, since we can just stop returning it.

Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
---
 cpus.c   | 44 
 hmp-commands-info.hx | 14 +++
 hmp.c| 24 ++
 hmp.h|  1 +
 qapi-schema.json | 71 
 5 files changed, 154 insertions(+)

diff --git a/cpus.c b/cpus.c
index 2cb0af9b22..3b68a8146c 100644
--- a/cpus.c
+++ b/cpus.c
@@ -2083,6 +2083,50 @@ CpuInfoList *qmp_query_cpus(Error **errp)
 return head;
 }
 
+/*
+ * fast means: we NEVER interrupt vCPU threads to retrieve
+ * information from KVM.
+ */
+CpuInfo2List *qmp_query_cpus_fast(Error **errp)
+{
+MachineState *ms = MACHINE(qdev_get_machine());
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+CpuInfo2List *head = NULL, *cur_item = NULL;
+CPUState *cpu;
+
+CPU_FOREACH(cpu) {
+CpuInfo2List *info = g_malloc0(sizeof(*info));
+info->value = g_malloc0(sizeof(*info->value));
+
+info->value->cpu_index = cpu->cpu_index;
+info->value->qom_path = object_get_canonical_path(OBJECT(cpu));
+info->value->thread_id = cpu->thread_id;
+
+info->value->has_props = !!mc->cpu_index_to_instance_props;
+if (info->value->has_props) {
+CpuInstanceProperties *props;
+props = g_malloc0(sizeof(*props));
+*props = mc->cpu_index_to_instance_props(ms, cpu->cpu_index);
+info->value->props = props;
+}
+
+/* if in kernel irqchip is used, we don't have 'halted' */
+info->value->has_halted = !kvm_irqchip_in_kernel();
+if (info->value->has_halted) {
+info->value->halted = cpu->halted;
+}
+
+if (!cur_item) {
+head = cur_item = info;
+} else {
+cur_item->next = info;
+cur_item = info;
+}
+}
+
+return head;
+}
+
 void qmp_memsave(int64_t addr, int64_t size, const char *filename,
  bool has_cpu, int64_t cpu_index, Error **errp)
 {
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index ad590a4ffb..8657ceceb0 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -157,6 +157,20 @@ STEXI
 @item info cpus
 @findex info cpus
 Show infos for each CPU.
+ETEXI
+
+{
+.name   = "cpus_fast",
+.args_type  = "",
+.params = "",
+.help   = "show infos for each CPU without performance penalty",
+.cmd= hmp_info_cpus_fast,
+},
+
+STEXI
+@item info cpus_fast
+@findex info cpus_fast
+Show infos for each CPU without performance penalty.
 ETEXI
 
 {
diff --git a/hmp.c b/hmp.c
index b3de32d219..3d32333fd2 100644
--- a/hmp.c
+++ b/hmp.c
@@ -404,6 +404,30 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict)
 qapi_free_CpuInfoList(cpu_list);
 }
 
+void hmp_info_cpus_fast(Monitor *mon, const QDict *qdict)
+{
+CpuInfo2List *head, *cpu;
+TargetInfo *target;
+
+target = qmp_query_target(NULL);
+monitor_printf(mon, "CPU architecture is '%s'\n\n", target->arch);
+qapi_free_TargetInfo(target);
+
+head = qmp_query_cpus_fast(NULL);
+
+for (cpu = head; cpu; cpu = cpu->next) {
+monitor_printf(mon, "CPU%" PRId64 "\n", cpu->value->cpu_index);
+monitor_printf(mon, " thread-id=%" PRId64 "\n", cpu->value->thread_id);
+   

[Qemu-devel] [PATCH 2/2] qmp: document query-cpus performance issue

[Luiz Capitulino]

Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
---
 qapi-schema.json | 4 
 1 file changed, 4 insertions(+)

diff --git a/qapi-schema.json b/qapi-schema.json
index 82d6f12b53..0665a14dba 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -526,6 +526,10 @@
 #
 # Returns a list of information about each virtual CPU.
 #
+# WARNING: This command incurs a performance penalty for latency
+#  sensitive workloads and hence it's not recommended to
+#  to be used in production. Use query-cpus-fast instead
+#
 # Returns: a list of @CpuInfo for each virtual CPU
 #
 # Since: 0.14.0
-- 
2.14.3

[Qemu-devel] [PATCH 0/2] qmp: add query-cpus-fast

[Luiz Capitulino]

We've recently debugged a huge performance degradation we were getting
on a latency sensitive workload down to the fact that libvirt is
issuing query-cpus. As it turns out, query-cpus always interrupts all
vCPU threads so that they can run ioctl to collect a number of register
information, most of which are not even used by query-cpus at all.

This series adds a new command called query-cpus-fast, which returns
the most relevant information returned by query-cpus without having
to interrupt vCPU threads. This series also updates query-cpus
documentation to advise against its use in production.

More details in individual patches.

Luiz Capitulino (2):
  qmp: add query-cpus-fast
  qmp: document query-cpus performance issue

 cpus.c   | 44 ++
 hmp-commands-info.hx | 14 ++
 hmp.c| 24 +
 hmp.h|  1 +
 qapi-schema.json | 75 
 5 files changed, 158 insertions(+)

-- 
2.14.3

Re: [Qemu-devel] [RFC] kvm: x86: export vCPU halted state to sysfs

[Luiz Capitulino]

On Fri, 2 Feb 2018 12:50:14 -0200
Eduardo Habkost <ehabk...@redhat.com> wrote:

> (CCing qemu-devel)
> 
> On Fri, Feb 02, 2018 at 09:21:59AM -0500, Luiz Capitulino wrote:
> > On Fri, 2 Feb 2018 14:19:38 +
> > Daniel P. Berrangé <berra...@redhat.com> wrote:  
> > > On Fri, Feb 02, 2018 at 12:15:54PM -0200, Eduardo Habkost wrote:  
> [...]
> > > > It would be also interesting to update QEMU QMP documentation to
> > > > clarify the arch-specific semantics of "halted".
> > > 
> > > Any also especially clarify the awful performance implications of running
> > > this particular query command. In general I would not expect query-xxx
> > > monitor commands to interrupt all vcpus, so we should clearly warn about
> > > this !  
> > 
> > Or deprecate it...  
> 
> We could deprecate the expensive fields on query-cpus, and move
> them to a more expensive query-cpu-state command.  I believe most
> users of query-cpus are only interested in qom_path, thread_id,
> and topology info.

Agree. The only thing I'm unsure about is that, is the performance
issue only present in x86? If yes, then do we deprecate it only
for x86 or for all archs? Maybe for all archs, otherwise this has
the potential to turn into a mess.

> Markus, Eric: from the QAPI point of view, is it OK to remove
> fields between QEMU versions, as long as we follow our
> deprecation policy?

I guess we can't remove fields, but maybe we could always return
"running" and skip interrupting the vCPU threads.

Re: [Qemu-devel] Hi, where can i get a latest full version of QAPI ?

[Luiz Capitulino]

On Wed, 20 Dec 2017 18:37:37 +0800
"那个秀才"  wrote:

> Hi,
>     Dear master.    Where can i get a latest full verson of QAPI ?    I wanna 
> read some file in VMs by qemu-quest-agent, since then, i found things below:
> https://wiki.qemu.org/QMPhttps://wiki.qemu.org/Features/GuestAgent
> https://wiki.qemu.org/Features/QAPI
> https://wiki.qemu.org/Features/QAPI/Signals
> and even:
> http://shevek.github.io/qemu-java/docs/javadoc/However, those are all 
> not a API manual like 
> https://developer.openstack.org/api-ref/application-container/ or 
> https://dev.office.com/reference/add-ins/shared/asyncresult
> Need help !Thanks for any response !
> Regards!
> Boba little code labour in the world full of dust.

Markus is a better person to ask.

Re: [Qemu-devel] [PATCH 04/17] qapi: merge QInt and QFloat in QNum

[Luiz Capitulino]

tory.
> > - *
> > - */
> > -#include "qemu/osdep.h"
> > -
> > -#include "qapi/qmp/qfloat.h"
> > -#include "qemu-common.h"
> > -
> > -/*
> > - * Public Interface test-cases
> > - *
> > - * (with some violations to access 'private' data)
> > - */
> > -
> > -static void qfloat_from_double_test(void)
> > -{
> > -QFloat *qf;
> > -const double value = -42.23423;
> > -
> > -qf = qfloat_from_double(value);
> > -g_assert(qf != NULL);
> > -g_assert(qf->value == value);
> > -g_assert(qf->base.refcnt == 1);
> > -g_assert(qobject_type(QOBJECT(qf)) == QTYPE_QFLOAT);
> > -
> > -// destroy doesn't exit yet
> > -g_free(qf);
> > -}
> > -
> > -static void qfloat_destroy_test(void)
> > -{
> > -QFloat *qf = qfloat_from_double(0.0);
> > -QDECREF(qf);
> > -}
> > -
> > -int main(int argc, char **argv)
> > -{
> > -g_test_init(, , NULL);
> > -
> > -g_test_add_func("/public/from_double", qfloat_from_double_test);
> > -g_test_add_func("/public/destroy", qfloat_destroy_test);
> > -
> > -return g_test_run();
> > -}
> > diff --git a/tests/check-qint.c b/tests/check-qint.c
> > deleted file mode 100644
> > index b6e4555115..00
> > --- a/tests/check-qint.c
> > +++ /dev/null
> > @@ -1,87 +0,0 @@
> > -/*
> > - * QInt unit-tests.
> > - *
> > - * Copyright (C) 2009 Red Hat Inc.
> > - *
> > - * Authors:
> > - *  Luiz Capitulino <lcapitul...@redhat.com>
> > - *
> > - * This work is licensed under the terms of the GNU LGPL, version 2.1 or 
> > later.
> > - * See the COPYING.LIB file in the top-level directory.
> > - */
> > -#include "qemu/osdep.h"
> > -
> > -#include "qapi/qmp/qint.h"
> > -#include "qemu-common.h"
> > -
> > -/*
> > - * Public Interface test-cases
> > - *
> > - * (with some violations to access 'private' data)
> > - */
> > -
> > -static void qint_from_int_test(void)
> > -{
> > -QInt *qi;
> > -const int value = -42;
> > -
> > -qi = qint_from_int(value);
> > -g_assert(qi != NULL);
> > -g_assert(qi->value == value);
> > -g_assert(qi->base.refcnt == 1);
> > -g_assert(qobject_type(QOBJECT(qi)) == QTYPE_QINT);
> > -
> > -// destroy doesn't exit yet
> > -g_free(qi);
> > -}
> > -
> > -static void qint_destroy_test(void)
> > -{
> > -QInt *qi = qint_from_int(0);
> > -QDECREF(qi);
> > -}
> > -
> > -static void qint_from_int64_test(void)
> > -{
> > -QInt *qi;
> > -const int64_t value = 0x1234567890abcdefLL;
> > -
> > -qi = qint_from_int(value);
> > -g_assert((int64_t) qi->value == value);
> > -
> > -QDECREF(qi);
> > -}
> > -
> > -static void qint_get_int_test(void)
> > -{
> > -QInt *qi;
> > -const int value = 123456;
> > -
> > -qi = qint_from_int(value);
> > -g_assert(qint_get_int(qi) == value);
> > -
> > -QDECREF(qi);
> > -}
> > -
> > -static void qobject_to_qint_test(void)
> > -{
> > -QInt *qi;
> > -
> > -qi = qint_from_int(0);
> > -g_assert(qobject_to_qint(QOBJECT(qi)) == qi);
> > -
> > -QDECREF(qi);
> > -}
> > -
> > -int main(int argc, char **argv)
> > -{
> > -g_test_init(, , NULL);
> > -
> > -g_test_add_func("/public/from_int", qint_from_int_test);
> > -g_test_add_func("/public/destroy", qint_destroy_test);
> > -g_test_add_func("/public/from_int64", qint_from_int64_test);
> > -g_test_add_func("/public/get_int", qint_get_int_test);
> > -g_test_add_func("/public/to_qint", qobject_to_qint_test);
> > -
> > -return g_test_run();
> > -}
> > diff --git a/tests/check-qjson.c b/tests/check-qjson.c
> > index 963dd46f07..c432aebf13 100644
> > --- a/tests/check-qjson.c
> > +++ b/tests/check-qjson.c
> > @@ -886,21 +886,21 @@ static void simple_number(void)
> >  };
> >  
> >  for (i = 0; test_cases[i].encoded; i++) {
> > -QInt *qint;
> > +QNum *qnum;
> >  
> > -qint = qobject_to_qint(qobject_from_json(test_cases[i].encoded,
> > +qnum = qobject_to_qnum(qobject_from_json(test_cases[i].encoded,
> >  

Re: [Qemu-devel] [PATCH 04/17] qapi: merge QInt and QFloat in QNum

[Luiz Capitulino]

On Fri, 12 May 2017 08:30:36 +0200
Markus Armbruster <arm...@redhat.com> wrote:

> Question for Luiz...
> 
> Marc-André Lureau <marcandre.lur...@redhat.com> writes:
> 
> [...]
> > diff --git a/tests/check-qnum.c b/tests/check-qnum.c
> > new file mode 100644
> > index 00..d08d35e85a
> > --- /dev/null
> > +++ b/tests/check-qnum.c
> > @@ -0,0 +1,131 @@
> > +/*
> > + * QNum unit-tests.
> > + *
> > + * Copyright (C) 2009 Red Hat Inc.
> > + *
> > + * Authors:
> > + *  Luiz Capitulino <lcapitul...@redhat.com>
> > + *
> > + * This work is licensed under the terms of the GNU LGPL, version 2.1 or 
> > later.
> > + * See the COPYING.LIB file in the top-level directory.
> > + */
> > +#include "qemu/osdep.h"
> > +
> > +#include "qapi/qmp/qnum.h"
> > +#include "qapi/error.h"
> > +#include "qemu-common.h"
> > +
> > +/*
> > + * Public Interface test-cases
> > + *
> > + * (with some violations to access 'private' data)
> > + */
> > +
> > +static void qnum_from_int_test(void)
> > +{
> > +QNum *qi;
> > +const int value = -42;
> > +
> > +qi = qnum_from_int(value);
> > +g_assert(qi != NULL);
> > +g_assert_cmpint(qi->u.i64, ==, value);
> > +g_assert_cmpint(qi->base.refcnt, ==, 1);
> > +g_assert_cmpint(qobject_type(QOBJECT(qi)), ==, QTYPE_QNUM);
> > +
> > +// destroy doesn't exit yet
> > +g_free(qi);
> > +}  
> 
> The comment is enigmatic. 

It was meant for future generations to figure it out :)

> It was first written in commit 33837ba
> "Introduce QInt unit-tests", and got copied around since.  In
> check-qlist.c, it's spelled "exist yet".

Yes, "exit" is a typo it should be "exist".

> What is "destroy", why doesn't it exit / exist now, but will exit /
> exist later?  It can't be qnum_destroy_obj(), because that certainly
> exists already, exits already in the sense of returning, and shouldn't
> ever exit in the sense of terminating the program.
> 
> The comment applies to a g_free().  Why do we free directly instead
> decrementing the reference count?  Perhaps the comment tries to explain
> that (if it does, it fails).

In my personal style of writing unit-tests, I never use a method
in a test before testing it. So, as QDECREF() wasn't tested yet,
I wasn't allowed to use it.

While I keep this principle when writing unit-tests today, this
particular case is very extreme and not useful at all. Today I'd just
go ahead and use QDECREF(). The qint_destroy_test() in the original
commit is also very bogus, it's not really doing an useful test.

Re: [Qemu-devel] Monitor brain dump

[Luiz Capitulino]

On Wed, 05 Oct 2016 18:22:28 +0200
Markus Armbruster  wrote:

> In the beginning, there was only monitor.c, and it provided what we
> today call HMP, at just under 500 SLOC.
> 
> Since then, most (but not all) HMP commands have moved elsewhere, either
> to the applicable subsystem, or to hmp.c.  Command declaration moved to
> hmp-commands.hx and hmp-commands-info.hx.
> 
> Plenty of features got added, most notably QMP.  monitor.c is now huge:
> 3400 SLOC.  Since HMP and QMP are entangled there, MAINTAINERS adds it
> to both subsystems.  Some disentangling would be nice.  Perhaps like
> this:
> 
> * Move all HMP commands to hmp.c.
> 
> * Move all QMP commands to qmp.c.
> 
> * Split the rest into three parts: HMP only (line editing, completion,
>   history, HMP parsing and dispatch, the pocket calculator, ...), QMP
>   only (QMP parsing and dispatch, events, ...), common core.
> 
> Only the much smaller common core would remain part of both subsystems.

Agreed. Put it differently, for a long time now our goal for HMP has
been to move it on top of QMP. This means that HMP commands should not
access QEMU data directly, but do QMP calls instead. We did a lot of
this work already, I can't remember what's missing.

The separation you mention is probably a good place to start. Although
we don't necessarily need everything in hmp.c, having hmp/{history.c,
completion.c, commands.c} might make more sense.

I also remember I never liked hmp-commands.hx and hmp-commands-info.hx,
in special .args_type and .params. I wanted to ditch both files, but
I don't remember what I was planning as a replacement.

Lastly, this is maybe more QMP/QAPI than HMP, but I remember there
was talk some years ago about replacing QObjects with GObject. This
is no small undertaking though.

> Speaking of the pocket calculator: my recommendation would be "nuke from
> orbit".  It adds surprising corner cases to the HMP language, and
> provides next to no value.

Pocket calculator, LOL!

Re: [Qemu-devel] [PATCH 0/2] MAINTAINERS: Update HMP and QObject

[Luiz Capitulino]

On Wed, 28 Sep 2016 19:33:40 +0200
Markus Armbruster <arm...@redhat.com> wrote:

> Markus Armbruster (2):
>   MAINTAINERS: Pass the HMP staff from Luiz to David
>   MAINTAINERS: Pass the QObject staff from Luiz to Markus
> 
>  MAINTAINERS | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)

Guys,

Thank you very much for taking up maintainership of those
subsystems!

Acked-by: Luiz Capitulino <lcapitul...@redhat.com>

Re: [Qemu-devel] [PATCH] MAINTAINERS: Add some more files to the HMP section

[Luiz Capitulino]

On Thu, 22 Sep 2016 21:32:38 +0200
Thomas Huth <th...@redhat.com> wrote:

> The hmp-commands-info.hx, hmp.h and include/monitor/hmp-target.h
> files were classified as unmaintained. Let's add them to the
> HMP section.
> 
> Signed-off-by: Thomas Huth <th...@redhat.com>

Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>

I probably should downgrade the status of HMP to "Odd Fixes",
as I've not been dedicating any time for it. If anyone is
interested in taking up it let me know.

> ---
>  MAINTAINERS | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9da3d09..3879e1c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1160,8 +1160,9 @@ Human Monitor (HMP)
>  M: Luiz Capitulino <lcapitul...@redhat.com>
>  S: Maintained
>  F: monitor.c
> -F: hmp.c
> -F: hmp-commands.hx
> +F: hmp.[ch]
> +F: hmp-commands*.hx
> +F: include/monitor/hmp-target.h
>  T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
>  
>  Network device backends

Re: [Qemu-devel] [PATCH] monitor: fix crash for platforms without a CPU 0

[Luiz Capitulino]

On Wed, 21 Sep 2016 15:29:26 +1000
David Gibson <da...@gibson.dropbear.id.au> wrote:

> Now that we allow CPU hot unplug on a few platforms, we can end up in a
> situation where we don't have a CPU with index 0.  Or at least we could,
> if we didn't have code to explicitly prohibit unplug of CPU 0.
> 
> Longer term we want to allow CPU 0 unplug, this patch is an early step in
> allowing this, by removing an assumption in the monitor code that CPU 0
> always exists.
> 
> Signed-off-by: Cédric Le Goater <c...@kaod.org>
> [dwg: Rewrote commit message to better explain background]
> Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
> ---
>  monitor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Anyone want to volunteer to take this through their tree?  If not, I
> can take it through my ppc tree.

Please do.

Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>

> 
> diff --git a/monitor.c b/monitor.c
> index 8bb8bbf..83c4edf 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -1025,7 +1025,7 @@ int monitor_set_cpu(int cpu_index)
>  CPUState *mon_get_cpu(void)
>  {
>  if (!cur_mon->mon_cpu) {
> -monitor_set_cpu(0);
> +monitor_set_cpu(first_cpu->cpu_index);
>  }
>  cpu_synchronize_state(cur_mon->mon_cpu);
>  return cur_mon->mon_cpu;

Re: [Qemu-devel] [PATCH 0/6] hypertrace: Lightweight guest-to-QEMU trace channel

[Luiz Capitulino]

On Thu, 18 Aug 2016 14:53:27 +0100
Stefan Hajnoczi <stefa...@redhat.com> wrote:

> On Thu, Aug 18, 2016 at 12:22:18PM +0200, Lluís Vilanova wrote:
> > Stefan Hajnoczi writes:
> >   
> > > On Fri, Aug 05, 2016 at 06:59:23PM +0200, Lluís Vilanova wrote:  
> > >> The hypertrace channel allows guest code to emit events in QEMU (the 
> > >> host) using
> > >> its tracing infrastructure (see "docs/trace.txt"). This works in both 
> > >> 'system'
> > >> and 'user' modes. That is, hypertrace is to tracing, what hypercalls are 
> > >> to
> > >> system calls.
> > >> 
> > >> You can use this to emit an event on both guest and QEMU (host) traces 
> > >> to easily
> > >> synchronize or correlate them. You could also modify you guest's tracing 
> > >> system
> > >> to emit all events through the hypertrace channel, providing a unified 
> > >> and fully
> > >> synchronized trace log. Another use case is timing the performance of 
> > >> guest code
> > >> when optimizing TCG (QEMU traces have a timestamp).
> > >> 
> > >> See first commit for a full description.
> > >> 
> > >> Signed-off-by: Lluís Vilanova <vilan...@ac.upc.edu>
> > >> ---  
> >   
> > > CCing Steven Rostedt, Masami Hiramatsu, Luiz Capitulino, and LTTng folks
> > > who have all looked into host/guest tracing solutions.  
> > [...]
> > 
> > Oh, I wasn't aware of that. I'm certainly interested in collaborating.  
> 
> They are working on or have worked on different approaches to host/guest
> tracing.  Unfortunately there isn't an out-of-the-box solution as far as
> I know.

The ftrace solution is documented here:

 https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html

This traces the guest and host kernels. It supports merging the guest
and host traces. It's extremely low latency and has helped us to
find several spikes for real-time KVM (we're talking a few to
a dozen microseconds at most).

Now, our stack actually is:

 - Guest app
 - Guest kernel
 - Host kernel
 - QEMU

QEMU already has its own tracing (which I don't know how it works).
If I had to trace the guest app, I'd certainly start off by using
LTTng. Although, we'd have to write a tool to merge and orchestrate
(wooo, cloud buzzword!) all those traces (if that's what one wants).

> It would be nice if there was a documented host/guest tracing approach
> that didn't involve much manual setup and handled most use cases.

I'd volunteer to do it, although it will take me weeks to do it.

Re: [Qemu-devel] [PATCH 0/6] hypertrace: Lightweight guest-to-QEMU trace channel

[Luiz Capitulino]

On Thu, 18 Aug 2016 11:54:24 +0100
Stefan Hajnoczi  wrote:

> On Fri, Aug 05, 2016 at 06:59:23PM +0200, Lluís Vilanova wrote:
> > The hypertrace channel allows guest code to emit events in QEMU (the host) 
> > using
> > its tracing infrastructure (see "docs/trace.txt"). This works in both 
> > 'system'
> > and 'user' modes. That is, hypertrace is to tracing, what hypercalls are to
> > system calls.
> > 
> > You can use this to emit an event on both guest and QEMU (host) traces to 
> > easily
> > synchronize or correlate them. You could also modify you guest's tracing 
> > system
> > to emit all events through the hypertrace channel, providing a unified and 
> > fully
> > synchronized trace log. Another use case is timing the performance of guest 
> > code
> > when optimizing TCG (QEMU traces have a timestamp).
> > 
> > See first commit for a full description.  

I hate the be the one asking the stupid questions, but what's
the problem this series solves? What are the use-cases? Why
existing solutions don't solve this problem? How does this
compares to existing solutions?

> This tracing approach has a high performance overhead, particularly for
> SMP guests where each trace event requires writing to the global control
> register.  All CPUs will be hammering this register (heavyweight vmexit)
> for each trace event.
> 
> I think the folks CCed on this email all take an asynchronous approach
> to avoid this performance overhead.  Synchronous means taking a VM exit
> for every event.  Asynchronous means writing trace data to a buffer and
> later interleaving guest data with host trace data.
> 
> LTTng Userspace Tracer is an example of the asynchronous approach.  The
> trace data buffers are in shared memory.  The LTTng process can grab
> buffers at appropriate times.
> 
> The ftrace virtio-serial approach has been to splice() the ftrace
> buffers, resulting in efficient I/O.

Yes. However, note that the virtio-serial device is only used to
transfer the tracing data to the host. It has no role in the
tracing process. Also, it's not required. I've been using the
networking and it works OK as long as your tracing data is not big.

> 
> Steven is working on a host/guest solution for trace-cmd.  It is also
> asynchronous.  No new paravirt hardware is needed and it makes me wonder
> whether the hypertrace PCI device is trying to solve the problem at the
> wrong layer.
> 
> If you want to play around with asynchronous tracing, you could start
> with trace/simple.c.  It has a trace buffer that is asynchronously
> written out to file by a dedicated "writer" thread.
> 
> The one case where hypertrace makes sense to me is for -user tracing.
> There QEMU can efficiently interleave guest and QEMU traces, although as
> mentioned in the patch, I don't think the SIGSEGV approach should be
> used.
> 
> I suggest stripping this series down to focus on -user.  Synchronous
> tracing is not a good approach for -system emulation.
> 
> Stefan

Re: [Qemu-devel] [PATCH for-2.8 00/18] pc: q35: x2APIC support in kvm_apic mode

[Luiz Capitulino]

On Tue, 9 Aug 2016 21:35:04 +0800
Peter Xu  wrote:

> On Tue, Aug 09, 2016 at 10:28:41AM +0200, Igor Mammedov wrote:
> > On Mon, 8 Aug 2016 16:57:14 +0800
> > Peter Xu  wrote:
> >   
> > > On Mon, Aug 08, 2016 at 03:41:23PM +0800, Chao Gao wrote:  
> > > > HI, everyone.
> > > > 
> > > > We have done some tests after merging this patch set into the lastest 
> > > > qemu
> > > > master. In kvm aspect, we use the lastest kvm linux-next branch. Here 
> > > > are
> > > > some problems we have met.
> > > > 
> > > > 1. We can't boot up a 288 vcpus linux guest with CLI:
> > > > qemu-system-x86_64 -boot c -m 4096 -sdl -monitor pty --enable-kvm \
> > > > -M kernel-irqchip=split -serial stdio -bios bios.bin -smp cpus=288 \
> > > > -hda vdisk.img -device intel-iommu,intremap=on -machine q35.
> > > > The problem exists, even after we only assign 32 vcpus to the linux 
> > > > guest.
> > > > Maybe the output "do_IRQ: 146.113 No irq handler for vector (irq -1)" 
> > > > is a clue.
> > > > The output of qemu and kernel is in attachments. Do you have any idea
> > > > about the problem and how to solve it?
> > > 
> > > IIUC, we need to wait for Radim's QEMU patches to finally enable 288
> > > vcpus?
> > > 
> > > Btw, could you please try adding this to the QEMU cmdline when testing
> > > with 32 vcpus:
> > > 
> > >   -global ioapic.version=0x20
> > > 
> > > I see that you were running RHEL 7.2 guest with a default e1000. In
> > > that case, we may need to boost ioapic version to 0x20.
> > > 
> > > Thanks,
> > > 
> > > -- peterx  
> > 
> > Peter,
> > 
> > Upstream guest kernel 4.7.0+ (d52bd54db) crashes when booting with irq 
> > remapping on:
> > 
> > ./qemu-system-x86_64 -enable-kvm -smp 
> > 1,sockets=9,cores=32,threads=1,maxcpus=288 -device 
> > qemu64-x86_64-cpu,socket-id=8,core-id=30,thread-id=0 -bios x2apic_bios.bin  
> > -m 1G -nographic -device intel-iommu,intremap=on -machine 
> > q35,kernel-irqchip=split -snapshot -global ioapic.version=0x20 /dev/rhel72
> > 
> > 
> > [0.350669] smpboot: Max logical packages: 9
> > [0.351853] smpboot: APIC(0) Converting physical 0 to logical package 0
> > [0.353160] smpboot: APIC(11e) Converting physical 8 to logical package 1
> > [0.354627] DMAR: Host address width 39
> > [0.355621] DMAR: DRHD base: 0x00fed9 flags: 0x1
> > [0.356785] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap 
> > 12008c22260206 ecap f00f1a
> > [0.358721] DMAR-IR: IOAPIC id 0 under DRHD base  0xfed9 IOMMU 0
> > [0.360029] DMAR-IR: Queued invalidation will be enabled to support 
> > x2apic and Intr-remapping.
> > [0.364605] DMAR-IR: Enabled IRQ remapping in x2apic mode
> > [0.365805] BUG: unable to handle kernel NULL pointer dereference at 
> >   (null)
> > [0.367965] IP: [] x2apic_cluster_probe+0x35/0x70
> > [0.369373] PGD 0 
> > [0.370258] Oops: 0002 [#1] SMP
> > [0.371140] Modules linked in:
> > [0.372150] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0+ #647
> > [0.373485] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> > rel-1.9.0-143-gbac87e4 04/01/2014
> > [0.375622] task: 880039ad task.stack: 880039ad8000
> > [0.376875] RIP: 0010:[]  [] 
> > x2apic_cluster_probe+0x35/0x70
> > [0.379066] RSP: :880039adbe28  EFLAGS: 00010202
> > [0.380299] RAX:  RBX: 81f388a8 RCX: 
> > 880039e0
> > [0.381677] RDX:  RSI: 0002 RDI: 
> > 0246
> > [0.383096] RBP: 880039adbe28 R08: 00c6 R09: 
> > 880b9b80
> > [0.384579] R10: 00a0 R11: 0050 R12: 
> > 2000
> > [0.385990] R13: a118 R14: 011f R15: 
> > 0120
> > [0.387448] FS:  () GS:880039e0() 
> > knlGS:
> > [0.389454] CS:  0010 DS:  ES:  CR0: 80050033
> > [0.390697] CR2:  CR3: 01c06000 CR4: 
> > 06f0
> > [0.392114] Stack:
> > [0.392889]  880039adbe40 81da277c a110 
> > 880039adbe78
> > [0.395135]  81d9c055 81f14c60 880039ad0a58 
> > 81c95ac0
> > [0.397469]  818232c0 880039ad 880039adbf38 
> > 81d86293
> > [0.399695] Call Trace:
> > [0.400529]  [] default_setup_apic_routing+0x28/0x69
> > [0.401881]  [] native_smp_prepare_cpus+0x223/0x2d2
> > [0.403260]  [] kernel_init_freeable+0xd8/0x249
> > [0.404525]  [] kernel_init+0xe/0x110
> > [0.405703]  [] ret_from_fork+0x1f/0x40
> > [0.406966]  [] ? rest_init+0x80/0x80
> > [0.408165] Code: 00 31 c0 65 8b 15 2c f1 fa 7e 85 c9 75 01 c3 48 63 ca 
> > 55 48 c7 c0 10 d7 00 00 48 8b 0c cd 20 8d d4 81 89 d2 48 89 e5 48 8b 04 08 
> >  48 0f ab 10 49 c7 c0 60 b0 05 81 48 c7 c1 a0 ae 05 81 ba 01 
> > [0.417107] RIP  [] x2apic_cluster_probe+0x35/0x70
> 

Re: [Qemu-devel] [PATCH] trace-events: Fix typos (found by codespell)

[Luiz Capitulino]

On Wed, 23 Mar 2016 15:38:20 +0100
Stefan Weil <s...@weilnetz.de> wrote:

> Signed-off-by: Stefan Weil <s...@weilnetz.de>
> ---
>  trace-events | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/trace-events b/trace-events
> index d494de1..996a77f 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -144,8 +144,8 @@ cpu_out(unsigned int addr, char size, unsigned int val) 
> "addr %#x(%c) value %u"
>  # Since requests are raised via monitor, not many tracepoints are needed.
>  balloon_event(void *opaque, unsigned long addr) "opaque %p addr %lu"
>  virtio_balloon_handle_output(const char *name, uint64_t gpa) "section name: 
> %s gpa: %"PRIx64
> -virtio_balloon_get_config(uint32_t num_pages, uint32_t acutal) "num_pages: 
> %d acutal: %d"
> -virtio_balloon_set_config(uint32_t acutal, uint32_t oldacutal) "acutal: %d 
> oldacutal: %d"
> +virtio_balloon_get_config(uint32_t num_pages, uint32_t actual) "num_pages: 
> %d actual: %d"
> +virtio_balloon_set_config(uint32_t actual, uint32_t oldactual) "actual: %d 
> oldactual: %d"
>  virtio_balloon_to_target(uint64_t target, uint32_t num_pages) "balloon 
> target: %"PRIx64" num_pages: %d"
>  
>  # hw/intc/apic_common.c

Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>

Re: [Qemu-devel] [RFC] host and guest kernel trace merging

[Luiz Capitulino]

On Thu, 24 Mar 2016 13:16:20 +0800
Peter Xu  wrote:

> Hi, Steven,
> 
> On Fri, Mar 04, 2016 at 08:23:11AM -0500, Steven Rostedt wrote:
> > My idea for a trace-cmd server, is to have a --client operation, for
> > running on the guest.
> > 
> >  trace-cmd server --client 
> > 
> > The connection will be some socket, either network or something
> > directly attached to the host.
> > 
> > Then on the host, we can have
> > 
> >   trace-cmd server --connect 
> > 
> > Where the server will create a connection to the guest.
> > 
> > And then, you could run on the host:
> > 
> >   trace-cmd record  --connect  
> > 
> > And this will start recording host events, and then connect to the
> > local server that connects to the guest(s) and that will start tracing
> > on the guest as well.
> > 
> > Then events on the guest will be passed to the host server.
> > 
> > Something like this is my idea. We can work out the details on the best
> > way to get things working. We may be able to eliminate the host server
> > middle man. But I envision that we need a trace-cmd server running on
> > the guest to start off the commands.
> 
> Not sure whether fully I understand the above, it seems that we can
> remove the host server middle man (as you have mentioned). Moreover,
> I am not sure whether we can use this for multiple hosts as well,

Honest question, what's the multiple hosts use-case?

I would start by thinking about the most simple use-case: a host
and a guest with a single vCPU. Then add vCPUs, and then add multiple
guests.

[Qemu-devel] [RFC] host and guest kernel trace merging

[Luiz Capitulino]

Very recently, trace-cmd got a few new features that allow you
to merge the host and guest kernel traces using the host TSC.

Those features originated in the tracing we're doing to debug spikes
in real-time KVM. However, as real-time KVM uses a very specific
setup and as we have so far debugged a very simple application,
I'm wondering: is this feature useful for the general, non-realtime,
use-cases?

If the answer is yes, then I've got several ideas on how to
make host and guest trace merging extremely simple to use.

I'll first describe how we do tracing for real-time KVM. Then
I'll give some suggestions on how to use the same procedure
for unpinned use-cases. Lastly, I'll talk about how we could
make it easy to use.

Real-time KVM host and guest tracing


In real-time KVM, each guest's vCPU is pinned to a different host
core. The real-time application running in the guest is also pinned.
When we get a spike, we know in which guest CPU it ocurred, and
so we know in which host core this CPU was running. All we have to
do is to get a trace of that guest CPU/host core pair.

1. Setup


You'll need the following:

 1. A stable TSC
 2. The TSC offset of the guest you want to debug
(see below)
 3. Have your guest transfer a file to your
host someway (I use networking)
 4. Latest trace-cmd.git in both host and guest
(HEAD c21aae2c or later)

To get the TSC offset of the guest, you can use the kvm_write_tsc_offset
tracepoint in the host. I use this script to do it:

 http://people.redhat.com/~lcapitul/real-time/start-debug-guest

Yes, it sucks. I have an idea on how to improve this (keep reading).

2. Tracing
--

In summary, what you have to do is:

 1. run trace-cmd start -C x86-tsc in the host
 2. run trace-cmd record -C x86-tsc in the guest
 3. run trace-cmd stop in the host
 4. run trace-cmd extract in the host
 4. copy the guest's trace.dat file to a known
location in the host

This guest script does all that:

 http://people.redhat.com/~lcapitul/real-time/trace-host-and-guest

I run it like this:

 # trace-host-and-guest cyclictest -q -n -b10 --notrace

3. Merging
--

Merging is simple:

 $ trace-cmd report -i host-trace.dat --ts-offset $((GUEST-TSC-offset)) \
-i guest-trace.dat

For real-time KVM, we also want to see the difference in nanoseconds
of each line in the trace so we use additional options:

 $ trace-cmd report --ts-diff --ts2secs HOST-Hz -t \
-i host-trace.dat --ts-offset $((GUEST-TSC-offset)) \
-i guest-trace.dat

Here's a real example:

 $ trace-cmd report --ts-diff --ts2secs 260 -t \
-i host-trace.dat --ts-offset $((18443676333795429734)) \
-i guest-trace.dat

And here's a little extract of a merged trace where the host injects
a timer interrupt, the guest handles it and reprograms the next
hrtimer timer. The value in "()" is how many nanoseconds it took
between the previous and the following line:

 host-trace.dat: qemu-kvm-3699  [004] [004]  6196.749398857: (+88)
function: kvm_inject_pending_timer_irqs <-- kvm_arch_vcpu_ioctl_run
 host-trace.dat: qemu-kvm-3699  [004] [004]  6196.749398990: (+133)   
kvm_entry:vcpu 0
guest-trace.dat:   -0 [000] [000]  6196.749399096: (+106)   
function: hrtimer_interrupt <-- local_apic_timer_interrupt
guest-trace.dat:   -0 [000] [000]  6196.749399123: (+27)
function: hrtimer_wakeup <-- __run_hrtimer
guest-trace.dat:   -0 [000] [000]  6196.749399183: (+60)
function: tick_program_event <-- hrtimer_interrupt
 host-trace.dat: qemu-kvm-3699  [004] [004]  6196.749399219: (+36)
kvm_exit: reason MSR_WRITE rip 0x8104bf58 info 0 0
 host-trace.dat: qemu-kvm-3699  [004] [004]  6196.749399260: (+41)
function: kvm_set_lapic_tscdeadline_msr <-- kvm_set_msr_common
 host-trace.dat: qemu-kvm-3699  [004] [004]  6196.749399283: (+23)
function: hrtimer_start <-- start_apic_timer
 host-trace.dat: qemu-kvm-3699  [004] [004]  6196.749399336: (+53)
kvm_entry:vcpu 0

Unpinned use-cases
==

If you can't pin the guest vCPU threads and the guest application like
we do in real-time KVM, you could try the following:

 * If your guest has a single CPU, or you want to trace a
   specific guest vCPU then try to pass -P vCPU-TID when
   running "trace-cmd record start" in the host

 * If you want to trace multiple vCPUs, I think you could
   try to trace all cores where the vCPUs could run with -M.
   Then you could try to merge this with the guest trace and
   see if you get a single timeline of all cores and guests CPUs

trace-cmd-server


Everything I described could look like this:

  # trace-cmd server [ in 

[Qemu-devel] [PATCH] memory: exit when hugepage allocation fails if mem-prealloc

[Luiz Capitulino]

When -mem-prealloc is passed on the command-line, the expected
behavior is to exit if the hugepage allocation fails.  However,
this behavior is broken since commit cc57501dee which made
hugepage allocation fall back to regular ram in case of faliure.

This commit restores the expected behavior for -mem-prealloc.

Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
---
 numa.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/numa.c b/numa.c
index 425ef8d..0e1638d 100644
--- a/numa.c
+++ b/numa.c
@@ -418,12 +418,13 @@ static void allocate_system_memory_nonnuma(MemoryRegion 
*mr, Object *owner,
 Error *err = NULL;
 memory_region_init_ram_from_file(mr, owner, name, ram_size, false,
  mem_path, );
-
-/* Legacy behavior: if allocation failed, fall back to
- * regular RAM allocation.
- */
 if (err) {
 error_report_err(err);
+if (mem_prealloc)
+exit(1);
+/* Legacy behavior: if allocation failed, fall back to
+ * regular RAM allocation.
+ */
 memory_region_init_ram(mr, owner, name, ram_size, _fatal);
 }
 #else
-- 
2.1.0

Re: [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer

[Luiz Capitulino]

On Thu, 17 Dec 2015 18:10:59 +0530 (IST)
P J P <ppan...@redhat.com> wrote:

>Hello,
> 
> An OOB write issue was reported by Mr Ling Liu, CC'd here. It occurs while 
> processing the 'sendkey' command, if the command argument was longer than
> the 'keyname_buf[16]' buffer.

Markus, are you planning a pull request soon?

Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>

> 
> ===
> From b0363f4c0e91671064dd7ffece8a6923c8dcaf20 Mon Sep 17 00:00:00 2001
> From: Prasad J Pandit <p...@fedoraproject.org>
> Date: Thu, 17 Dec 2015 17:47:15 +0530
> Subject: [PATCH] hmp: avoid redundant null termination of buffer
> 
> When processing 'sendkey' command, hmp_sendkey routine null
> terminates the 'keyname_buf' array. This results in an OOB write
> issue, if 'keyname_len' was to fall outside of 'keyname_buf' array.
> Removed the redundant null termination, as pstrcpy routine already
> null terminates the target buffer.
> 
> Reported-by: Ling Liu <liuling...@360.cn>
> Signed-off-by: Prasad J Pandit <p...@fedoraproject.org>
> ---
>   hmp.c | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/hmp.c b/hmp.c
> index 2140605..e530c9c 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -1746,9 +1746,7 @@ void hmp_sendkey(Monitor *mon, const QDict *qdict)
>   /* Be compatible with old interface, convert user inputted "<" */
>   if (!strncmp(keyname_buf, "<", 1) && keyname_len == 1) {
>   pstrcpy(keyname_buf, sizeof(keyname_buf), "less");
> -keyname_len = 4;
>   }
> -keyname_buf[keyname_len] = 0;
> 
>   keylist = g_malloc0(sizeof(*keylist));
>   keylist->value = g_malloc0(sizeof(*keylist->value));

Re: [Qemu-devel] [PATCH] misc: spelling

[Luiz Capitulino]

On Fri, 18 Dec 2015 13:58:45 +0100
Markus Armbruster <arm...@redhat.com> wrote:

> Copying maintainer just for completeness.  I'm sure Luiz won't at all
> mind this going through trivial ;)
> 
> Let's clarify the commit message:
> 
> monitor: Spelling fix
> 
> With that:
> 
> Reviewed-by: Markus Armbruster <arm...@redhat.com>

Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>

> 
> marcandre.lur...@redhat.com writes:
> 
> > From: Marc-André Lureau <marcandre.lur...@redhat.com>
> >
> > ---
> >  monitor.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/monitor.c b/monitor.c
> > index e7e7ae2..51ec4c3 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -311,7 +311,7 @@ static void monitor_flush_locked(Monitor *mon)
> >  return;
> >  }
> >  if (rc > 0) {
> > -/* partinal write */
> > +/* partial write */
> >  QString *tmp = qstring_from_str(buf + rc);
> >  QDECREF(mon->outbuf);
> >  mon->outbuf = tmp;
> 

Re: [Qemu-devel] RFC: libyajl for JSON

[Luiz Capitulino]

On Tue, 03 Nov 2015 08:17:58 +0100
Markus Armbruster  wrote:

> > So at this point, I want to see if lloyd makes any progress towards an
> > actual yajl release and/or adding a co-maintainer, before even trying to
> > get formal upstream support for single quoting.  We could always create
> > a git submodule with our own choice of fork (since there are already
> > forks that do single-quote parsing) - but the mantra of 'upstream first'
> > has a lot of merit (I'm reluctant to fork without good reason).
> 
> The value proposition of replacing our flawed JSON parser isn't in
> saving big on maintenance, it's in not having to find and fix its flaws.
> 
> If the replacement needs a lot of work to fit our needs, the value
> proposition becomes negative.
> 
> A JSON parser shouldn't require much maintenance, as JSON is simple,
> doesn't change, and parsing has few system dependencies.

Let me suggest this crazy idea: have you guys considered breaking
compatibility?

Re: [Qemu-devel] RFC: libyajl for JSON

[Luiz Capitulino]

On Tue, 3 Nov 2015 14:53:59 +0100
Paolo Bonzini <pbonz...@redhat.com> wrote:

> On 03/11/2015 14:46, Luiz Capitulino wrote:
> >> > Can you explain why that would make sense? :)  (Especially since there
> >> > is another extension---JSON5---that does exactly what we're doing, so it
> >> > probably wasn't that stupid an idea).
> > Let's be pragmatic. *If* this is the only issue stopping us from
> > dropping our own parser in favor of something more widely used and
> > *if* libvirt doesn't make use of the feature, it's something we
> > should strongly consider.
> 
> I'm not sure what's so bad about our parser that makes it worthwhile to:

It's not that it's bad. It's about the advantages of dropping hundreds of
lines of NIH code and switching to something more widely used. Also,
any maintenance time we spend on libyajl will also be automatically
enjoyed by libvirt which is excellent.

On the other hand, I don't want to push too hard for it because I do
recognize that switching has a cost and I won't be able to help with
that myself.

> 1) uglify all tests and make them inconsistent with the QAPI schemas,
> which also uses single-quoted strings

This doesn't seem hard to fix, we could pre-process the test files,
say in Python, to add the needed escaping.

> 2) waste time finding a replacement for % interpolation (the best
> replacement here would be to rewrite the tests in Python IMHO, but
> that's not a small ask)

Is this only used by tests? Can you give an example of this feature?

> 
> Just let's remove the weird (to not say worse) usage of QDict/QList to
> store tokens...
> 
> Paolo
> 

Re: [Qemu-devel] RFC: libyajl for JSON

[Luiz Capitulino]

On Tue, 3 Nov 2015 14:38:38 +0100
Paolo Bonzini <pbonz...@redhat.com> wrote:

> 
> 
> On 03/11/2015 14:19, Luiz Capitulino wrote:
> > > The value proposition of replacing our flawed JSON parser isn't in
> > > saving big on maintenance, it's in not having to find and fix its flaws.
> > > 
> > > If the replacement needs a lot of work to fit our needs, the value
> > > proposition becomes negative.
> > > 
> > > A JSON parser shouldn't require much maintenance, as JSON is simple,
> > > doesn't change, and parsing has few system dependencies.
> > 
> > Let me suggest this crazy idea: have you guys considered breaking
> > compatibility?
> 
> Can you explain why that would make sense? :)  (Especially since there
> is another extension---JSON5---that does exactly what we're doing, so it
> probably wasn't that stupid an idea).

Let's be pragmatic. *If* this is the only issue stopping us from
dropping our own parser in favor of something more widely used and
*if* libvirt doesn't make use of the feature, it's something we
should strongly consider.

Re: [Qemu-devel] RFC: libyajl for JSON

[Luiz Capitulino]

On Tue, 3 Nov 2015 06:40:32 -0700
Eric Blake <ebl...@redhat.com> wrote:

> On 11/03/2015 06:19 AM, Luiz Capitulino wrote:
> > On Tue, 03 Nov 2015 08:17:58 +0100
> > Markus Armbruster <arm...@redhat.com> wrote:
> > 
> >>> So at this point, I want to see if lloyd makes any progress towards an
> >>> actual yajl release and/or adding a co-maintainer, before even trying to
> >>> get formal upstream support for single quoting.  We could always create
> >>> a git submodule with our own choice of fork (since there are already
> >>> forks that do single-quote parsing) - but the mantra of 'upstream first'
> >>> has a lot of merit (I'm reluctant to fork without good reason).
> >>
> >> The value proposition of replacing our flawed JSON parser isn't in
> >> saving big on maintenance, it's in not having to find and fix its flaws.
> >>
> >> If the replacement needs a lot of work to fit our needs, the value
> >> proposition becomes negative.
> >>
> >> A JSON parser shouldn't require much maintenance, as JSON is simple,
> >> doesn't change, and parsing has few system dependencies.
> > 
> > Let me suggest this crazy idea: have you guys considered breaking
> > compatibility?
> 
> As in, requiring QMP clients to send "quotes" rather than 'quotes'?

Yes.

> It's worth considering (we already guarantee that our output is strict
> JSON, and that the 'quotes' on input is merely for convenience).  If we
> want to go that route, than 2.5 should document loudly that we are
> deprecating 'quotes' in QMP, so that 2.6 can actually remove it when
> switching to yajl.  

I'd go for more craziness: disable the feature for the next release
and watch. If we suddenly found out that there are some big users of
the feature, we back off and re-enable it on a -stable release.

> And as single quotes appears to be the only JSON
> extension we have been relying on, I think that would indeed free us
> from having to wait for a yajl release or carry our own yajl fork.
> 
> Interesting idea; I'm still thinking whether it would help us more than
> it would hurt lazy clients that were depending on the extension.

The point is, apart from libvirt, I've never heard of any serious QMP
client that's not a simple automation script. And I'd bet those are
sending in "quotes" to talk to QMP.

Re: [Qemu-devel] RFC: libyajl for JSON

[Luiz Capitulino]

[I thought I had replied to this thread, but it doesn't seem so. So,
 I'll try again]

On Fri, 30 Oct 2015 13:45:48 -0600
Eric Blake  wrote:

> Loaded question in response to
> https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg06988.html, but
> posting as a new thread to call attention to it:
> 
> Libvirt uses libyajl to parse and format JSON. Would it be worth
> dragging in yet another prerequisite library into qemu and reuse
> libyajl's parser instead of our own hand-rolled one?

I'd be in favor of that.

I don't exactly remember why we didn't use an external library like
libyajl. Maybe it was unknown to us, or maybe having an external dep
was too painful at the time. But I do remember we looked at having
something we could merge in QEMU source code, and everything we found
had license issues.

> 
> I know that a while ago, the answer was "as long as we support
> out-of-the-box builds on RHEL 5, that platform lacks yajl therefore we
> can't depend on it" (and libvirt's solution on RHEL 5 is "qemu doesn't
> support QMP and thus doesn't use JSON and thus libvirt doesn't need yajl
> there").
> 
> But now that we have just recently bumped the minimum glib and python
> versions to something not available on RHEL 5, it may also be time to
> start thinking about outsourcing to libyajl, because as far as I can
> tell, every platform that currently supports qemu out of the box has a
> version of libyajl. And since libvirt has already figured out the grunt
> work of how to simultaneously code to both the 1.x and 2.x APIs, it's
> not that much of a stretch to reuse that work in qemu.
> 
> On the other hand, one of the "features" of qemu's hand-rolled json
> parser is the ability to do qobject_from_jsonf("{'foo':%s}", "bar")
> (that is, we extended JSON with our notion of single-quoted strings, and
> with our notion of %s and similar escape sequences for piecing together
> multiple inputs into a single input stream without having to first
> g_strdup_printf our pieces into a single string).  I don't know if
> libyajl lets us add extensions to the language it parses.
> 

Re: [Qemu-devel] [PATCH] monitor: Plug memory leak on QMP error

[Luiz Capitulino]

On Thu, 29 Oct 2015 12:15:09 +0100
Markus Armbruster <arm...@redhat.com> wrote:

> Leak introduced in commit 8a4f501..710aec9, v2.4.0.
> 
> Signed-off-by: Markus Armbruster <arm...@redhat.com>

Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>

I think this can go through your tree?

> ---
>  monitor.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/monitor.c b/monitor.c
> index 301a143..c59e85b 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -3862,6 +3862,7 @@ static void handle_qmp_command(JSONMessageParser 
> *parser, QList *tokens)
>  err_out:
>  monitor_protocol_emitter(mon, data, local_err);
>  qobject_decref(data);
> +error_free(local_err);
>  QDECREF(input);
>  QDECREF(args);
>  }

Re: [Qemu-devel] [PATCH] monitor: Plug memory leak on QMP error

[Luiz Capitulino]

On Thu, 29 Oct 2015 17:23:43 +0100
Markus Armbruster <arm...@redhat.com> wrote:

> Luiz Capitulino <lcapitul...@redhat.com> writes:
> 
> > On Thu, 29 Oct 2015 12:15:09 +0100
> > Markus Armbruster <arm...@redhat.com> wrote:
> >
> >> Leak introduced in commit 8a4f501..710aec9, v2.4.0.
> >> 
> >> Signed-off-by: Markus Armbruster <arm...@redhat.com>
> >
> > Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>
> 
> Thanks!
> 
> > I think this can go through your tree?
> 
> Yes, along with the json-streamer work.

Do you need my review for that one? It's been ages that I don't
look at that code, I'm not sure it's going to be that worthwhile.

Re: [Qemu-devel] [PATCH 0/6] qobject: Make conversion from QObject * accept null

[Luiz Capitulino]

On Thu, 15 Oct 2015 16:15:31 +0200
Markus Armbruster <arm...@redhat.com> wrote:

> The qobject_to_FOO() crash on null, which is a trap for the unwary.
> Return null instead, and simplify a few callers.
> 
> Throw in a patch to drop QObject_HEAD.
> 
> Luiz, I'm happy to take this through my tree, since got a QMP series
> based on it (to be posted shortly).

Please do.

Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>

Btw, what do you think about this patch? :)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9bd2b8f..aa03f3d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1010,7 +1010,7 @@ F: qemu-timer.c
 F: vl.c
 
 Human Monitor (HMP)
-M: Luiz Capitulino <lcapitul...@redhat.com>
+M: Markus Armbruster <arm...@redhat.com>
 S: Maintained
 F: monitor.c
 F: hmp.c
@@ -1073,7 +1073,7 @@ F: qapi/*.json
 T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 QObject
-M: Luiz Capitulino <lcapitul...@redhat.com>
+M: Markus Armbruster <arm...@redhat.com>
 S: Maintained
 F: qobject/
 F: include/qapi/qmp/

Re: [Qemu-devel] [PATCH 1/1] log hmp/qmp command

[Luiz Capitulino]

On Mon, 12 Oct 2015 11:41:35 +0300
"Denis V. Lunev" <d...@openvz.org> wrote:

> From: Pavel Butsykin <pbutsy...@virtuozzo.com>
> 
> This log would be very welcome for long-term diagnostics of the system
> in the production. This log is at least necessary to understand what
> has been happened on the system and to identify issues at higher-level
> subsystems (libvirt, etc).

This is good to have, and probably we should have had it since day one.
But I have the following considerations:

 - libvirt would need support for this to use it the way you describe,
   although libvirt already has its logging facility (well, one could
   wrap qemu in bash and pass this by default but this is not ideal)

 - A true logging facility would also log responses and events

 - I don't think it's important to log HMP

> 
> Signed-off-by: Pavel Butsykin <pbutsy...@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <d...@openvz.org>
> CC: Markus Armbruster <arm...@redhat.com>
> CC: Luiz Capitulino <lcapitul...@redhat.com>
> CC: Eric Blake <ebl...@redhat.com>
> ---
>  include/qemu/log.h | 1 +
>  monitor.c  | 4 
>  qemu-log.c | 1 +
>  3 files changed, 6 insertions(+)
> 
> diff --git a/include/qemu/log.h b/include/qemu/log.h
> index f880e66..dfb587e 100644
> --- a/include/qemu/log.h
> +++ b/include/qemu/log.h
> @@ -41,6 +41,7 @@ static inline bool qemu_log_enabled(void)
>  #define LOG_UNIMP  (1 << 10)
>  #define LOG_GUEST_ERROR(1 << 11)
>  #define CPU_LOG_MMU(1 << 12)
> +#define LOG_CMD(1 << 13)
>  
>  /* Returns true if a bit is set in the current loglevel mask
>   */
> diff --git a/monitor.c b/monitor.c
> index 4f1ba2f..a22a798 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2848,6 +2848,8 @@ static void handle_hmp_command(Monitor *mon, const char 
> *cmdline)
>  QDict *qdict;
>  const mon_cmd_t *cmd;
>  
> +qemu_log_mask(LOG_CMD, "hmp \"%s\" requested\n", cmdline);
> +
>  cmd = monitor_parse_command(mon, , mon->cmd_table);
>  if (!cmd) {
>  return;
> @@ -3822,6 +3824,8 @@ static void handle_qmp_command(JSONMessageParser 
> *parser, QList *tokens)
>  error_setg(_err, QERR_JSON_PARSING);
>  goto err_out;
>  }
> +qemu_log_mask(LOG_CMD, "qmp \"%s\" requested\n",
> +  qobject_to_json(obj)->string);
>  
>  input = qmp_check_input_obj(obj, _err);
>  if (!input) {
> diff --git a/qemu-log.c b/qemu-log.c
> index 13f3813..66b15ec 100644
> --- a/qemu-log.c
> +++ b/qemu-log.c
> @@ -119,6 +119,7 @@ const QEMULogItem qemu_log_items[] = {
>  { LOG_GUEST_ERROR, "guest_errors",
>"log when the guest OS does something invalid (eg accessing a\n"
>"non-existent register)" },
> +{ LOG_CMD, "cmd", "log the hmp/qmp commands execution" },
>  { 0, NULL, NULL },
>  };
>  

Re: [Qemu-devel] [PATCH 0/3] MAINTAINERS docs: flatten docs/qmp/, specify include and test files

[Luiz Capitulino]

On Thu, 24 Sep 2015 18:11:54 +0200
Markus Armbruster <arm...@redhat.com> wrote:

> Markus Armbruster (3):
>   docs: Move files from docs/qmp/ to docs/
>   MAINTAINERS: Specify QObject include and test files
>   MAINTAINERS: Specify QAPI include and test files
> 
>  MAINTAINERS| 15 ++-
>  docs/{qmp => }/qmp-events.txt  |  0
>  docs/{qmp/README => qmp-intro.txt} |  0
>  docs/{qmp => }/qmp-spec.txt|  0
>  4 files changed, 14 insertions(+), 1 deletion(-)
>  rename docs/{qmp => }/qmp-events.txt (100%)
>  rename docs/{qmp/README => qmp-intro.txt} (100%)
>  rename docs/{qmp => }/qmp-spec.txt (100%)
> 

Reviewed-by: Luiz Capitulino <lcapitul...@redhat.com>

Re: [Qemu-devel] [PATCH 04/29] Introduce QDict

[Luiz Capitulino]

On Fri, 11 Sep 2015 20:22:38 -0400
Programmingkid  wrote:

> Could you make a tutorial on how to use the QDict type?

There are several examples in tests/check-qdict.c.

Re: [Qemu-devel] [PATCH 2/4] monitor: remove target-specific code from monitor.c

[Luiz Capitulino]

On Tue, 8 Sep 2015 11:54:46 +0200
Paolo Bonzini  wrote:

> 
> 
> On 08/09/2015 09:09, Denis V. Lunev wrote:
> >  qemu-monitor-info.texi   | 151 +++
> 
> This should be added in patch 4, not now.
> 
> > +const MonitorDef *target_monitor_defs(void) __attribute__((weak));
> > +
> > +const MonitorDef *target_monitor_defs(void)
> > +{
> > +return NULL;
> > +}
> 
> Weak symbols do not work on all platforms.  Luckily, making libqemustub
> a static library gets exactly the same result without the need for weak
> symbols: the definition from the QEMU object files will hide the stub.
> 
> You just need to remove __attribute__((weak)), and it should just work.
> 
> Otherwise, the patches look good to me.  Luiz, do you have time to post
> a pull request for v4, or do you want to pass HMP maintainership as well
> to someone else?

It would be great to pass it to someone else.

Re: [Qemu-devel] [PATCH 2/4] monitor: remove target-specific code from monitor.c

[Luiz Capitulino]

On Tue, 8 Sep 2015 09:04:56 -0400 (EDT)
Paolo Bonzini  wrote:

> 
> > > This should be added in patch 4, not now.
> > > 
> > > > +const MonitorDef *target_monitor_defs(void) __attribute__((weak));
> > > > +
> > > > +const MonitorDef *target_monitor_defs(void)
> > > > +{
> > > > +return NULL;
> > > > +}
> > > 
> > > Weak symbols do not work on all platforms.  Luckily, making libqemustub
> > > a static library gets exactly the same result without the need for weak
> > > symbols: the definition from the QEMU object files will hide the stub.
> > > 
> > > You just need to remove __attribute__((weak)), and it should just work.
> > > 
> > > Otherwise, the patches look good to me.  Luiz, do you have time to post
> > > a pull request for v4, or do you want to pass HMP maintainership as well
> > > to someone else?
> > 
> > It would be great to pass it to someone else.
> 
> I can take the next version of these patches then.  

Thanks a lot! These are the patches I have pending for review:

- [PATCH qemu 0/2] monitor/ppc: Print correct SPRs
- [PATCH] trace-events: Add hmp completion
- [PATCH v3 0/4] Move target- and device specific code from monitor

> However, please make that
> someone else also be someone other than me. :-)

Well, we've always been short on maintainers...

Re: [Qemu-devel] [PATCH] qmp-shell: add documentation

[Luiz Capitulino]

On Thu, 23 Jul 2015 09:36:38 +0200
Markus Armbruster arm...@redhat.com wrote:

 John Snow js...@redhat.com writes:
 
  On 07/02/2015 11:31 AM, Luiz Capitulino wrote:
  On Wed,  1 Jul 2015 14:25:49 -0400
  John Snow js...@redhat.com wrote:
  
  I should probably document the changes that were made.
 
 John, what do you mean here?
 
  Signed-off-by: John Snow js...@redhat.com
  
  Looks good to me, CC'ing maintainer.
 
 Luiz, is this a R-by?

Reviewed-by: Luiz Capitulino lcapitul...@redhat.com

This one is :)

 
  Whoops, didn't realize Markus took this file over, too. Sorry Luiz.
 
 Don't worry about our maintainer reshuffling.
 
  Markus, would you consider staging this? It's purely a documentation
  update for only a dev tool, so it doesn't really matter /when/ it lands
  either way, just shoring up some changes I made a while back to the
  interpreter here.
 
  tldr: ping
 
 I'm happy to include this in the next pull after it got reviewed.  I'm
 ignorant about qmp-shell, because I don't use it myself, so I'd have to
 dig through it to verify your documentation is accurate and reasonably
 complete.
 
 Fishing for more qualified reviewers:
 
 $ scripts/get_maintainer.pl --git-blame -f scripts/qmp/qmp-shell 
 Markus Armbruster arm...@redhat.com (supporter:QMP)
 Luiz Capitulino lcapitul...@redhat.com (authored 
 lines:230/390=59%,commits:10/10=100%)
 John Snow js...@redhat.com (authored lines:117/390=30%,commits:4/10=40%)
 Daniel P. Berrange berra...@redhat.com (authored lines:27/390=7%)
 Eric Blake ebl...@redhat.com (commits:6/10=60%)
 Stefan Hajnoczi stefa...@redhat.com (commits:2/10=20%)
 Benoit Canet ben...@irqsave.net (commits:1/10=10%)
 
 Luiz, can you review for accuracy and reasonable completeness?
 
 Of course, I'm the reviewer of last resort for anything I maintain,
 whether I understand it or not :)
 

Re: [Qemu-devel] [PATCH v5] hmp: add info iothreads command

[Luiz Capitulino]

On Fri, 26 Jun 2015 16:07:13 +0800
Ting Wang kathy.wangt...@huawei.com wrote:

 Make info iothreads available on the HMP monitor.
 
 For example, the results are as follows when executing qemu
 command with -object iothread,id=iothread-1 -object 
 iothread,id=iothread-2.
 (qemu) info iothreads
 iothread-1: thread_id=123
 iothread-2: thread_id=456
 
 Signed-off-by: Ting Wang kathy.wangt...@huawei.com

Reviewed-by: Luiz Capitulino lcapitul...@redhat.com

Markus will take this patch via his tree.

 ---
 v5: use for instead of while
 ---
  hmp-commands.hx |  2 ++
  hmp.c   | 13 +
  hmp.h   |  1 +
  monitor.c   |  7 +++
  4 files changed, 23 insertions(+)execute
 
 diff --git a/hmp-commands.hx b/hmp-commands.hx
 index d3b7932..c8c8d79 100644
 --- a/hmp-commands.hx
 +++ b/hmp-commands.hx
 @@ -1790,6 +1790,8 @@ show roms
  show the TPM device
  @item info memory-devices
  show the memory devices
 +@item info iothreads
 +show iothreads
  @end table
  ETEXI
  
 diff --git a/hmp.c b/hmp.c
 index 070aaf8..7192494 100644
 --- a/hmp.c
 +++ b/hmp.c
 @@ -1963,6 +1963,19 @@ void hmp_info_memory_devices(Monitor *mon, const QDict 
 *qdict)
  qapi_free_MemoryDeviceInfoList(info_list);
  }
  
 +void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
 +{
 +IOThreadInfoList *info_list = qmp_query_iothreads(NULL);
 +IOThreadInfoList *info;
 +
 +for (info = info_list; info; info = info-next) {
 +monitor_printf(mon, %s: thread_id=% PRId64 \n,
 +   info-value-id, info-value-thread_id);
 +}
 +
 +qapi_free_IOThreadInfoList(info_list);
 +}
 +
  void hmp_qom_list(Monitor *mon, const QDict *qdict)
  {
  const char *path = qdict_get_try_str(qdict, path);
 diff --git a/hmp.h b/hmp.h
 index 0cf4f2a..c139a97 100644
 --- a/hmp.h
 +++ b/hmp.h
 @@ -39,6 +39,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
  void hmp_info_pci(Monitor *mon, const QDict *qdict);
  void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
  void hmp_info_tpm(Monitor *mon, const QDict *qdict);
 +void hmp_info_iothreads(Monitor *mon, const QDict *qdict);
  void hmp_quit(Monitor *mon, const QDict *qdict);
  void hmp_stop(Monitor *mon, const QDict *qdict);
  void hmp_system_reset(Monitor *mon, const QDict *qdict);
 diff --git a/monitor.c b/monitor.c
 index aeea2b5..917e827 100644
 --- a/monitor.c
 +++ b/monitor.c
 @@ -2850,6 +2850,13 @@ static mon_cmd_t info_cmds[] = {
  .mhandler.cmd = hmp_info_memory_devices,
  },
  {
 +.name   = iothreads,
 +.args_type  = ,
 +.params = ,
 +.help   = show iothreads,
 +.mhandler.cmd = hmp_info_iothreads,
 +},
 +{
  .name   = rocker,
  .args_type  = name:s,
  .params = name,

Re: [Qemu-devel] [PATCH] qmp-shell: add documentation

[Luiz Capitulino]

On Wed,  1 Jul 2015 14:25:49 -0400
John Snow js...@redhat.com wrote:

 I should probably document the changes that were made.
 
 Signed-off-by: John Snow js...@redhat.com

Looks good to me, CC'ing maintainer.

 ---
  scripts/qmp/qmp-shell | 35 +++
  1 file changed, 35 insertions(+)
 
 diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell
 index 65280d2..fa39bf0 100755
 --- a/scripts/qmp/qmp-shell
 +++ b/scripts/qmp/qmp-shell
 @@ -29,6 +29,41 @@
  # (QEMU) device_add driver=e1000 id=net1
  # {u'return': {}}
  # (QEMU)
 +#
 +# key=value pairs also support Python or JSON object literal subset 
 notations,
 +# without spaces. Dictionaries/objects {} are supported as are arrays [].
 +#
 +#example-command arg-name1={'key':'value','obj'={'prop':value}}
 +#
 +# Both JSON and Python formatting should work, including both styles of
 +# string literal quotes. Both paradigms of literal values should work,
 +# including null/true/false for JSON and None/True/False for Python.
 +#
 +#
 +# Transactions have the following multi-line format:
 +#
 +#transaction(
 +#action-name1 [ arg-name1=arg1 ] ... [arg-nameN=argN ]
 +#...
 +#action-nameN [ arg-name1=arg1 ] ... [arg-nameN=argN ]
 +#)
 +#
 +# One line transactions are also supported:
 +#
 +#transaction( action-name1 ... )
 +#
 +# For example:
 +#
 +# (QEMU) transaction(
 +# TRANS block-dirty-bitmap-add node=drive0 name=bitmap1
 +# TRANS block-dirty-bitmap-clear node=drive0 name=bitmap0
 +# TRANS )
 +# {return: {}}
 +# (QEMU)
 +#
 +# Use the -v and -p options to activate the verbose and pretty-print options,
 +# which will echo back the properly formatted JSON-compliant QMP that is 
 being
 +# sent to QEMU, which is useful for debugging and documentation generation.
  
  import qmp
  import json

Re: [Qemu-devel] [PATCH v4] hmp: add info iothreads command

[Luiz Capitulino]

On Tue, 23 Jun 2015 13:57:08 +0200
Markus Armbruster arm...@redhat.com wrote:

 Ting Wang kathy.wangt...@huawei.com writes:
 
  Hi Luiz and Markus,
 
  Would you like to pick up this patch, which has
  been reviewed by Stefan and Fam?
 
 Looks like this fell through the cracks back in March.  You should've
 asked for merge much earlier.  Pinging the maintainer after two weeks is
 fair.
 
 I just did a monitor pull, and I can't yet say whether I'll do another
 for 2.4.

It would be great if you could pick this one, because I'll be out for
some days. I wouldn't mind this one going through the block tree either,
as the QMP command did go through it. Worst case I can merge this patch
and post a pull request right before hard freeze deadline.

 
 Quick review inline.
 
 
  Thanks.
 
  Ting
 
  On 2015-3-13 16:58, Ting Wang wrote:
  Make info iothreads available on the HMP monitor.
  
  The results are as follows:
  id1: thread_id=thread_id1
  id2: thread_id=thread_id2
 
 Actually, they are like
 
 id1: thread_id=123
 id2: thread_id=456
 
 Recommend to paste actual output from your testing.
 
  
  Signed-off-by: Ting Wang kathy.wangt...@huawei.com
  ---
  v4: use the PRId64 format specifier macro for the int64_t thread_id
  v3: fix comment and the trailing whitespace
  v2: add braces for if
  ---
   hmp-commands.hx |  2 ++
   hmp.c   | 22 ++
   hmp.h   |  1 +
   monitor.c   |  7 +++
   4 files changed, 32 insertions(+)
  
  diff --git a/hmp-commands.hx b/hmp-commands.hx
  index d5022d8..67d76ed 100644
  --- a/hmp-commands.hx
  +++ b/hmp-commands.hx
  @@ -1746,6 +1746,8 @@ show roms
   show the TPM device
   @item info memory-devices
   show the memory devices
  +@item info iothreads
  +show iothreads
   @end table
   ETEXI
   
  diff --git a/hmp.c b/hmp.c
  index 71c28bc..445a8ad 100644
  --- a/hmp.c
  +++ b/hmp.c
  @@ -821,6 +821,28 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
   qapi_free_TPMInfoList(info_list);
   }
   
  +void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
  +{
  +IOThreadInfoList *head = NULL, *elem = NULL;
  +
  +head = qmp_query_iothreads(NULL);
  +if (!head) {
  +monitor_printf(mon, No iothread has been added\n);
  +return;
  +}
 
 Printing something instead of nothing when the list is empty is matter
 of taste.  Consistency would be nice, though.  I know several commands
 that print nothing.  Can you quote commands printing something?
 
  +
  +elem = head;
  +while (elem) {
  +if (elem-value) {
  +monitor_printf(mon, %s: thread_id=% PRId64 \n, 
  elem-value-id,
  +elem-value-thread_id);
  +}
  +elem = elem-next;
  +}
 
 for (info = info_list; info; info = info-next) {
 monitor_printf(mon, %s: thread_id=% PRId64 \n,
elem-value-id, elem-value-thread_id);
 }
 
 1. for is more readable than while, because it has the full loop control
 in one place.
 
 2. List elements cannot be null, so don't bother checking for it.
 
  +
  +qapi_free_IOThreadInfoList(head);
  +}
  +
   void hmp_quit(Monitor *mon, const QDict *qdict)
   {
   monitor_suspend(mon);
  diff --git a/hmp.h b/hmp.h
  index 81177b2..d99090e 100644
  --- a/hmp.h
  +++ b/hmp.h
  @@ -38,6 +38,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
   void hmp_info_pci(Monitor *mon, const QDict *qdict);
   void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
   void hmp_info_tpm(Monitor *mon, const QDict *qdict);
  +void hmp_info_iothreads(Monitor *mon, const QDict *qdict);
   void hmp_quit(Monitor *mon, const QDict *qdict);
   void hmp_stop(Monitor *mon, const QDict *qdict);
   void hmp_system_reset(Monitor *mon, const QDict *qdict);
  diff --git a/monitor.c b/monitor.c
  index c86a89e..076a306 100644
  --- a/monitor.c
  +++ b/monitor.c
  @@ -2924,6 +2924,13 @@ static mon_cmd_t info_cmds[] = {
   .mhandler.cmd = hmp_info_memory_devices,
   },
   {
  +.name   = iothreads,
  +.args_type  = ,
  +.params = ,
  +.help   = show iothreads,
  +.mhandler.cmd = hmp_info_iothreads,
  +},
  +{
   .name   = NULL,
   },
   };
  
 

Re: [Qemu-devel] [PATCH 00/11] Sprint to the finish: purge QError

[Luiz Capitulino]

On Tue, 16 Jun 2015 15:08:41 +0200
Markus Armbruster arm...@redhat.com wrote:

 Luiz Capitulino lcapitul...@redhat.com writes:
 
  On Sat, 13 Jun 2015 16:20:47 +0200
  Markus Armbruster arm...@redhat.com wrote:
 
  After a bit over a year and many patches, QError is finally ripe.  All
  that's left of qerror.h after this series is a bunch of QERR_ macros.
  Killing them is left for another day.
 
  Excellent!
 
  I did my best to review this series, but unfortunately my review is
  a bit weak because I'm not that familiar with some code paths
  (like QemuOpts) and I was unable to apply patches starting with patch 04/11.
 
 Did you apply on top of my [PATCH v2 0/7] qdev: Mostly wean off
 QError?

No, I assumed it was already merged.

  But it does look good to me:
 
  Reviewed-by: Luiz Capitulino lcapitul...@redhat.com
 
 Thanks!
 

Re: [Qemu-devel] [PATCH 04/11] qerror: Eliminate QERR_DEVICE_NOT_FOUND

[Luiz Capitulino]

On Sat, 13 Jun 2015 16:20:51 +0200
Markus Armbruster arm...@redhat.com wrote:

 Error classes other than ERROR_CLASS_GENERIC_ERROR should not be used
 in new code.  Hiding them in QERR_ macros makes new uses hard to spot.
 Fortunately, there's just one such macro left.  Eliminate it with this
 coccinelle semantic patch:
 
 @@
 expression EP, E;
 @@
 -error_set(EP, QERR_DEVICE_NOT_FOUND, E)
 +error_set(EP, ERROR_CLASS_DEVICE_NOT_FOUND, Device '%s' not found, E)

This is a bit minor, but I think I'd have created a new function instead,
say error_set_enodev(). This avoids all the duplication. But I'm not asking
you to change, as the patch is good and this can be done in the future if
we so want.

 
 Signed-off-by: Markus Armbruster arm...@redhat.com
 ---
  backends/rng-egd.c|  3 ++-
  blockdev-nbd.c|  3 ++-
  blockdev.c| 33 ++---
  hmp.c |  6 --
  include/qapi/qmp/qerror.h |  3 ---
  net/net.c |  6 --
  qdev-monitor.c|  6 --
  qmp.c | 12 
  qom/object.c  |  6 --
  ui/input.c|  3 ++-
  10 files changed, 52 insertions(+), 29 deletions(-)
 
 diff --git a/backends/rng-egd.c b/backends/rng-egd.c
 index 2962795..849bd7a 100644
 --- a/backends/rng-egd.c
 +++ b/backends/rng-egd.c
 @@ -147,7 +147,8 @@ static void rng_egd_opened(RngBackend *b, Error **errp)
  
  s-chr = qemu_chr_find(s-chr_name);
  if (s-chr == NULL) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, s-chr_name);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, s-chr_name);
  return;
  }
  
 diff --git a/blockdev-nbd.c b/blockdev-nbd.c
 index 0d9df47..128e810 100644
 --- a/blockdev-nbd.c
 +++ b/blockdev-nbd.c
 @@ -91,7 +91,8 @@ void qmp_nbd_server_add(const char *device, bool 
 has_writable, bool writable,
  
  blk = blk_by_name(device);
  if (!blk) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, device);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, device);
  return;
  }
  if (!blk_is_inserted(blk)) {
 diff --git a/blockdev.c b/blockdev.c
 index a88ea76..8dec0cc 100644
 --- a/blockdev.c
 +++ b/blockdev.c
 @@ -1102,7 +1102,8 @@ SnapshotInfo 
 *qmp_blockdev_snapshot_delete_internal_sync(const char *device,
  
  blk = blk_by_name(device);
  if (!blk) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, device);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, device);
  return NULL;
  }
  bs = blk_bs(blk);
 @@ -1291,7 +1292,8 @@ static void 
 internal_snapshot_prepare(BlkTransactionState *common,
  /* 2. check for validation */
  blk = blk_by_name(device);
  if (!blk) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, device);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, device);
  return;
  }
  bs = blk_bs(blk);
 @@ -1571,7 +1573,8 @@ static void drive_backup_prepare(BlkTransactionState 
 *common, Error **errp)
  
  blk = blk_by_name(backup-device);
  if (!blk) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, backup-device);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, backup-device);
  return;
  }
  bs = blk_bs(blk);
 @@ -1841,7 +1844,8 @@ void qmp_eject(const char *device, bool has_force, bool 
 force, Error **errp)
  
  blk = blk_by_name(device);
  if (!blk) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, device);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, device);
  return;
  }
  
 @@ -1901,7 +1905,8 @@ void qmp_change_blockdev(const char *device, const char 
 *filename,
  
  blk = blk_by_name(device);
  if (!blk) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, device);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, device);
  return;
  }
  bs = blk_bs(blk);
 @@ -1960,7 +1965,8 @@ void qmp_block_set_io_throttle(const char *device, 
 int64_t bps, int64_t bps_rd,
  
  blk = blk_by_name(device);
  if (!blk) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, device);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, device);
  return;
  }
  bs = blk_bs(blk);
 @@ -2275,7 +2281,8 @@ void qmp_block_stream(const char *device,
  
  blk = blk_by_name(device);
  if (!blk) {
 -error_set(errp, QERR_DEVICE_NOT_FOUND, device);
 +error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
 +  Device '%s' not found, device);
  return;
  }
  bs = blk_bs(blk);
 @@ -2349,7 +2356,8 @@ void qmp_block_commit(const char 

Re: [Qemu-devel] [PATCH 00/11] Sprint to the finish: purge QError

[Luiz Capitulino]

On Sat, 13 Jun 2015 16:20:47 +0200
Markus Armbruster arm...@redhat.com wrote:

 After a bit over a year and many patches, QError is finally ripe.  All
 that's left of qerror.h after this series is a bunch of QERR_ macros.
 Killing them is left for another day.

Excellent!

I did my best to review this series, but unfortunately my review is
a bit weak because I'm not that familiar with some code paths
(like QemuOpts) and I was unable to apply patches starting with patch 04/11.

But it does look good to me:

Reviewed-by: Luiz Capitulino lcapitul...@redhat.com

 
 The diffstat looks a bit scary, but that's almost entirely due to
 mechanical changes like PATCH 05.
 
 This series applies on top of my [PATCH v2 0/7] qdev: Mostly wean off
 QError.
 
 Markus Armbruster (11):
   QemuOpts: Wean off qerror_report_err()
   vl: Avoid qerror_report() outside QMP command handlers
   vl: Use error_report() for --display errors
   qerror: Eliminate QERR_DEVICE_NOT_FOUND
   qerror: Clean up QERR_ macros to expand into a single string
   tpm: Avoid qerror_report() outside QMP command handlers
   qmp: Wean off qerror_report()
   qerror: Finally unused, clean up
   qerror: Move #include out of qerror.h
   Include qapi/qmp/qerror.h exactly where needed
   Include monitor/monitor.h exactly where needed
 
  audio/spiceaudio.c   |   1 +
  audio/wavcapture.c   |   1 +
  backends/hostmem.c   |   1 -
  backends/rng-egd.c   |  11 +--
  backends/rng-random.c|   6 +-
  backends/rng.c   |   2 +-
  backends/tpm.c   |   2 +-
  balloon.c|   5 +-
  block.c  |   4 +-
  block/backup.c   |   5 +-
  block/commit.c   |   3 +-
  block/curl.c |   1 +
  block/dmg.c  |   1 +
  block/io.c   |   1 +
  block/iscsi.c|   1 +
  block/mirror.c   |   9 +--
  block/qapi.c |   6 --
  block/qcow.c |   5 +-
  block/qcow2-snapshot.c   |   1 +
  block/qcow2.c|   4 +-
  block/qed.c  |   4 +-
  block/quorum.c   |   5 +-
  block/raw-posix.c|   2 +
  block/snapshot.c |   5 +-
  block/ssh.c  |   2 +
  block/stream.c   |   5 +-
  block/vhdx-log.c |   1 +
  block/vmdk.c |  14 ++--
  block/vvfat.c|   1 +
  blockdev-nbd.c   |   6 +-
  blockdev.c   |  80 -
  blockjob.c   |   9 +--
  cpus.c   |   9 +--
  dump.c   |  13 ++--
  hmp.c|  24 ---
  hw/9pfs/virtio-9p.c  |   1 +
  hw/char/serial-pci.c |   1 -
  hw/char/virtio-serial-bus.c  |   1 +
  hw/core/nmi.c|   2 +-
  hw/core/platform-bus.c   |   1 -
  hw/core/qdev-properties-system.c |   3 +-
  hw/core/qdev-properties.c|  12 ++--
  hw/core/qdev.c   |   9 +--
  hw/display/g364fb.c  |   1 +
  hw/display/qxl.c |   1 -
  hw/display/tcx.c |   1 +
  hw/dma/xilinx_axidma.c   |   1 -
  hw/i386/pc.c |   2 +-
  hw/ide/ahci.c|   2 +-
  hw/intc/openpic.c|   6 +-
  hw/misc/ivshmem.c|   2 +-
  hw/net/xilinx_axienet.c  |   1 -
  hw/pci/pci-stub.c|   3 +-
  hw/pci/pci.c |   1 +
  hw/pci/pcie.c|   1 -
  hw/pci/shpc.c|   1 -
  hw/ppc/spapr_pci.c   |   8 +--
  hw/ppc/spapr_vio.c   |   1 -
  hw/ppc/virtex_ml507.c|   2 +-
  hw/s390x/event-facility.c|   1 -
  hw/s390x/s390-virtio-bus.c   |   1 -
  hw/s390x/s390-virtio.c   |   4 +-
  hw/s390x/virtio-ccw.c|   2 +-
  hw/scsi/vhost-scsi.c |   1 +
  hw/timer/hpet.c  |   1 +
  hw/tpm/tpm_passthrough.c |   1 +
  hw/usb/bus.c |   1 +
  hw/usb/ccid-card-emulated.c  |   1 -
  hw/usb/ccid-card-passthru.c  |   2 +-
  hw/usb/dev-network.c |   2 +-
  hw/usb/dev-serial.c  |   2 +-
  hw/usb/dev-smartcard-reader.c|   1 -
  hw/usb/dev-storage.c |   1 +
  hw/usb/hcd-ehci.h|   1 -
  hw/usb/host-libusb.c |   1 +
  hw/usb/redirect.c|   9 +--
  hw/virtio/virtio-rng.c   |   1 -
  include/block/block_int.h|   2 -
  include/monitor/monitor.h|   9 +--
  include/monitor/qdev.h   |   5 +-
  include/net/net.h|   2 +-
  include/qapi/qmp/qerror.h|  85 +-
  include/qapi/qmp/qobject.h   |   1 -
  include/qemu/option.h

Re: [Qemu-devel] [PATCH v2 0/2] monitor+disas: Remove uses of ENV_GET_CPU

[Luiz Capitulino]

On Sun, 24 May 2015 14:20:39 -0700
Peter Crosthwaite crosthwaitepe...@gmail.com wrote:

 Neither the monitor or disassembly core has a good reason to navigate from an
 env pointer to a cpu pointer. Disas should not need env awarness at all, that
 is removed in P2.
 
 The monitor is trickier, the env is still needed by some #ifdef switched 
 target
 specific code but all common code only needs to trade in CPU pointers. As the
 monitor always has access to a CPU pointer naturally, remove ENV_GET_CPU 
 usages
 (P1).
 
 This is related to my multi-arch work, where the goal is to minimise use of
 architecture defined global definitions, ENV_GET_CPU being a major headache in
 that whole effort. The longer term goal is to limit ENV_GET_CPU use to 
 genuinely
 architecture specific code.
 
 But I think these two patches stand in their own right, so sending ahead of 
 the
 motherload series. This brings both modules closer to common-oby-y'ification.
 
 First RFC for multi arch is avaiable here:
 
 https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg01771.html
 
 The two patches are done together to avoid a conflict with monitor_disas which
 is touched by both patches. If one patch gets acked, the other nacked then
 either can be merged independently with trivial edits.

Unfortunately, I'm quite busy and won't have time to push this
through my tree. Markus is going to pick up this series soon.

Acked-by: Luiz Capitulino lcapitul...@redhat.com

 
 Changed since v1:
 Addressed RH and Andreas comments on P1.
 
 Peter Crosthwaite (2):
   monitor: Split mon_get_cpu fn to remove ENV_GET_CPU
   disas: Remove uses of CPU env
 
  disas.c   | 14 +-
  include/disas/disas.h |  4 +--
  include/qemu/log.h|  4 +--
  monitor.c | 65 
 +++
  target-alpha/translate.c  |  2 +-
  target-arm/translate-a64.c|  2 +-
  target-arm/translate.c|  2 +-
  target-cris/translate.c   |  2 +-
  target-i386/translate.c   |  2 +-
  target-lm32/translate.c   |  2 +-
  target-m68k/translate.c   |  2 +-
  target-microblaze/translate.c |  2 +-
  target-mips/translate.c   |  2 +-
  target-openrisc/translate.c   |  2 +-
  target-ppc/translate.c|  2 +-
  target-s390x/translate.c  |  2 +-
  target-sh4/translate.c|  2 +-
  target-sparc/translate.c  |  2 +-
  target-tricore/translate.c|  2 +-
  target-unicore32/translate.c  |  2 +-
  target-xtensa/translate.c |  2 +-
  21 files changed, 57 insertions(+), 64 deletions(-)
 

Re: [Qemu-devel] [PATCH v5 0/4] monitor: suggest running help for command errors

[Luiz Capitulino]

On Mon, 08 Jun 2015 10:53:23 +0200
Markus Armbruster arm...@redhat.com wrote:

 Copying HMP maintainer Luiz.
 
 Series
 Reviewed-by: Markus Armbruster arm...@redhat.com
 
 Bandan, thanks for your patience.
 
 Luiz, my monitor/QMP queue is currently empty, but if it fills up before
 you get around to doing a monitor/HMP pull request, I'm happy to take
 this series along, if it gets your Acked-by.

I'd be immensely grateful if you pick this series along with the
other ones, as we've spoken in pvt. Thanks a lot Markus for your
help!

Acked-by: Luiz Capitulino lcapitul...@redhat.com

Re: [Qemu-devel] [PATCH 0/2] Use bool for QBool

[Luiz Capitulino]

On Thu, 28 May 2015 15:54:12 -0400
Luiz Capitulino lcapitul...@redhat.com wrote:

 On Fri, 15 May 2015 16:24:58 -0600
 Eric Blake ebl...@redhat.com wrote:
 
  Passing around an 'int' for a QBool type is weird, when we already
  use a C99 compiler and have a sane 'bool' that does just fine.
  
  I half-debated sending this through qemu-trivial, but think it
  better belongs through the QMP tree.  There turned out to be few
  enough clients that I grouped it into two patches touching a number
  of files each; but I'm also okay with splitting into finer-grained
  patches that focus on fewer files at a time if that is desired.
  
  Eric Blake (2):
qobject: Use 'bool' for qbool
qobject: Use 'bool' inside qdict
 
 Applied to the qmp branch, thanks.

Unfortunately, I'm quite busy and won't have time to push this
through my tree. Markus is going to pick up this series soon.

Acked-by: Luiz Capitulino lcapitul...@redhat.com

 
  
   block/qapi.c|  2 +-
   block/quorum.c  |  4 ++--
   block/vvfat.c   |  4 ++--
   hmp.c   | 40 
  
   hw/pci/pcie_aer.c   |  4 ++--
   include/qapi/qmp/qbool.h|  8 
   include/qapi/qmp/qdict.h|  4 ++--
   monitor.c   | 12 ++--
   qapi/qmp-input-visitor.c|  2 +-
   qapi/qmp-output-visitor.c   |  2 +-
   qobject/json-parser.c   |  6 +++---
   qobject/qbool.c |  8 
   qobject/qdict.c |  8 
   qobject/qjson.c |  2 +-
   qom/object.c|  4 ++--
   tests/check-qjson.c | 11 ++-
   tests/test-qmp-event.c  |  4 ++--
   tests/test-qmp-output-visitor.c |  6 +++---
   util/qemu-option.c  |  2 +-
   19 files changed, 67 insertions(+), 66 deletions(-)
  
 

Re: [Qemu-devel] [RFC v6 0/2] monitor: add memory search commands s, sp

[Luiz Capitulino]

On Thu, 28 May 2015 16:18:41 -0400
Luiz Capitulino lcapitul...@redhat.com wrote:

 On Mon, 18 May 2015 13:22:16 +0200
 hw.clau...@gmail.com wrote:
 
  From: Claudio Fontana claudio.font...@huawei.com
  
  This is the latest iteration of the memory search patch,
  including a trivial replacement for the memmem function for systems
  which don't provide one (notably Windows).
  
  It detects the presence of memmem in configure and sets CONFIG_MEMMEM,
  providing a trivial implementation for the !CONFIG_MEMMEM case.
  
  The new code is MIT licensed, following usage of other files in the same
  directory dealing with replacement functions (osdep, oslib, getauxval etc),
  and to maximize reusability.
  
  I have tested this in both CONFIG_MEMMEM defined/undefined scenarios,
  but more feedback and testing is welcome of course.
  
  changes from v5:
  dropped the import from gnulib and implemented a trivial replacement.
  
  changes from v4:
  made into a series of two patches.
  Introduced a memmem replacement function (import from gnulib)
  and detection code in configure.
  
  changes from v3:
  initialize pointer variable to NULL to finally get rid of spurious warning
  
  changes from v2:
  move code to try to address spurious warning
  
  changes from v1:
  make checkpatch happy by adding braces here and there.
  
  
  Claudio Fontana (2):
util: add memmem replacement function
monitor: add memory search commands s, sp
 
 Applied to the qmp branch, thanks.


Unfortunately, I'm quite busy and won't have time to push this
through my tree. Markus is going to pick up this series soon.

Acked-by: Luiz Capitulino lcapitul...@redhat.com

 
  
   configure|  15 ++
   hmp-commands.hx  |  28 +++
   include/qemu/osdep.h |   4 ++
   monitor.c| 140 
  +++
   util/Makefile.objs   |   1 +
   util/memmem.c|  62 +++
   6 files changed, 250 insertions(+)
   create mode 100644 util/memmem.c
  
 

Re: [Qemu-devel] Ping: [PATCH] qobject: object_property_add() performance improvement

[Luiz Capitulino]

On Thu, 04 Jun 2015 10:35:17 +0300
Pavel Fedin p.fe...@samsung.com wrote:

  Hello Luiz! Have you missed this ?

Well, this is a QOM patch. QOM also has an object abstraction, but
it's not the same as QObject.

I'm CC'ing the maintainer.

 
 Kind regards,
 Pavel Fedin
 Expert Engineer
 Samsung Electronics Research center Russia
 
 
  -Original Message-
  From: qemu-devel-bounces+p.fedin=samsung@nongnu.org [mailto:qemu-devel-
  bounces+p.fedin=samsung@nongnu.org] On Behalf Of Pavel Fedin
  Sent: Thursday, May 28, 2015 11:42 AM
  To: qemu-devel@nongnu.org
  Cc: 'Luiz Capitulino'
  Subject: [Qemu-devel] [PATCH] qobject: object_property_add() performance 
  improvement
  
   The function originally behaves very badly when adding properties with 
  [*] suffix.
  Nomnally these are used for numbering IRQ pins. In order to find the 
  correct starting
  number the function started from zero and checked for duplicates. This took 
  incredibly
  long time with large number of CPUs because number of IRQ pins on some 
  architectures
 (like
  ARM GICv3) gets multiplied by number of CPUs.
   The solution is to add one more property which caches last used index so 
  that
 duplication
  check is not repeated thousands of times. Every time an array is expanded 
  the index is
  picked up from this cache. Cache property is a uint32_t and has the 
  original name of the
  array ('name[*]') for simplicity.
   Some more improvements:
  - Call object_property_add_single() instead of recursing into itself - 
  keeps off
 memcmp()
  check every time when its result is already known.
  - Allocate name_no_array only once and not every time for every property 
  (there can be
  thousands of them)
   The modification decreases qemu startup time with 32 ARMv8 CPUs by a 
  factor of 2 (~10
 sec
  vs ~20 sec).
  
  Signed-off-by: Pavel Fedin p.fe...@samsung.com
  ---
   qom/object.c | 89 
  ++--
   1 file changed, 62 insertions(+), 27 deletions(-)
  
  diff --git a/qom/object.c b/qom/object.c
  index b8dff43..72480bc 100644
  --- a/qom/object.c
  +++ b/qom/object.c
  @@ -10,6 +10,8 @@
* See the COPYING file in the top-level directory.
*/
  
  +#include glib/gprintf.h
  +
   #include qom/object.h
   #include qemu-common.h
   #include qapi/visitor.h
  @@ -721,35 +723,14 @@ void object_unref(Object *obj)
   }
   }
  
  -ObjectProperty *
  -object_property_add(Object *obj, const char *name, const char *type,
  -ObjectPropertyAccessor *get,
  -ObjectPropertyAccessor *set,
  -ObjectPropertyRelease *release,
  -void *opaque, Error **errp)
  +static ObjectProperty *
  +object_property_add_single(Object *obj, const char *name, const char *type,
  +   ObjectPropertyAccessor *get,
  +   ObjectPropertyAccessor *set,
  +   ObjectPropertyRelease *release,
  +   void *opaque, Error **errp)
   {
   ObjectProperty *prop;
  -size_t name_len = strlen(name);
  -
  -if (name_len = 3  !memcmp(name + name_len - 3, [*], 4)) {
  -int i;
  -ObjectProperty *ret;
  -char *name_no_array = g_strdup(name);
  -
  -name_no_array[name_len - 3] = '\0';
  -for (i = 0; ; ++i) {
  -char *full_name = g_strdup_printf(%s[%d], name_no_array, i);
  -
  -ret = object_property_add(obj, full_name, type, get, set,
  -  release, opaque, NULL);
  -g_free(full_name);
  -if (ret) {
  -break;
  -}
  -}
  -g_free(name_no_array);
  -return ret;
  -}
  
   QTAILQ_FOREACH(prop, obj-properties, node) {
   if (strcmp(prop-name, name) == 0) {
  @@ -774,6 +755,60 @@ object_property_add(Object *obj, const char *name, 
  const char
 *type,
   return prop;
   }
  
  +static void property_get_uint32_ptr(Object *obj, Visitor *v,
  +   void *opaque, const char *name,
  +   Error **errp);
  +
  +ObjectProperty *
  +object_property_add(Object *obj, const char *name, const char *type,
  +ObjectPropertyAccessor *get,
  +ObjectPropertyAccessor *set,
  +ObjectPropertyRelease *release,
  +void *opaque, Error **errp)
  +{
  +size_t name_len = strlen(name);
  +
  +if (name_len = 3  !memcmp(name + name_len - 3, [*], 4)) {
  +int i;
  +ObjectProperty *ret, *count;
  +/* 10 characters for maximum possible integer number */
  +char *name_no_array = g_malloc(name_len + 10);
  +
  +count = object_property_find(obj, name, NULL);
  +   if (count == NULL) {
  +   void *v = g_malloc0(sizeof(uint32_t));
  +
  +/* This is the same

Re: [Qemu-devel] [PATCH v2 0/2] monitor+disas: Remove uses of ENV_GET_CPU

[Luiz Capitulino]

On Tue, 2 Jun 2015 01:06:11 -0700
Peter Crosthwaite peter.crosthwa...@xilinx.com wrote:

 Ping!
 
 So there was some uncertainty around maintainerships earlier (on some
 follow up work to this one) and I wonder what the target queue is for
 this stuff.

It's the monitor queue, for which I'm the maintainer. But I won't have
to go over patches this week.

If Markus, or any other maintainer, wants to take this one and the other
patches I have queued through their trees, that would be more than
welcome.

Re: [Qemu-devel] [PATCH v3 11/21] monitor: Propagate errors through invalid_qmp_mode()

[Luiz Capitulino]

On Fri, 29 May 2015 11:56:50 +0200
Markus Armbruster arm...@redhat.com wrote:

 Signed-off-by: Markus Armbruster arm...@redhat.com
 ---
  monitor.c | 18 ++
  1 file changed, 10 insertions(+), 8 deletions(-)
 
 diff --git a/monitor.c b/monitor.c
 index 61ea346..d336b8f 100644
 --- a/monitor.c
 +++ b/monitor.c
 @@ -4708,19 +4708,20 @@ static int monitor_can_read(void *opaque)
  return (mon-suspend_cnt == 0) ? 1 : 0;
  }
  
 -static bool invalid_qmp_mode(const Monitor *mon, const mon_cmd_t *cmd)
 +static bool invalid_qmp_mode(const Monitor *mon, const mon_cmd_t *cmd,
 + Error **errp)
  {
  bool is_cap = cmd-mhandler.cmd_new == do_qmp_capabilities;
  if (is_cap  qmp_cmd_mode(mon)) {
 -qerror_report(ERROR_CLASS_COMMAND_NOT_FOUND,
 -  Capabilities negotiation is already complete, command 
 
 -  '%s' ignored, cmd-name);
 +error_set(errp, ERROR_CLASS_COMMAND_NOT_FOUND,
 +  Capabilities negotiation is already complete, command 
 +  '%s' ignored, cmd-name);
  return true;
  }
  if (!is_cap  !qmp_cmd_mode(mon)) {
 -qerror_report(ERROR_CLASS_COMMAND_NOT_FOUND,
 -  Expecting capabilities negotiation with 
 -  'qmp_capabilities' before command '%s', cmd-name);
 +error_set(errp, ERROR_CLASS_COMMAND_NOT_FOUND,
 +  Expecting capabilities negotiation with 
 +  'qmp_capabilities' before command '%s', cmd-name);
  return true;
  }
  return false;
 @@ -5010,7 +5011,8 @@ static void handle_qmp_command(JSONMessageParser 
 *parser, QList *tokens)
The command %s has not been found, cmd_name);
  goto err_out;
  }
 -if (invalid_qmp_mode(mon, cmd)) {
 +if (invalid_qmp_mode(mon, cmd, local_err)) {
 +qerror_report_err(local_err);

I don't think you need to call qerror_report_err() here, and you could
have changed invalid_qmp_mode() to return void. You can make those changes
before applying if you choose to do them:

Reviewed-by: Luiz Capitulino lcapitul...@redhat.com

  goto err_out;
  }
  

Re: [Qemu-devel] [PATCH v3 11/21] monitor: Propagate errors through invalid_qmp_mode()

[Luiz Capitulino]

On Fri, 29 May 2015 16:19:28 +0200
Markus Armbruster arm...@redhat.com wrote:

 Luiz Capitulino lcapitul...@redhat.com writes:
 
  On Fri, 29 May 2015 11:56:50 +0200
  Markus Armbruster arm...@redhat.com wrote:
 
  Signed-off-by: Markus Armbruster arm...@redhat.com
  ---
   monitor.c | 18 ++
   1 file changed, 10 insertions(+), 8 deletions(-)
  
  diff --git a/monitor.c b/monitor.c
  index 61ea346..d336b8f 100644
  --- a/monitor.c
  +++ b/monitor.c
  @@ -4708,19 +4708,20 @@ static int monitor_can_read(void *opaque)
   return (mon-suspend_cnt == 0) ? 1 : 0;
   }
   
  -static bool invalid_qmp_mode(const Monitor *mon, const mon_cmd_t *cmd)
  +static bool invalid_qmp_mode(const Monitor *mon, const mon_cmd_t *cmd,
  + Error **errp)
   {
   bool is_cap = cmd-mhandler.cmd_new == do_qmp_capabilities;
   if (is_cap  qmp_cmd_mode(mon)) {
  -qerror_report(ERROR_CLASS_COMMAND_NOT_FOUND,
  -  Capabilities negotiation is already complete, 
  command 
  -  '%s' ignored, cmd-name);
  +error_set(errp, ERROR_CLASS_COMMAND_NOT_FOUND,
  +  Capabilities negotiation is already complete, command 
  +  '%s' ignored, cmd-name);
   return true;
   }
   if (!is_cap  !qmp_cmd_mode(mon)) {
  -qerror_report(ERROR_CLASS_COMMAND_NOT_FOUND,
  -  Expecting capabilities negotiation with 
  -  'qmp_capabilities' before command '%s', 
  cmd-name);
  +error_set(errp, ERROR_CLASS_COMMAND_NOT_FOUND,
  +  Expecting capabilities negotiation with 
  +  'qmp_capabilities' before command '%s', cmd-name);
   return true;
   }
   return false;
  @@ -5010,7 +5011,8 @@ static void handle_qmp_command(JSONMessageParser 
  *parser, QList *tokens)
 The command %s has not been found, cmd_name);
   goto err_out;
   }
  -if (invalid_qmp_mode(mon, cmd)) {
  +if (invalid_qmp_mode(mon, cmd, local_err)) {
  +qerror_report_err(local_err);
 
  I don't think you need to call qerror_report_err() here, and you could
  have changed invalid_qmp_mode() to return void. You can make those changes
  before applying if you choose to do them:
 
 Actually, I have to call it here, because after this patch, we still
 have monitor_protocol_emitter() getting the error from mon-error, so we
 still have to put it there.

You're right!

 However, I forgot to drop it along with the other calls in PATCH 14!

You don't have to respin because of that, feel free to fix it when
applying.

 
  Reviewed-by: Luiz Capitulino lcapitul...@redhat.com
 
 Thanks!
 
   goto err_out;
   }
   
 

Re: [Qemu-devel] [PATCH v3 14/21] monitor: Limit QError use to command handlers

[Luiz Capitulino]

On Fri, 29 May 2015 16:23:55 +0200
Markus Armbruster arm...@redhat.com wrote:

 The following hunk needs to be squashed in:
 
 diff --git a/monitor.c b/monitor.c
 index 16bd567..888d771 100644
 --- a/monitor.c
 +++ b/monitor.c
 @@ -5005,7 +5005,6 @@ static void handle_qmp_command(JSONMessageParser 
 *parser, QList *tokens)
  goto err_out;
  }
  if (invalid_qmp_mode(mon, cmd, local_err)) {
 -qerror_report_err(local_err);
  goto err_out;
  }

Reviewed-by: Luiz Capitulino lcapitul...@redhat.com

  
 

Re: [Qemu-devel] [PATCH 0/2] Use bool for QBool

[Luiz Capitulino]

On Fri, 15 May 2015 16:24:58 -0600
Eric Blake ebl...@redhat.com wrote:

 Passing around an 'int' for a QBool type is weird, when we already
 use a C99 compiler and have a sane 'bool' that does just fine.
 
 I half-debated sending this through qemu-trivial, but think it
 better belongs through the QMP tree.  There turned out to be few
 enough clients that I grouped it into two patches touching a number
 of files each; but I'm also okay with splitting into finer-grained
 patches that focus on fewer files at a time if that is desired.
 
 Eric Blake (2):
   qobject: Use 'bool' for qbool
   qobject: Use 'bool' inside qdict

Applied to the qmp branch, thanks.

 
  block/qapi.c|  2 +-
  block/quorum.c  |  4 ++--
  block/vvfat.c   |  4 ++--
  hmp.c   | 40 
  hw/pci/pcie_aer.c   |  4 ++--
  include/qapi/qmp/qbool.h|  8 
  include/qapi/qmp/qdict.h|  4 ++--
  monitor.c   | 12 ++--
  qapi/qmp-input-visitor.c|  2 +-
  qapi/qmp-output-visitor.c   |  2 +-
  qobject/json-parser.c   |  6 +++---
  qobject/qbool.c |  8 
  qobject/qdict.c |  8 
  qobject/qjson.c |  2 +-
  qom/object.c|  4 ++--
  tests/check-qjson.c | 11 ++-
  tests/test-qmp-event.c  |  4 ++--
  tests/test-qmp-output-visitor.c |  6 +++---
  util/qemu-option.c  |  2 +-
  19 files changed, 67 insertions(+), 66 deletions(-)
 

Re: [Qemu-devel] [RFC v6 0/2] monitor: add memory search commands s, sp

[Luiz Capitulino]

On Mon, 18 May 2015 13:22:16 +0200
hw.clau...@gmail.com wrote:

 From: Claudio Fontana claudio.font...@huawei.com
 
 This is the latest iteration of the memory search patch,
 including a trivial replacement for the memmem function for systems
 which don't provide one (notably Windows).
 
 It detects the presence of memmem in configure and sets CONFIG_MEMMEM,
 providing a trivial implementation for the !CONFIG_MEMMEM case.
 
 The new code is MIT licensed, following usage of other files in the same
 directory dealing with replacement functions (osdep, oslib, getauxval etc),
 and to maximize reusability.
 
 I have tested this in both CONFIG_MEMMEM defined/undefined scenarios,
 but more feedback and testing is welcome of course.
 
 changes from v5:
 dropped the import from gnulib and implemented a trivial replacement.
 
 changes from v4:
 made into a series of two patches.
 Introduced a memmem replacement function (import from gnulib)
 and detection code in configure.
 
 changes from v3:
 initialize pointer variable to NULL to finally get rid of spurious warning
 
 changes from v2:
 move code to try to address spurious warning
 
 changes from v1:
 make checkpatch happy by adding braces here and there.
 
 
 Claudio Fontana (2):
   util: add memmem replacement function
   monitor: add memory search commands s, sp

Applied to the qmp branch, thanks.

 
  configure|  15 ++
  hmp-commands.hx  |  28 +++
  include/qemu/osdep.h |   4 ++
  monitor.c| 140 
 +++
  util/Makefile.objs   |   1 +
  util/memmem.c|  62 +++
  6 files changed, 250 insertions(+)
  create mode 100644 util/memmem.c
 

Re: [Qemu-devel] [PATCH v2 09/20] monitor: Propagate errors through qmp_check_client_args()

[Luiz Capitulino]

On Tue, 26 May 2015 17:20:44 +0200
Markus Armbruster arm...@redhat.com wrote:

 Signed-off-by: Markus Armbruster arm...@redhat.com
 Reviewed-by: Eric Blake ebl...@redhat.com
 ---
  monitor.c | 65 
 ---
  1 file changed, 33 insertions(+), 32 deletions(-)
 
 diff --git a/monitor.c b/monitor.c
 index 9403c2c..0afcf60 100644
 --- a/monitor.c
 +++ b/monitor.c
 @@ -4736,8 +4736,9 @@ static bool invalid_qmp_mode(const Monitor *mon, const 
 mon_cmd_t *cmd)
   *   the QMP_ACCEPT_UNKNOWNS flag is set, then the
   *   checking is skipped for it.
   */
 -static int check_client_args_type(const QDict *client_args,
 -  const QDict *cmd_args, int flags)
 +static void check_client_args_type(const QDict *client_args,
 +   const QDict *cmd_args, int flags,
 +   Error **errp)
  {
  const QDictEntry *ent;
  
 @@ -4754,8 +4755,8 @@ static int check_client_args_type(const QDict 
 *client_args,
  continue;
  }
  /* client arg doesn't exist */
 -qerror_report(QERR_INVALID_PARAMETER, client_arg_name);
 -return -1;
 +error_set(errp, QERR_INVALID_PARAMETER, client_arg_name);
 +return;
  }
  
  arg_type = qobject_to_qstring(obj);
 @@ -4767,9 +4768,9 @@ static int check_client_args_type(const QDict 
 *client_args,
  case 'B':
  case 's':
  if (qobject_type(client_arg) != QTYPE_QSTRING) {
 -qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
 -  string);
 -return -1;
 +error_set(errp, QERR_INVALID_PARAMETER_TYPE,
 +  client_arg_name, string);
 +return;
  }
  break;
  case 'i':
 @@ -4777,25 +4778,25 @@ static int check_client_args_type(const QDict 
 *client_args,
  case 'M':
  case 'o':
  if (qobject_type(client_arg) != QTYPE_QINT) {
 -qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
 -  int);
 -return -1; 
 +error_set(errp, QERR_INVALID_PARAMETER_TYPE,
 +  client_arg_name, int);
 +return;
  }
  break;
  case 'T':
  if (qobject_type(client_arg) != QTYPE_QINT 
  qobject_type(client_arg) != QTYPE_QFLOAT) {
 -qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
 -  number);
 -   return -1; 
 +error_set(errp, QERR_INVALID_PARAMETER_TYPE,
 +  client_arg_name, number);
 +return;
  }
  break;
  case 'b':
  case '-':
  if (qobject_type(client_arg) != QTYPE_QBOOL) {
 -qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
 -  bool);
 -   return -1; 
 +error_set(errp, QERR_INVALID_PARAMETER_TYPE,
 +  client_arg_name, bool);
 +return;
  }
  break;
  case 'O':
 @@ -4814,16 +4815,15 @@ static int check_client_args_type(const QDict 
 *client_args,
  abort();
  }
  }
 -
 -return 0;
  }
  
  /*
   * - Check if the client has passed all mandatory args
   * - Set special flags for argument validation
   */
 -static int check_mandatory_args(const QDict *cmd_args,
 -const QDict *client_args, int *flags)
 +static void check_mandatory_args(const QDict *cmd_args,
 + const QDict *client_args, int *flags,
 + Error **errp)
  {
  const QDictEntry *ent;
  
 @@ -4838,12 +4838,10 @@ static int check_mandatory_args(const QDict *cmd_args,
  } else if (qstring_get_str(type)[0] != '-' 
 qstring_get_str(type)[1] != '?' 
 !qdict_haskey(client_args, cmd_arg_name)) {
 -qerror_report(QERR_MISSING_PARAMETER, cmd_arg_name);
 -return -1;
 +error_set(errp, QERR_MISSING_PARAMETER, cmd_arg_name);
 +return;
  }
  }
 -
 -return 0;

I'd go from qerror_report() to error_setg(), but it's fine if you're
saving this for a different series. I won't make this comment on the
next patches, as this seems to be your intention.

  }
  
  static QDict *qdict_from_args_type(const char *args_type)
 @@ -4899,24 +4897,26 @@ out:
   * 3. Each argument provided by the client must have the type expected
   *by the command
   */
 -static int qmp_check_client_args(const mon_cmd_t *cmd, QDict *client_args)
 +static void qmp_check_client_args(const mon_cmd_t *cmd, QDict 

Re: [Qemu-devel] [PATCH v2 04/20] monitor: Convert client_migrate_info to QAPI

[Luiz Capitulino]

On Tue, 26 May 2015 17:20:39 +0200
Markus Armbruster arm...@redhat.com wrote:

 Signed-off-by: Markus Armbruster arm...@redhat.com
 Reviewed-by: Eric Blake ebl...@redhat.com
 ---
  hmp-commands.hx  |  3 +--
  hmp.c| 17 +
  hmp.h|  1 +
  monitor.c| 42 ++
  qapi-schema.json | 19 +++
  qmp-commands.hx  |  2 +-
  6 files changed, 57 insertions(+), 27 deletions(-)
 
 diff --git a/hmp-commands.hx b/hmp-commands.hx
 index 0cf592b..af2de61 100644
 --- a/hmp-commands.hx
 +++ b/hmp-commands.hx
 @@ -1012,8 +1012,7 @@ ETEXI
  .args_type  = 
 protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?,
  .params = protocol hostname port tls-port cert-subject,
  .help   = set migration information for remote display,
 -.user_print = monitor_user_noop,
 -.mhandler.cmd_new = client_migrate_info,
 +.mhandler.cmd = hmp_client_migrate_info,
  },
  
  STEXI
 diff --git a/hmp.c b/hmp.c
 index e17852d..5a43f9d 100644
 --- a/hmp.c
 +++ b/hmp.c
 @@ -1250,6 +1250,23 @@ void hmp_migrate_set_parameter(Monitor *mon, const 
 QDict *qdict)
  }
  }
  
 +void hmp_client_migrate_info(Monitor *mon, const QDict *qdict)
 +{
 +Error *err = NULL;
 +const char *protocol = qdict_get_str(qdict, protocol);
 +const char *hostname = qdict_get_str(qdict, hostname);
 +bool has_port= qdict_haskey(qdict, port);
 +int port = qdict_get_try_int(qdict, port, -1);
 +bool has_tls_port= qdict_haskey(qdict, tls-port);
 +int tls_port = qdict_get_try_int(qdict, tls-port, -1);
 +const char *cert_subject = qdict_get_try_str(qdict, cert-subject);
 +
 +qmp_client_migrate_info(protocol, hostname,
 +has_port, port, has_tls_port, tls_port,
 +!!cert_subject, cert_subject, err);
 +hmp_handle_error(mon, err);
 +}
 +
  void hmp_set_password(Monitor *mon, const QDict *qdict)
  {
  const char *protocol  = qdict_get_str(qdict, protocol);
 diff --git a/hmp.h b/hmp.h
 index a158e3f..b81439c 100644
 --- a/hmp.h
 +++ b/hmp.h
 @@ -67,6 +67,7 @@ void hmp_migrate_set_speed(Monitor *mon, const QDict 
 *qdict);
  void hmp_migrate_set_capability(Monitor *mon, const QDict *qdict);
  void hmp_migrate_set_parameter(Monitor *mon, const QDict *qdict);
  void hmp_migrate_set_cache_size(Monitor *mon, const QDict *qdict);
 +void hmp_client_migrate_info(Monitor *mon, const QDict *qdict);
  void hmp_set_password(Monitor *mon, const QDict *qdict);
  void hmp_expire_password(Monitor *mon, const QDict *qdict);
  void hmp_eject(Monitor *mon, const QDict *qdict);
 diff --git a/monitor.c b/monitor.c
 index 8170309..38ff972 100644
 --- a/monitor.c
 +++ b/monitor.c
 @@ -1032,39 +1032,33 @@ static void hmp_info_trace_events(Monitor *mon, const 
 QDict *qdict)
  qapi_free_TraceEventInfoList(events);
  }
  
 -static int client_migrate_info(Monitor *mon, const QDict *qdict,
 -   QObject **ret_data)
 +void qmp_client_migrate_info(const char *protocol, const char *hostname,
 + bool has_port, int64_t port,
 + bool has_tls_port, int64_t tls_port,
 + bool has_cert_subject, const char *cert_subject,
 + Error **errp)
  {
 -const char *protocol = qdict_get_str(qdict, protocol);
 -const char *hostname = qdict_get_str(qdict, hostname);
 -const char *subject  = qdict_get_try_str(qdict, cert-subject);
 -int port = qdict_get_try_int(qdict, port, -1);
 -int tls_port = qdict_get_try_int(qdict, tls-port, -1);
 -Error *err = NULL;
 -int ret;
 -
  if (strcmp(protocol, spice) == 0) {
 -if (!qemu_using_spice(err)) {
 -qerror_report_err(err);
 -error_free(err);
 -return -1;
 +if (!qemu_using_spice(errp)) {
 +return;
  }
  
 -if (port == -1  tls_port == -1) {
 -qerror_report(QERR_MISSING_PARAMETER, port/tls-port);
 -return -1;
 +if (!has_port  !has_tls_port) {
 +error_set(errp, QERR_MISSING_PARAMETER, port/tls-port);
 +return;
  }
  
 -ret = qemu_spice_migrate_info(hostname, port, tls_port, subject);
 -if (ret != 0) {
 -qerror_report(QERR_UNDEFINED_ERROR);
 -return -1;
 +if (qemu_spice_migrate_info(hostname,
 +has_port ? port : -1,
 +has_tls_port ? tls_port : -1,
 +cert_subject)) {
 +error_set(errp, QERR_UNDEFINED_ERROR);
 +return;
  }
 -return 0;
 +return;
  }
  
 -qerror_report(QERR_INVALID_PARAMETER_VALUE, protocol, spice);
 -return -1;
 +error_set(errp, QERR_INVALID_PARAMETER_VALUE, 

Re: [Qemu-devel] [PATCH v2 00/20] monitor: Wean core off QError, and other cleanups

[Luiz Capitulino]

On Tue, 26 May 2015 17:20:35 +0200
Markus Armbruster arm...@redhat.com wrote:

 Command handlers still use QError.  Left for another day.

Great work! I've found one bug that has to be addressed before merging.
Also, for the error conversions you're doing you're going from
qerror_report() to error_set() but I'd recommend going directly to
error_setg() as that's our final goal. It's totally fine with me
if you're saving this work for a later series, but I think it will
you save work if you do it in this series. Your call.

Can you take this through your tree? Feel free to add this once
you fix the bug:

Reviewed-by: Luiz Capitulino lcapitul...@redhat.com

 
 v2:
 * Trivially rebased
 * PATCH 01: Drop another async remnant [Eric]
 * PATCH 01+02+18: Improve commit messages
 * PATCH 03+04: client_migrate_info still hasn't been implemented VNC,
   de-document [Eric, Gerd]
 * PATCH 16+19: Don't inline monitor_ctrl_mode() into monitor_init() [Eric]
 * PATCH 20: Use false instead of 0 [Eric]
 
 Markus Armbruster (20):
   monitor: Drop broken, unused asynchronous command interface
   monitor: Clean up after previous commit
   monitor: Improve and document client_migrate_info protocol error
   monitor: Convert client_migrate_info to QAPI
   monitor: Use traditional command interface for HMP drive_del
   monitor: Use traditional command interface for HMP device_add
   monitor: Use trad. command interface for HMP pcie_aer_inject_error
   monitor: Drop unused new HMP command interface
   monitor: Propagate errors through qmp_check_client_args()
   monitor: Propagate errors through qmp_check_input_obj()
   monitor: Wean monitor_protocol_emitter() off mon-error
   monitor: Inline monitor_has_error() into its only caller
   monitor: Limit QError use to command handlers
   monitor: Rename handle_user_command() to handle_hmp_command()
   monitor: Rename monitor_control_read(), monitor_control_event()
   monitor: Unbox Monitor member mc and rename to qmp
   monitor: Drop do_qmp_capabilities()'s superfluous QMP check
   monitor: Turn int command_mode into bool in_command_mode
   monitor: Rename monitor_ctrl_mode() to monitor_is_qmp()
   monitor: Change return type of monitor_cur_is_qmp() to bool
 
  blockdev.c|   9 +-
  hmp-commands.hx   |  20 +--
  hmp.c |  23 +++
  hmp.h |   2 +
  hw/pci/pci-stub.c |  14 +-
  hw/pci/pcie_aer.c |  39 ++---
  include/monitor/monitor.h |   7 +-
  include/sysemu/blockdev.h |   2 +-
  include/sysemu/sysemu.h   |   4 +-
  monitor.c | 380 
 --
  qapi-schema.json  |  19 +++
  qmp-commands.hx   |  16 +-
  stubs/mon-is-qmp.c|   4 +-
  13 files changed, 222 insertions(+), 317 deletions(-)
 

Re: [Qemu-devel] [PATCH v2 13/20] monitor: Limit QError use to command handlers

[Luiz Capitulino]

On Tue, 26 May 2015 17:20:48 +0200
Markus Armbruster arm...@redhat.com wrote:

 The previous commits narrowed use of QError to handle_qmp_command()
 and its helpers monitor_protocol_emitter(), build_qmp_error_dict().
 Narrow it further to just the command handler call: instead of
 converting Error to QError throughout handle_qmp_command(), convert
 the QError gotten from the command handler to Error, and switch the
 helpers from QError to Error.
 
 Signed-off-by: Markus Armbruster arm...@redhat.com
 Reviewed-by: Eric Blake ebl...@redhat.com
 ---
  monitor.c | 26 ++
  1 file changed, 14 insertions(+), 12 deletions(-)
 
 diff --git a/monitor.c b/monitor.c
 index f7e8fdf..1ed8462 100644
 --- a/monitor.c
 +++ b/monitor.c
 @@ -391,19 +391,19 @@ static void monitor_json_emitter(Monitor *mon, const 
 QObject *data)
  QDECREF(json);
  }
  
 -static QDict *build_qmp_error_dict(const QError *err)
 +static QDict *build_qmp_error_dict(Error *err)
  {
  QObject *obj;
  
 -obj = qobject_from_jsonf({ 'error': { 'class': %s, 'desc': %p } },
 - ErrorClass_lookup[err-err_class],
 - qerror_human(err));
 +obj = qobject_from_jsonf({ 'error': { 'class': %s, 'desc': %s } },
 + ErrorClass_lookup[error_get_class(err)],
 + error_get_pretty(err));
  
  return qobject_to_qdict(obj);
  }
  
  static void monitor_protocol_emitter(Monitor *mon, QObject *data,
 - QError *err)
 + Error *err)
  {
  QDict *qmp;
  
 @@ -4982,13 +4982,12 @@ static void handle_qmp_command(JSONMessageParser 
 *parser, QList *tokens)
  obj = json_parser_parse(tokens, NULL);
  if (!obj) {
  // FIXME: should be triggered in json_parser_parse()
 -qerror_report(QERR_JSON_PARSING);
 +error_set(local_err, QERR_JSON_PARSING);
  goto err_out;
  }
  
  input = qmp_check_input_obj(obj, local_err);
  if (!input) {
 -qerror_report_err(local_err);
  qobject_decref(obj);
  goto err_out;
  }
 @@ -5000,8 +4999,8 @@ static void handle_qmp_command(JSONMessageParser 
 *parser, QList *tokens)
  trace_handle_qmp_command(mon, cmd_name);
  cmd = qmp_find_cmd(cmd_name);
  if (!cmd) {
 -qerror_report(ERROR_CLASS_COMMAND_NOT_FOUND,
 -  The command %s has not been found, cmd_name);
 +error_set(local_err, ERROR_CLASS_COMMAND_NOT_FOUND,
 +  The command %s has not been found, cmd_name);
  goto err_out;
  }
  if (invalid_qmp_mode(mon, cmd)) {
 @@ -5018,7 +5017,6 @@ static void handle_qmp_command(JSONMessageParser 
 *parser, QList *tokens)
  
  qmp_check_client_args(cmd, args, local_err);
  if (local_err) {
 -qerror_report_err(local_err);
  goto err_out;
  }
  
 @@ -5026,12 +5024,16 @@ static void handle_qmp_command(JSONMessageParser 
 *parser, QList *tokens)
  /* Command failed... */
  if (!mon-error) {
  /* ... without setting an error, so make one up */
 -qerror_report(QERR_UNDEFINED_ERROR);
 +error_set(local_err, QERR_UNDEFINED_ERROR);
  }
  }
 +if (mon-error) {
 +error_set(local_err, mon-error-err_class, %s,
 +  mon-error-err_msg);
 +}
  
  err_out:
 -monitor_protocol_emitter(mon, data, mon-error);
 +monitor_protocol_emitter(mon, data, local_err);

This breaks error reporting from invalid_qmp_mode(). The end result
is that every command succeeds in capability negotiation mode and
qmp_capabilities never fails (even in command mode).

There are two simple ways to fix it: just propagate mon-error to
local_err when invalid_qmp_mode() fails, or change invalid_qmp_mode()
to take an Error object (preferable).

  qobject_decref(data);
  QDECREF(mon-error);
  mon-error = NULL;

Re: [Qemu-devel] [RFC v4] monitor: add memory search commands s, sp

[Luiz Capitulino]

On Fri, 24 Apr 2015 14:39:48 +0200
hw.clau...@gmail.com wrote:

 From: Claudio Fontana claudio.font...@huawei.com
 
 usage is similar to the commands x, xp.
 
 Example with string: looking for ELF header in memory:
 
 (qemu) s/100cb 0x40001000 ELF
 searching memory area [40001000-400f5240]
 40090001
 (qemu) x/20b 0x4009
 4009: '\x7f' 'E' 'L' 'F' '\x02' '\x01' '\x01' '\x03'
 40090008: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00'
 40090010: '\x02' '\x00' '\xb7' '\x00'
 
 Example with value: looking for 64bit variable value 0x990088
 
 (qemu) s/100xg 0x90004200 0x990088
 searching memory area [90004200-9000427a1200]
 9000424b3000
 9000424c1000
 
 Signed-off-by: Claudio Fontana claudio.font...@huawei.com

I had to drop this patch because it doesn't build for w32. You can
find instructions on how to build for w32 at:

 http://wiki.qemu.org/Hosts/W32

 ---
  hmp-commands.hx |  28 
  monitor.c   | 140 
 
  2 files changed, 168 insertions(+)
 
 changes from v3:
 initialize pointer variable to NULL to finally get rid of spurious warning
 
 changes from v2:
 move code to try to address spurious warning
 
 changes from v1:
 make checkpatch happy by adding braces here and there.
 
 diff --git a/hmp-commands.hx b/hmp-commands.hx
 index d5022d8..2bf5737 100644
 --- a/hmp-commands.hx
 +++ b/hmp-commands.hx
 @@ -432,6 +432,34 @@ Start gdbserver session (default @var{port}=1234)
  ETEXI
  
  {
 +.name   = s,
 +.args_type  = fmt:/,addr:l,data:s,
 +.params = /fmt addr data,
 +.help   = search virtual memory starting at 'addr' for 'data',
 +.mhandler.cmd = hmp_memory_search,
 +},
 +
 +STEXI
 +@item s/fmt @var{addr} @var{data}
 +@findex s
 +Virtual memory search starting at @var{addr} for data described by 
 @var{data}.
 +ETEXI
 +
 +{
 +.name   = sp,
 +.args_type  = fmt:/,addr:l,data:s,
 +.params = /fmt addr data,
 +.help   = search physical memory starting at 'addr' for 'data',
 +.mhandler.cmd = hmp_physical_memory_search,
 +},
 +
 +STEXI
 +@item sp/fmt @var{addr} @var{data}
 +@findex sp
 +Physical memory search starting at @var{addr} for data described by 
 @var{data}.
 +ETEXI
 +
 +{
  .name   = x,
  .args_type  = fmt:/,addr:l,
  .params = /fmt addr,
 diff --git a/monitor.c b/monitor.c
 index c86a89e..b648dd2 100644
 --- a/monitor.c
 +++ b/monitor.c
 @@ -1208,6 +1208,124 @@ static void monitor_printc(Monitor *mon, int c)
  monitor_printf(mon, ');
  }
  
 +static void monitor_print_addr(Monitor *mon, hwaddr addr, bool is_physical)
 +{
 +if (is_physical) {
 +monitor_printf(mon, TARGET_FMT_plx \n, addr);
 +} else {
 +monitor_printf(mon, TARGET_FMT_lx \n, (target_ulong)addr);
 +}
 +}
 +
 +/* simple memory search for a byte sequence. The sequence is generated from
 + * a numeric value to look for in guest memory, or from a string.
 + */
 +static void memory_search(Monitor *mon, int count, int format, int wsize,
 +  hwaddr addr, const char *data_str, bool 
 is_physical)
 +{
 +int pos, len;  /* pos in the search area, len of area */
 +char *hay; /* buffer for haystack */
 +int hay_size;  /* haystack size. Needle size is wsize. */
 +const char *needle = NULL; /* needle to search in the haystack */
 +const char *format_str;/* numeric input format string */
 +char value_raw[8]; /* numeric input converted to raw data */
 +#define MONITOR_S_CHUNK_SIZE 16000
 +
 +len = wsize * count;
 +if (len  1) {
 +monitor_printf(mon, invalid search area length.\n);
 +return;
 +}
 +switch (format) {
 +case 'i':
 +monitor_printf(mon, format '%c' not supported.\n, format);
 +return;
 +case 'c':
 +needle = data_str;
 +wsize = strlen(data_str);
 +if (wsize  MONITOR_S_CHUNK_SIZE) {
 +monitor_printf(mon, search string too long [max %d].\n,
 +   MONITOR_S_CHUNK_SIZE);
 +return;
 +}
 +break;
 +case 'o':
 +format_str = % SCNo64;
 +break;
 +default:
 +case 'x':
 +format_str = % SCNx64;
 +break;
 +case 'u':
 +format_str = % SCNu64;
 +break;
 +case 'd':
 +format_str = % SCNd64;
 +break;
 +}
 +if (format != 'c') {
 +uint64_t value;  /* numeric input value */
 +void *from = value;
 +if (sscanf(data_str, format_str, value) != 1) {
 +monitor_printf(mon, could not parse search string 
 +   \%s\ as format '%c'.\n, data_str, format);
 +return;
 +}
 +#if defined(HOST_WORDS_BIGENDIAN) != 

Re: [Qemu-devel] [PULL 00/10] QMP queue

[Luiz Capitulino]

On Mon, 11 May 2015 13:53:47 +0100
Peter Maydell peter.mayd...@linaro.org wrote:

 On 8 May 2015 at 14:34, Luiz Capitulino lcapitul...@redhat.com wrote:
  The following changes since commit f8340b360b9bc29d48716ba8aca79df2b9544979:
 
hw/ptimer: Do not artificially limit timers when using icount (2015-05-08 
  17:15:23 +1000)
 
  are available in the git repository at:
 
git://repo.or.cz/qemu/qmp-unstable.git tags/for-upstream
 
  for you to fetch changes up to 07972d16e3343dc62302b81efb018308f99f7a7a:
 
scripts: qmp-shell: Add verbose flag (2015-05-08 08:47:01 -0400)
 
  
  QMP pull request
 
 Hi. I'm afraid this doesn't build on win32:
 /home/petmay01/linaro/qemu-for-merges/monitor.c: In function ‘memory_search’:
 /home/petmay01/linaro/qemu-for-merges/monitor.c:1306: warning:
 implicit declaration of function ‘memmem’
 /home/petmay01/linaro/qemu-for-merges/monitor.c:1306: warning: nested
 extern declaration of ‘memmem’
 /home/petmay01/linaro/qemu-for-merges/monitor.c:1306: warning:
 assignment makes pointer from integer

Needless to say that I didn't build for win32. My bad.

Can you try again? I've dropped the offending patch and pushed
the tag again.

[Qemu-devel] [PULL 10/10] scripts: qmp-shell: Add verbose flag

[Luiz Capitulino]

From: John Snow js...@redhat.com

Add a verbose flag that shows the QMP command that was
constructed, to allow for later copy/pasting, reference,
debugging, etc.

The QMP is converted from a Python literal to JSON first,
to ensure that it is viable input to the actual QMP parser.

As a side-effect, this JSON output will helpfully show all
the necessary conversions that were performed on the input,
illustrating that True was transformed back into true,
literal values are now escaped with  instead of '', and so on.

Signed-off-by: John Snow js...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Tested-by: Kashyap Chamarthy kcham...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 scripts/qmp/qmp-shell | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell
index 1df2ca7..65280d2 100755
--- a/scripts/qmp/qmp-shell
+++ b/scripts/qmp/qmp-shell
@@ -195,6 +195,13 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 self.__cli_expr(cmdargs[1:], qmpcmd['arguments'])
 return qmpcmd
 
+def _print(self, qmp):
+jsobj = json.dumps(qmp)
+if self._pp is not None:
+self._pp.pprint(jsobj)
+else:
+print str(jsobj)
+
 def _execute_cmd(self, cmdline):
 try:
 qmpcmd = self.__build_cmd(cmdline)
@@ -206,15 +213,13 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 # For transaction mode, we may have just cached the action:
 if qmpcmd is None:
 return True
+if self._verbose:
+self._print(qmpcmd)
 resp = self.cmd_obj(qmpcmd)
 if resp is None:
 print 'Disconnected'
 return False
-
-if self._pp is not None:
-self._pp.pprint(resp)
-else:
-print resp
+self._print(resp)
 return True
 
 def connect(self):
@@ -250,6 +255,9 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 else:
 return self._execute_cmd(cmdline)
 
+def set_verbosity(self, verbose):
+self._verbose = verbose
+
 class HMPShell(QMPShell):
 def __init__(self, address):
 QMPShell.__init__(self, address)
@@ -327,7 +335,7 @@ def die(msg):
 def fail_cmdline(option=None):
 if option:
 sys.stderr.write('ERROR: bad command-line option \'%s\'\n' % option)
-sys.stderr.write('qemu-shell [ -p ] [ -H ]  UNIX socket path |  TCP 
address:port \n')
+sys.stderr.write('qemu-shell [ -v ] [ -p ] [ -H ]  UNIX socket path |  
TCP address:port \n')
 sys.exit(1)
 
 def main():
@@ -335,6 +343,7 @@ def main():
 qemu = None
 hmp = False
 pp = None
+verbose = False
 
 try:
 for arg in sys.argv[1:]:
@@ -346,6 +355,8 @@ def main():
 if pp is not None:
 fail_cmdline(arg)
 pp = pprint.PrettyPrinter(indent=4)
+elif arg == -v:
+verbose = True
 else:
 if qemu is not None:
 fail_cmdline(arg)
@@ -370,6 +381,7 @@ def main():
 die('Could not connect to %s' % addr)
 
 qemu.show_banner()
+qemu.set_verbosity(verbose)
 while qemu.read_exec_command(qemu.get_prompt()):
 pass
 qemu.close()
-- 
1.9.3

[Qemu-devel] [PULL 09/10] scripts: qmp-shell: add transaction subshell

[Luiz Capitulino]

From: John Snow js...@redhat.com

Add a special processing mode to craft transactions.

By entering transaction( the shell will enter a special
mode where each subsequent command will be saved as a transaction
instead of executed as an individual command.

The transaction can be submitted by entering ) on a line by itself.

Examples:

Separate lines:

(QEMU) transaction(
TRANS block-dirty-bitmap-add node=drive0 name=bitmap1
TRANS block-dirty-bitmap-clear node=drive0 name=bitmap0
TRANS )

With a transaction action included on the first line:

(QEMU) transaction( block-dirty-bitmap-add node=drive0 name=bitmap2
TRANS block-dirty-bitmap-add node=drive0 name=bitmap3
TRANS )

As a one-liner, with just one transaction action:

(QEMU) transaction( block-dirty-bitmap-add node=drive0 name=bitmap0 )

As a side-effect of this patch, blank lines are now parsed as no-ops,
regardless of which shell mode you are in.

Signed-off-by: John Snow js...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Tested-by: Kashyap Chamarthy kcham...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 scripts/qmp/qmp-shell | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell
index 7f2c554..1df2ca7 100755
--- a/scripts/qmp/qmp-shell
+++ b/scripts/qmp/qmp-shell
@@ -73,6 +73,8 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 self._greeting = None
 self._completer = None
 self._pp = pp
+self._transmode = False
+self._actions = list()
 
 def __get_address(self, arg):
 
@@ -159,6 +161,36 @@ class QMPShell(qmp.QEMUMonitorProtocol):
  command-name  [ arg-name1=arg1 ] ... [ arg-nameN=argN ]
 
 cmdargs = cmdline.split()
+
+# Transactional CLI entry/exit:
+if cmdargs[0] == 'transaction(':
+self._transmode = True
+cmdargs.pop(0)
+elif cmdargs[0] == ')' and self._transmode:
+self._transmode = False
+if len(cmdargs)  1:
+raise QMPShellError(Unexpected input after close of 
Transaction sub-shell)
+qmpcmd = { 'execute': 'transaction',
+   'arguments': { 'actions': self._actions } }
+self._actions = list()
+return qmpcmd
+
+# Nothing to process?
+if not cmdargs:
+return None
+
+# Parse and then cache this Transactional Action
+if self._transmode:
+finalize = False
+action = { 'type': cmdargs[0], 'data': {} }
+if cmdargs[-1] == ')':
+cmdargs.pop(-1)
+finalize = True
+self.__cli_expr(cmdargs[1:], action['data'])
+self._actions.append(action)
+return self.__build_cmd(')') if finalize else None
+
+# Standard command: parse and return it to be executed.
 qmpcmd = { 'execute': cmdargs[0], 'arguments': {} }
 self.__cli_expr(cmdargs[1:], qmpcmd['arguments'])
 return qmpcmd
@@ -171,6 +203,9 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 print 'command format: command-name ',
 print '[arg-name1=arg1] ... [arg-nameN=argN]'
 return True
+# For transaction mode, we may have just cached the action:
+if qmpcmd is None:
+return True
 resp = self.cmd_obj(qmpcmd)
 if resp is None:
 print 'Disconnected'
@@ -191,6 +226,11 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 version = self._greeting['QMP']['version']['qemu']
 print 'Connected to QEMU %d.%d.%d\n' % 
(version['major'],version['minor'],version['micro'])
 
+def get_prompt(self):
+if self._transmode:
+return TRANS 
+return (QEMU) 
+
 def read_exec_command(self, prompt):
 
 Read and execute a command.
@@ -330,7 +370,7 @@ def main():
 die('Could not connect to %s' % addr)
 
 qemu.show_banner()
-while qemu.read_exec_command('(QEMU) '):
+while qemu.read_exec_command(qemu.get_prompt()):
 pass
 qemu.close()
 
-- 
1.9.3

[Qemu-devel] [PULL 04/10] qobject: Add a special null QObject

[Luiz Capitulino]

From: Markus Armbruster arm...@redhat.com

I'm going to fix the JSON parser to recognize null.  The obvious
representation of JSON null as (QObject *)NULL doesn't work, because
the parser already uses it as an error value.  Perhaps we should
change it to free NULL for null, but that's more than I can do right
now.  Create a special null QObject instead.

The existing QDict, QList, and QString all represent something that
is a pointer in C and could therefore be associated with NULL.  But
right now, all three of these sub-types are always non-null once
created, so the new null sentinel object is intentionally unrelated
to them.

Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Eric Blake ebl...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 include/qapi/qmp/qobject.h | 11 ++-
 qobject/Makefile.objs  |  2 +-
 qobject/qjson.c|  3 +++
 qobject/qnull.c| 29 +
 4 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100644 qobject/qnull.c

diff --git a/include/qapi/qmp/qobject.h b/include/qapi/qmp/qobject.h
index 0991296..84b2d9f 100644
--- a/include/qapi/qmp/qobject.h
+++ b/include/qapi/qmp/qobject.h
@@ -3,7 +3,7 @@
  *
  * Based on ideas by Avi Kivity a...@redhat.com
  *
- * Copyright (C) 2009 Red Hat Inc.
+ * Copyright (C) 2009, 2015 Red Hat Inc.
  *
  * Authors:
  *  Luiz Capitulino lcapitul...@redhat.com
@@ -37,6 +37,7 @@
 
 typedef enum {
 QTYPE_NONE,/* sentinel value, no QObject has this type code */
+QTYPE_QNULL,
 QTYPE_QINT,
 QTYPE_QSTRING,
 QTYPE_QDICT,
@@ -110,4 +111,12 @@ static inline qtype_code qobject_type(const QObject *obj)
 return obj-type-code;
 }
 
+extern QObject qnull_;
+
+static inline QObject *qnull(void)
+{
+qobject_incref(qnull_);
+return qnull_;
+}
+
 #endif /* QOBJECT_H */
diff --git a/qobject/Makefile.objs b/qobject/Makefile.objs
index c9ff59c..f7595f5 100644
--- a/qobject/Makefile.objs
+++ b/qobject/Makefile.objs
@@ -1,3 +1,3 @@
-util-obj-y = qint.o qstring.o qdict.o qlist.o qfloat.o qbool.o
+util-obj-y = qnull.o qint.o qstring.o qdict.o qlist.o qfloat.o qbool.o
 util-obj-y += qjson.o json-lexer.o json-streamer.o json-parser.o
 util-obj-y += qerror.o
diff --git a/qobject/qjson.c b/qobject/qjson.c
index f2857c1..846733d 100644
--- a/qobject/qjson.c
+++ b/qobject/qjson.c
@@ -127,6 +127,9 @@ static void to_json_list_iter(QObject *obj, void *opaque)
 static void to_json(const QObject *obj, QString *str, int pretty, int indent)
 {
 switch (qobject_type(obj)) {
+case QTYPE_QNULL:
+qstring_append(str, null);
+break;
 case QTYPE_QINT: {
 QInt *val = qobject_to_qint(obj);
 char buffer[1024];
diff --git a/qobject/qnull.c b/qobject/qnull.c
new file mode 100644
index 000..9873e26
--- /dev/null
+++ b/qobject/qnull.c
@@ -0,0 +1,29 @@
+/*
+ * QNull
+ *
+ * Copyright (C) 2015 Red Hat, Inc.
+ *
+ * Authors:
+ *  Markus Armbruster arm...@redhat.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1
+ * or later.  See the COPYING.LIB file in the top-level directory.
+ */
+
+#include qemu-common.h
+#include qapi/qmp/qobject.h
+
+static void qnull_destroy_obj(QObject *obj)
+{
+assert(0);
+}
+
+static const QType qnull_type = {
+.code = QTYPE_QNULL,
+.destroy = qnull_destroy_obj,
+};
+
+QObject qnull_ = {
+.type = qnull_type,
+.refcnt = 1,
+};
-- 
1.9.3

[Qemu-devel] [PULL 05/10] json-parser: Accept 'null' in QMP

[Luiz Capitulino]

From: Eric Blake ebl...@redhat.com

We document that in QMP, the client may send any json-value
for the optional id key, and then return that same value
on reply (both success and failures, insofar as the failure
happened after parsing the id).  [Note that the output may
not be identical to the input, as whitespace may change and
since we may reorder keys within a json-object, but that this
still constitutes the same json-value].  However, we were not
handling the JSON literal null, which counts as a json-value
per RFC 7159.

Also, down the road, given the QAPI schema of {'*foo':'str'} or
{'*foo':'ComplexType'}, we could decide to allow the QMP client
to pass { foo:null } instead of the current representation of
{ } where omitting the key is the only way to get at the default
NULL value.  Such a change might be useful for argument
introspection (if a type in older qemu lacks 'foo' altogether,
then an explicit foo:null probe will force an easily
distinguished error message for whether the optional foo key
is even understood in newer qemu).  And if we add default values
to optional arguments, allowing an explicit null would be
required for getting a NULL value associated with an optional
string that has a non-null default.  But all that can come at a
later day.

The 'check-unit' testsuite is enhanced to test that parsing
produces the same object as explicitly requesting a reference
to the special qnull object.  In addition, I tested with:

$ ./x86_64-softmmu/qemu-system-x86_64 -qmp stdio -nodefaults
{QMP: {version: {qemu: {micro: 91, minor: 2, major: 2}, package: 
}, capabilities: []}}
{execute:qmp_capabilities,id:null}
{return: {}, id: null}
{id:{a:null,b:[1,null]},execute:quit}
{return: {}, id: {a: null, b: [1, null]}}
{timestamp: {seconds: 1427742379, microseconds: 423128}, event: 
SHUTDOWN}

Signed-off-by: Eric Blake ebl...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 qobject/json-parser.c |  2 ++
 tests/check-qjson.c   | 15 +--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/qobject/json-parser.c b/qobject/json-parser.c
index 4288267..717cb8f 100644
--- a/qobject/json-parser.c
+++ b/qobject/json-parser.c
@@ -561,6 +561,8 @@ static QObject *parse_keyword(JSONParserContext *ctxt)
 ret = QOBJECT(qbool_from_int(true));
 } else if (token_is_keyword(token, false)) {
 ret = QOBJECT(qbool_from_int(false));
+} else if (token_is_keyword(token, null)) {
+ret = qnull();
 } else {
 parse_error(ctxt, token, invalid keyword `%s', 
token_get_value(token));
 goto out;
diff --git a/tests/check-qjson.c b/tests/check-qjson.c
index 95497a0..60e5b22 100644
--- a/tests/check-qjson.c
+++ b/tests/check-qjson.c
@@ -1,6 +1,6 @@
 /*
  * Copyright IBM, Corp. 2009
- * Copyright (c) 2013 Red Hat Inc.
+ * Copyright (c) 2013, 2015 Red Hat Inc.
  *
  * Authors:
  *  Anthony Liguori   aligu...@us.ibm.com
@@ -1005,6 +1005,7 @@ static void keyword_literal(void)
 {
 QObject *obj;
 QBool *qbool;
+QObject *null;
 QString *str;
 
 obj = qobject_from_json(true);
@@ -1041,7 +1042,7 @@ static void keyword_literal(void)
 g_assert(qbool_get_int(qbool) == 0);
 
 QDECREF(qbool);
-
+
 obj = qobject_from_jsonf(%i, true);
 g_assert(obj != NULL);
 g_assert(qobject_type(obj) == QTYPE_QBOOL);
@@ -1050,6 +1051,16 @@ static void keyword_literal(void)
 g_assert(qbool_get_int(qbool) != 0);
 
 QDECREF(qbool);
+
+obj = qobject_from_json(null);
+g_assert(obj != NULL);
+g_assert(qobject_type(obj) == QTYPE_QNULL);
+
+null = qnull();
+g_assert(null == obj);
+
+qobject_decref(obj);
+qobject_decref(null);
 }
 
 typedef struct LiteralQDictEntry LiteralQDictEntry;
-- 
1.9.3

[Qemu-devel] [PULL 03/10] qobject: Clean up around qtype_code

[Luiz Capitulino]

From: Markus Armbruster arm...@redhat.com

QTYPE_NONE is a sentinel value.  No QObject has this type code.
Document it properly.

Fix dump_qobject() to abort() on QTYPE_NONE, just like for any other
invalid type code.

Fix to_json() to abort() on all invalid type codes, not just
QTYPE_MAX.

Clean up Property member qtype's type: it's a qtype_code.

Signed-off-by: Markus Armbruster arm...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 block/qapi.c   | 3 ---
 include/hw/qdev-core.h | 2 +-
 include/qapi/qmp/qobject.h | 2 +-
 qobject/qjson.c| 3 +--
 4 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/block/qapi.c b/block/qapi.c
index 063dd1b..18d2b95 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -523,9 +523,6 @@ static void dump_qobject(fprintf_function func_fprintf, 
void *f,
 QDECREF(value);
 break;
 }
-case QTYPE_NONE:
-break;
-case QTYPE_MAX:
 default:
 abort();
 }
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 4e673f9..9a0ee30 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -226,7 +226,7 @@ struct Property {
 PropertyInfo *info;
 int  offset;
 uint8_t  bitnr;
-uint8_t  qtype;
+qtype_code   qtype;
 int64_t  defval;
 int  arrayoffset;
 PropertyInfo *arrayinfo;
diff --git a/include/qapi/qmp/qobject.h b/include/qapi/qmp/qobject.h
index d0bbc7c..0991296 100644
--- a/include/qapi/qmp/qobject.h
+++ b/include/qapi/qmp/qobject.h
@@ -36,7 +36,7 @@
 #include assert.h
 
 typedef enum {
-QTYPE_NONE,
+QTYPE_NONE,/* sentinel value, no QObject has this type code */
 QTYPE_QINT,
 QTYPE_QSTRING,
 QTYPE_QDICT,
diff --git a/qobject/qjson.c b/qobject/qjson.c
index 12c576d..f2857c1 100644
--- a/qobject/qjson.c
+++ b/qobject/qjson.c
@@ -260,9 +260,8 @@ static void to_json(const QObject *obj, QString *str, int 
pretty, int indent)
 }
 case QTYPE_QERROR:
 /* XXX: should QError be emitted? */
-case QTYPE_NONE:
 break;
-case QTYPE_MAX:
+default:
 abort();
 }
 }
-- 
1.9.3

[Qemu-devel] [PULL 02/10] QJSON: Use OBJECT_CHECK

[Luiz Capitulino]

From: Eduardo Habkost ehabk...@redhat.com

The QJSON code used casts to (QJSON*) directly, instead of OBJECT_CHECK.
There were even some functions using object_dynamic_cast() calls
followed by assert(), which is exactly what OBJECT_CHECK does (by
calling object_dynamic_cast_assert()).

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 qjson.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/qjson.c b/qjson.c
index 0cda269..e478802 100644
--- a/qjson.c
+++ b/qjson.c
@@ -24,6 +24,8 @@ struct QJSON {
 bool omit_comma;
 };
 
+#define QJSON(obj) OBJECT_CHECK(QJSON, (obj), TYPE_QJSON)
+
 static void json_emit_element(QJSON *json, const char *name)
 {
 /* Check whether we need to print a , before an element */
@@ -87,7 +89,7 @@ const char *qjson_get_str(QJSON *json)
 
 QJSON *qjson_new(void)
 {
-QJSON *json = (QJSON *)object_new(TYPE_QJSON);
+QJSON *json = QJSON(object_new(TYPE_QJSON));
 return json;
 }
 
@@ -98,8 +100,7 @@ void qjson_finish(QJSON *json)
 
 static void qjson_initfn(Object *obj)
 {
-QJSON *json = (QJSON *)object_dynamic_cast(obj, TYPE_QJSON);
-assert(json);
+QJSON *json = QJSON(obj);
 
 json-str = qstring_from_str({ );
 json-omit_comma = true;
@@ -107,9 +108,8 @@ static void qjson_initfn(Object *obj)
 
 static void qjson_finalizefn(Object *obj)
 {
-QJSON *json = (QJSON *)object_dynamic_cast(obj, TYPE_QJSON);
+QJSON *json = QJSON(obj);
 
-assert(json);
 qobject_decref(QOBJECT(json-str));
 }
 
-- 
1.9.3

Re: [Qemu-devel] [PATCH] qmp: Add qom-path field to query-cpus command

[Luiz Capitulino]

On Mon,  4 May 2015 16:09:58 -0300
Eduardo Habkost ehabk...@redhat.com wrote:

 This will allow clients to query additional information directly using
 qom-get on the CPU objects.

Eduardo, I'm not applying this patch this time because Eric's comments
have to be addressed.

 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
 ---
 Reference to previous discussion:
 
   Date: Mon, 4 May 2015 15:37:40 -0300
   From: Eduardo Habkost ehabk...@redhat.com
   Message-ID: 20150504183740.gm17...@thinpad.lan.raisama.net
   Subject: Re: [Qemu-devel] [PATCH] cpu: Register QOM links at 
 /machine/cpus/index
 
 The summary is: even if we provide predictable QOM paths for the CPU
 objects, the qom-path field will be useful to allow the QOM objects and
 query-cpu data to be matched correctly.
 ---
  cpus.c   | 1 +
  qapi-schema.json | 7 +--
  qmp-commands.hx  | 1 +
  3 files changed, 7 insertions(+), 2 deletions(-)
 
 diff --git a/cpus.c b/cpus.c
 index 62d157a..de6469f 100644
 --- a/cpus.c
 +++ b/cpus.c
 @@ -1435,6 +1435,7 @@ CpuInfoList *qmp_query_cpus(Error **errp)
  info-value-CPU = cpu-cpu_index;
  info-value-current = (cpu == first_cpu);
  info-value-halted = cpu-halted;
 +info-value-qom_path = object_get_canonical_path(OBJECT(cpu));
  info-value-thread_id = cpu-thread_id;
  #if defined(TARGET_I386)
  info-value-has_pc = true;
 diff --git a/qapi-schema.json b/qapi-schema.json
 index ac9594d..7a52a78 100644
 --- a/qapi-schema.json
 +++ b/qapi-schema.json
 @@ -602,6 +602,8 @@
  # @halted: true if the virtual CPU is in the halt state.  Halt usually refers
  #  to a processor specific low power mode.
  #
 +# @qom-path: path to the CPU object in the QOM tree.
 +#
  # @pc: #optional If the target is i386 or x86_64, this is the 64-bit 
 instruction
  #pointer.
  #If the target is Sparc, this is the PC component of the
 @@ -622,8 +624,9 @@
  #data is sent to the client, the guest may no longer be halted.
  ##
  { 'type': 'CpuInfo',
 -  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', '*pc': 'int',
 -   '*nip': 'int', '*npc': 'int', '*PC': 'int', 'thread_id': 'int'} }
 +  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool', 'qom-path': 
 'str',
 +   '*pc': 'int', '*nip': 'int', '*npc': 'int', '*PC': 'int',
 +   'thread_id': 'int'} }
  
  ##
  # @query-cpus:
 diff --git a/qmp-commands.hx b/qmp-commands.hx
 index d4a837c..5c92162 100644
 --- a/qmp-commands.hx
 +++ b/qmp-commands.hx
 @@ -2569,6 +2569,7 @@ Return a json-array. Each CPU is represented by a 
 json-object, which contains:
  - CPU: CPU index (json-int)
  - current: true if this is the current CPU, false otherwise (json-bool)
  - halted: true if the cpu is halted, false otherwise (json-bool)
 +- qom-path: path to the CPU object in the QOM tree (json-str)
  - Current program counter. The key's name depends on the architecture:
   pc: i386/x86_64 (json-int)
   nip: PPC (json-int)

Re: [Qemu-devel] [PATCH v4 0/4] scripts: qmp-shell: add transaction support

[Luiz Capitulino]

On Wed, 29 Apr 2015 15:14:00 -0400
John Snow js...@redhat.com wrote:

 The qmp-shell is a little rudimentary, but it can be hacked
 to give us some transactional support without too much difficulty.
 
 (1) Prep.
 (2) Add support for serializing json arrays and
 improve the robustness of QMP parsing
 (3) Add a special transaction( ... ) syntax that lets users
 build up transactional commands using the existing qmp shell
 syntax to define each action.
 (4) Add a verbose flag to display generated QMP commands.
 
 The parsing is not as robust as one would like, but this suffices
 without adding a proper parser.
 
 Design considerations:
 
 (1) Try not to disrupt the existing design of the qmp-shell. The existing
 API is not disturbed.
 (2) Pick a magic token such that it could not be confused for legitimate
 QMP/JSON syntax. Parentheses are used for this purpose.
 
 For convenience, this branch is available at:
 https://github.com/jnsnow/qemu.git branch qmp-shell++
 This version is tagged qmp-shell++-v4.

Applied to the qmp branch, thanks.

 
 ===
 v++
 ===
 
  - Use the AST to allow 'true', 'false' and 'null' within QMP expressions
  - Fix a bunch of stupid junk I broke in v2, apparently.
 
 ===
 v3:
 ===
 
  - Folding in hotfix from list (import ast)
 
 ===
 v2:
 ===
 
  - Squash patches 2  3:
  - Remove wholesale replacement of single quotes, in favor of try blocks
that attempt to parse as pure JSON, then as Python.
  - Factored out the value parser block to accomplish the above.
  - Allow both true/True and false/False for values.
  - Fix typo in patch 3 cover letter. (was patch 4.)
 
 John Snow (4):
   scripts: qmp-shell: refactor helpers
   scripts: qmp-shell: Expand support for QMP expressions
   scripts: qmp-shell: add transaction subshell
   scripts: qmp-shell: Add verbose flag
 
  scripts/qmp/qmp-shell | 147 
 +++---
  1 file changed, 116 insertions(+), 31 deletions(-)
 

[Qemu-devel] [PULL 08/10] scripts: qmp-shell: Expand support for QMP expressions

[Luiz Capitulino]

From: John Snow js...@redhat.com

This includes support for [] expressions, single-quotes in
QMP expressions (which is not strictly a part of JSON), and
the ability to use True, False and None literals instead
of JSON's equivalent true, false, and null literals.

qmp-shell currently allows you to describe values as
JSON expressions:
key={key:{key2:val}}

But it does not currently support arrays, which are needed
for serializing and deserializing transactions:
key=[{type:drive-backup,data:{...}}]

qmp-shell also only currently accepts doubly quoted strings
as-per JSON spec, but QMP allows single quotes.

Lastly, python allows you to utilize True or False as
boolean literals, but JSON expects true or false. Expand
qmp-shell to allow the user to type either, converting to the
correct type.

As a consequence of the above, the key=val parsing is also improved
to give better error messages if a key=val token is not provided.

CAVEAT: The parser is still extremely rudimentary and does not
expect to find spaces in {} nor [] expressions. This patch does
not improve this functionality.

Signed-off-by: John Snow js...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Tested-by: Kashyap Chamarthy kcham...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 scripts/qmp/qmp-shell | 63 ++-
 1 file changed, 47 insertions(+), 16 deletions(-)

diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell
index a9632ec..7f2c554 100755
--- a/scripts/qmp/qmp-shell
+++ b/scripts/qmp/qmp-shell
@@ -32,6 +32,7 @@
 
 import qmp
 import json
+import ast
 import readline
 import sys
 import pprint
@@ -51,6 +52,19 @@ class QMPShellError(Exception):
 class QMPShellBadPort(QMPShellError):
 pass
 
+class FuzzyJSON(ast.NodeTransformer):
+'''This extension of ast.NodeTransformer filters literal true/false/null
+values in an AST and replaces them by proper True/False/None values that
+Python can properly evaluate.'''
+def visit_Name(self, node):
+if node.id == 'true':
+node.id = 'True'
+if node.id == 'false':
+node.id = 'False'
+if node.id == 'null':
+node.id = 'None'
+return node
+
 # TODO: QMPShell's interface is a bit ugly (eg. _fill_completion() and
 #   _execute_cmd()). Let's design a better one.
 class QMPShell(qmp.QEMUMonitorProtocol):
@@ -88,23 +102,40 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 # clearing everything as it doesn't seem to matter
 readline.set_completer_delims('')
 
-def __cli_expr(self, tokens, parent):
-for arg in tokens:
-opt = arg.split('=')
+def __parse_value(self, val):
+try:
+return int(val)
+except ValueError:
+pass
+
+if val.lower() == 'true':
+return True
+if val.lower() == 'false':
+return False
+if val.startswith(('{', '[')):
+# Try first as pure JSON:
 try:
-if(len(opt)  2):
-opt[1] = '='.join(opt[1:])
-value = int(opt[1])
+return json.loads(val)
 except ValueError:
-if opt[1] == 'true':
-value = True
-elif opt[1] == 'false':
-value = False
-elif opt[1].startswith('{'):
-value = json.loads(opt[1])
-else:
-value = opt[1]
-optpath = opt[0].split('.')
+pass
+# Try once again as FuzzyJSON:
+try:
+st = ast.parse(val, mode='eval')
+return ast.literal_eval(FuzzyJSON().visit(st))
+except SyntaxError:
+pass
+except ValueError:
+pass
+return val
+
+def __cli_expr(self, tokens, parent):
+for arg in tokens:
+(key, _, val) = arg.partition('=')
+if not val:
+raise QMPShellError(Expected a key=value pair, got '%s' % 
arg)
+
+value = self.__parse_value(val)
+optpath = key.split('.')
 curpath = []
 for p in optpath[:-1]:
 curpath.append(p)
@@ -117,7 +148,7 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 if type(parent[optpath[-1]]) is dict:
 raise QMPShellError('Cannot use %s as both leaf and 
non-leaf key' % '.'.join(curpath))
 else:
-raise QMPShellError('Cannot set %s multiple times' % 
opt[0])
+raise QMPShellError('Cannot set %s multiple times' % key)
 parent[optpath[-1]] = value
 
 def __build_cmd(self, cmdline):
-- 
1.9.3

[Qemu-devel] [PULL 07/10] scripts: qmp-shell: refactor helpers

[Luiz Capitulino]

From: John Snow js...@redhat.com

Refactor the qmp-shell command line processing function
into two components. This will be used to allow sub-expressions,
which will assist us in adding transactional support to qmp-shell.

Signed-off-by: John Snow js...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Tested-by: Kashyap Chamarthy kcham...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 scripts/qmp/qmp-shell | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/scripts/qmp/qmp-shell b/scripts/qmp/qmp-shell
index e0e848b..a9632ec 100755
--- a/scripts/qmp/qmp-shell
+++ b/scripts/qmp/qmp-shell
@@ -88,16 +88,8 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 # clearing everything as it doesn't seem to matter
 readline.set_completer_delims('')
 
-def __build_cmd(self, cmdline):
-
-Build a QMP input object from a user provided command-line in the
-following format:
-
- command-name  [ arg-name1=arg1 ] ... [ arg-nameN=argN ]
-
-cmdargs = cmdline.split()
-qmpcmd = { 'execute': cmdargs[0], 'arguments': {} }
-for arg in cmdargs[1:]:
+def __cli_expr(self, tokens, parent):
+for arg in tokens:
 opt = arg.split('=')
 try:
 if(len(opt)  2):
@@ -113,7 +105,6 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 else:
 value = opt[1]
 optpath = opt[0].split('.')
-parent = qmpcmd['arguments']
 curpath = []
 for p in optpath[:-1]:
 curpath.append(p)
@@ -128,6 +119,17 @@ class QMPShell(qmp.QEMUMonitorProtocol):
 else:
 raise QMPShellError('Cannot set %s multiple times' % 
opt[0])
 parent[optpath[-1]] = value
+
+def __build_cmd(self, cmdline):
+
+Build a QMP input object from a user provided command-line in the
+following format:
+
+ command-name  [ arg-name1=arg1 ] ... [ arg-nameN=argN ]
+
+cmdargs = cmdline.split()
+qmpcmd = { 'execute': cmdargs[0], 'arguments': {} }
+self.__cli_expr(cmdargs[1:], qmpcmd['arguments'])
 return qmpcmd
 
 def _execute_cmd(self, cmdline):
-- 
1.9.3

[Qemu-devel] [PULL 01/10] monitor: add memory search commands s, sp

[Luiz Capitulino]

From: Claudio Fontana claudio.font...@huawei.com

usage is similar to the commands x, xp.

Example with string: looking for ELF header in memory:

(qemu) s/100cb 0x40001000 ELF
searching memory area [40001000-400f5240]
40090001
(qemu) x/20b 0x4009
4009: '\x7f' 'E' 'L' 'F' '\x02' '\x01' '\x01' '\x03'
40090008: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00'
40090010: '\x02' '\x00' '\xb7' '\x00'

Example with value: looking for 64bit variable value 0x990088

(qemu) s/100xg 0x90004200 0x990088
searching memory area [90004200-9000427a1200]
9000424b3000
9000424c1000

Signed-off-by: Claudio Fontana claudio.font...@huawei.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
 hmp-commands.hx |  28 
 monitor.c   | 140 
 2 files changed, 168 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index e864a6c..badf1f5 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -430,6 +430,34 @@ Start gdbserver session (default @var{port}=1234)
 ETEXI
 
 {
+.name   = s,
+.args_type  = fmt:/,addr:l,data:s,
+.params = /fmt addr data,
+.help   = search virtual memory starting at 'addr' for 'data',
+.mhandler.cmd = hmp_memory_search,
+},
+
+STEXI
+@item s/fmt @var{addr} @var{data}
+@findex s
+Virtual memory search starting at @var{addr} for data described by @var{data}.
+ETEXI
+
+{
+.name   = sp,
+.args_type  = fmt:/,addr:l,data:s,
+.params = /fmt addr data,
+.help   = search physical memory starting at 'addr' for 'data',
+.mhandler.cmd = hmp_physical_memory_search,
+},
+
+STEXI
+@item sp/fmt @var{addr} @var{data}
+@findex sp
+Physical memory search starting at @var{addr} for data described by @var{data}.
+ETEXI
+
+{
 .name   = x,
 .args_type  = fmt:/,addr:l,
 .params = /fmt addr,
diff --git a/monitor.c b/monitor.c
index 3952d64..9611d4f 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1205,6 +1205,124 @@ static void monitor_printc(Monitor *mon, int c)
 monitor_printf(mon, ');
 }
 
+static void monitor_print_addr(Monitor *mon, hwaddr addr, bool is_physical)
+{
+if (is_physical) {
+monitor_printf(mon, TARGET_FMT_plx \n, addr);
+} else {
+monitor_printf(mon, TARGET_FMT_lx \n, (target_ulong)addr);
+}
+}
+
+/* simple memory search for a byte sequence. The sequence is generated from
+ * a numeric value to look for in guest memory, or from a string.
+ */
+static void memory_search(Monitor *mon, int count, int format, int wsize,
+  hwaddr addr, const char *data_str, bool is_physical)
+{
+int pos, len;  /* pos in the search area, len of area */
+char *hay; /* buffer for haystack */
+int hay_size;  /* haystack size. Needle size is wsize. */
+const char *needle = NULL; /* needle to search in the haystack */
+const char *format_str;/* numeric input format string */
+char value_raw[8]; /* numeric input converted to raw data */
+#define MONITOR_S_CHUNK_SIZE 16000
+
+len = wsize * count;
+if (len  1) {
+monitor_printf(mon, invalid search area length.\n);
+return;
+}
+switch (format) {
+case 'i':
+monitor_printf(mon, format '%c' not supported.\n, format);
+return;
+case 'c':
+needle = data_str;
+wsize = strlen(data_str);
+if (wsize  MONITOR_S_CHUNK_SIZE) {
+monitor_printf(mon, search string too long [max %d].\n,
+   MONITOR_S_CHUNK_SIZE);
+return;
+}
+break;
+case 'o':
+format_str = % SCNo64;
+break;
+default:
+case 'x':
+format_str = % SCNx64;
+break;
+case 'u':
+format_str = % SCNu64;
+break;
+case 'd':
+format_str = % SCNd64;
+break;
+}
+if (format != 'c') {
+uint64_t value;  /* numeric input value */
+void *from = value;
+if (sscanf(data_str, format_str, value) != 1) {
+monitor_printf(mon, could not parse search string 
+   \%s\ as format '%c'.\n, data_str, format);
+return;
+}
+#if defined(HOST_WORDS_BIGENDIAN) != defined(TARGET_WORDS_BIGENDIAN)
+value = bswap64(value);
+#endif
+#if defined(TARGET_WORDS_BIGENDIAN)
+from += 8 - wsize;
+#endif
+memcpy(value_raw, from, wsize);
+needle = value_raw;
+}
+monitor_printf(mon, searching memory area );
+if (is_physical) {
+monitor_printf(mon, [ TARGET_FMT_plx - TARGET_FMT_plx ]\n,
+   addr, addr + len);
+} else {
+monitor_printf(mon, [ TARGET_FMT_lx - TARGET_FMT_lx ]\n,
+   (target_ulong)addr, (target_ulong)addr + len

[Qemu-devel] [PULL 00/10] QMP queue

[Luiz Capitulino]

The following changes since commit f8340b360b9bc29d48716ba8aca79df2b9544979:

  hw/ptimer: Do not artificially limit timers when using icount (2015-05-08 
17:15:23 +1000)

are available in the git repository at:

  git://repo.or.cz/qemu/qmp-unstable.git tags/for-upstream

for you to fetch changes up to 07972d16e3343dc62302b81efb018308f99f7a7a:

  scripts: qmp-shell: Add verbose flag (2015-05-08 08:47:01 -0400)


QMP pull request


Claudio Fontana (1):
  monitor: add memory search commands s, sp

Eduardo Habkost (1):
  QJSON: Use OBJECT_CHECK

Eric Blake (1):
  json-parser: Accept 'null' in QMP

John Snow (4):
  scripts: qmp-shell: refactor helpers
  scripts: qmp-shell: Expand support for QMP expressions
  scripts: qmp-shell: add transaction subshell
  scripts: qmp-shell: Add verbose flag

Luiz Capitulino (1):
  MAINTAINERS: New maintainer for QMP and QAPI

Markus Armbruster (2):
  qobject: Clean up around qtype_code
  qobject: Add a special null QObject

 MAINTAINERS|  18 +++---
 block/qapi.c   |   3 -
 hmp-commands.hx|  28 +
 include/hw/qdev-core.h |   2 +-
 include/qapi/qmp/qobject.h |  13 +++-
 monitor.c  | 140 ++
 qjson.c|  10 +--
 qobject/Makefile.objs  |   2 +-
 qobject/json-parser.c  |   2 +
 qobject/qjson.c|   6 +-
 qobject/qnull.c|  29 +
 scripts/qmp/qmp-shell  | 147 +++--
 tests/check-qjson.c|  15 -
 13 files changed, 359 insertions(+), 56 deletions(-)
 create mode 100644 qobject/qnull.c

[Qemu-devel] [PULL 06/10] MAINTAINERS: New maintainer for QMP and QAPI

[Luiz Capitulino]

Markus is taking over maintership of QMP and the QAPI from
me. Markus has always been a great reviewer and contributor
to those subsystems. In the last few months he's also doing
pull requests that are a lot more relevant than the ones I
was able to do. So, this is a natural move.

I'm still the maintainer of HMP and QObjects, but I'm
looking for someone to take over those too.

PS: This commit also fixes the file listing for the QMP
entry.

Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Reviewed-by: Michael Roth mdr...@linux.vnet.ibm.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
 MAINTAINERS | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0b67c48..d858c49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -926,20 +926,19 @@ K: srat|SRAT
 T: git git://github.com/ehabkost/qemu.git numa
 
 QAPI
-M: Luiz Capitulino lcapitul...@redhat.com
+M: Markus Armbruster arm...@redhat.com
 M: Michael Roth mdr...@linux.vnet.ibm.com
-S: Maintained
+S: Supported
 F: qapi/
 F: tests/qapi-schema/
-T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
+T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 QAPI Schema
 M: Eric Blake ebl...@redhat.com
-M: Luiz Capitulino lcapitul...@redhat.com
 M: Markus Armbruster arm...@redhat.com
 S: Supported
 F: qapi-schema.json
-T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
+T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 QObject
 M: Luiz Capitulino lcapitul...@redhat.com
@@ -964,13 +963,14 @@ X: qom/cpu.c
 F: tests/qom-test.c
 
 QMP
-M: Luiz Capitulino lcapitul...@redhat.com
-S: Maintained
+M: Markus Armbruster arm...@redhat.com
+S: Supported
 F: qmp.c
 F: monitor.c
 F: qmp-commands.hx
-F: QMP/
-T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
+F: docs/qmp/
+F: scripts/qmp/
+T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 SLIRP
 M: Jan Kiszka jan.kis...@siemens.com
-- 
1.9.3

[Qemu-devel] [PATCH] MAINTAINERS: New maintainer for QMP and QAPI

[Luiz Capitulino]

Markus is taking over maintership of QMP and the QAPI from
me. Markus has always been a great reviewer and contributor
to those subsystems. In the last few months he's also doing
pull requests that are a lot more relevant than the ones I
was able to do. So, this is a natural move.

I'm still the maintainer of HMP and QObjects, but I'm
looking for someone to take over those too.

PS: This commit also fixes the file listing for the QMP
entry.

Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---

PPS: I'll post a last QMP pull request this week.

 MAINTAINERS | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0b67c48..d858c49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -926,20 +926,19 @@ K: srat|SRAT
 T: git git://github.com/ehabkost/qemu.git numa
 
 QAPI
-M: Luiz Capitulino lcapitul...@redhat.com
+M: Markus Armbruster arm...@redhat.com
 M: Michael Roth mdr...@linux.vnet.ibm.com
-S: Maintained
+S: Supported
 F: qapi/
 F: tests/qapi-schema/
-T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
+T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 QAPI Schema
 M: Eric Blake ebl...@redhat.com
-M: Luiz Capitulino lcapitul...@redhat.com
 M: Markus Armbruster arm...@redhat.com
 S: Supported
 F: qapi-schema.json
-T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
+T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 QObject
 M: Luiz Capitulino lcapitul...@redhat.com
@@ -964,13 +963,14 @@ X: qom/cpu.c
 F: tests/qom-test.c
 
 QMP
-M: Luiz Capitulino lcapitul...@redhat.com
-S: Maintained
+M: Markus Armbruster arm...@redhat.com
+S: Supported
 F: qmp.c
 F: monitor.c
 F: qmp-commands.hx
-F: QMP/
-T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
+F: docs/qmp/
+F: scripts/qmp/
+T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 SLIRP
 M: Jan Kiszka jan.kis...@siemens.com
-- 
1.9.3

Re: [Qemu-devel] [PATCH v6 04/17] Extend HMP command info cpus to display accelerator id and model name

[Luiz Capitulino]

On Wed, 6 May 2015 07:38:53 -0300
Eduardo Habkost ehabk...@redhat.com wrote:

 On Wed, May 06, 2015 at 09:32:58AM +0200, Michael Mueller wrote:
  On Tue, 5 May 2015 10:14:32 -0300
  Eduardo Habkost ehabk...@redhat.com wrote:
  
   On Mon, Apr 27, 2015 at 04:53:18PM +0200, Michael Mueller wrote:
The HMP command info cpus now displays the CPU model name and the
backing accelerator if part of the CPUState.

(qemu) info cpus
* CPU #0: (halted) model=2827-ga2 accel=kvm thread_id=1679

Signed-off-by: Michael Mueller m...@linux.vnet.ibm.com
Acked-by: Christian Borntraeger borntrae...@de.ibm.com
   
   Do we really need this? I mean: I expect the amount of CPU data we
   provide to QMP clients to grow a lot in the near future, but that
   doesn't mean HMP users need all that data to be printed by info cpus.
  
  Where do you see the limit of what is worth to be shown an what not.
  I personally use info cpus less then sporadic but already got a comment
  internally on that information being worthwhile to be shown.  
 
 I really don't know, but I think we shouldn't add stuff to HMP unless we
 have a good reason. For each new piece of data in HMP I would like to at
 least see the description of a real use case that justifies adding it to
 HMP and not just implementing a simple script on top of QMP.
 
 For accel info we already have info kvm that is not ideal but is
 enough for current use cases, isn't it? CPU model name information seems
 to be more useful, but if it is just for debugging, people can just run
 QMP query-cpus command.
 
 Luiz, what do you think?

I don't see a problem with that. HMP is a debugging interface anyways.
Actually, I think it's a good test-case for QMP having a high-level
in-tree client (vs. qmp-shell, which is too low-level).

If the problem is that a command is dumping too much information to
the point of hurting usability, we can split the command or add a '-a'
option or something like that.

 
  
   
   
---
 hmp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hmp.c b/hmp.c
index f142d36..676d821 100644
--- a/hmp.c
+++ b/hmp.c
@@ -290,6 +290,13 @@ void hmp_info_cpus(Monitor *mon, const QDict 
*qdict)
 monitor_printf(mon,  (halted));
 }
 
+if (cpu-value-has_model) {
+monitor_printf(mon,  model=%s, cpu-value-model);
+}
+if (cpu-value-has_accel) {
+monitor_printf(mon,  accel=%s, 
AccelId_lookup[cpu-value-accel]);
+}
+
 monitor_printf(mon,  thread_id=% PRId64 \n, 
cpu-value-thread_id);
 }
 
-- 
1.8.3.1