Re: [Qemu-devel] [PATCH v3] i386, acpi: check acpi_memory_hotplug capacity in pre_plug

[Wei Yang]

On Tue, Feb 19, 2019 at 08:53:22AM +0800, Wei Yang wrote:
>Currently we do device realization like below:
>
>   hotplug_handler_pre_plug()
>   dc->realize()
>   hotplug_handler_plug()
>
>Before we do device realization and plug, we should allocate necessary
>resources and check if memory-hotplug-support property is enabled.
>
>At the piix4 and ich9, the memory-hotplug-support property is checked at
>plug stage. This means that device has been realized and mapped into guest
>address space 'pc_dimm_plug()' by the time acpi plug handler is called,
>where it might fail and crash QEMU due to reaching g_assert_not_reached()
>(piix4) or error_abort (ich9).
>
>Fix it by checking if memory hotplug is enabled at pre_plug stage
>where we can gracefully abort hotplug request.
>
>Signed-off-by: Wei Yang 
>CC: Igor Mammedov 
>CC: Eric Blake 
>
>---
>v3:
>   * replace acpi_memory_hotplug with memory-hotplug-support in changelog
>   * fix code alignment of ich9_pm_device_pre_plug_cb
>   * print which device type memory-hotplug-support is disabled in
> ich9_pm_device_pre_plug_cb and piix4_device_pre_plug_cb
>v2:
>   * (imamm...@redhat.com)
> - Almost the whole third paragraph
>   * apply this change to ich9
>   * use hotplug_handler_pre_plug() instead of open-coding check
>---
> hw/acpi/ich9.c | 15 +--
> hw/acpi/piix4.c| 15 +--
> hw/i386/pc.c   |  5 +
> hw/isa/lpc_ich9.c  |  1 +
> include/hw/acpi/ich9.h |  2 ++
> 5 files changed, 34 insertions(+), 4 deletions(-)
>
>diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
>index c5d8646abc..e53dfe1ee3 100644
>--- a/hw/acpi/ich9.c
>+++ b/hw/acpi/ich9.c
>@@ -483,13 +483,24 @@ void ich9_pm_add_properties(Object *obj, ICH9LPCPMRegs 
>*pm, Error **errp)
>  NULL);
> }
> 
>+void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
>+Error **errp)
>+{
>+ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
>+
>+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
>+!lpc->pm.acpi_memory_hotplug.is_enabled)
>+error_setg(errp,
>+   "memory hotplug is not enabled: %s.memory-hotplug-support "
>+   "is not set", object_get_typename(OBJECT(lpc)));
>+}
>+
> void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
> Error **errp)
> {
> ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
> 
>-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
>-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
>+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
> nvdimm_acpi_plug_cb(hotplug_dev, dev);
> } else {
>diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
>index e330f24c71..f7e3c2018d 100644
>--- a/hw/acpi/piix4.c
>+++ b/hw/acpi/piix4.c
>@@ -370,13 +370,23 @@ static void piix4_pm_powerdown_req(Notifier *n, void 
>*opaque)
> acpi_pm1_evt_power_down(&s->ar);
> }
> 
>+static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev,
>+ DeviceState *dev, Error **errp)

Miss to fix this alignment...

Please ignore this one.

>+{
>+PIIX4PMState *s = PIIX4_PM(hotplug_dev);
>+
>+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
>+!s->acpi_memory_hotplug.is_enabled)
>+error_setg(errp,
>+   "memory hotplug is not enabled: %s.memory-hotplug-support "
>+   "is not set", object_get_typename(OBJECT(s)));
>+}
> static void piix4_device_plug_cb(HotplugHandler *hotplug_dev,
>  DeviceState *dev, Error **errp)
> {
> PIIX4PMState *s = PIIX4_PM(hotplug_dev);
> 
>-if (s->acpi_memory_hotplug.is_enabled &&
>-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
>+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
> nvdimm_acpi_plug_cb(hotplug_dev, dev);
> } else {
>@@ -702,6 +712,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void 
>*data)
>  */
> dc->user_creatable = false;
> dc->hotpluggable = false;
>+hc->pre_plug = piix4_device_pre_plug_cb;
> hc->plug = piix4_device_plug_cb;
> hc->unplug_request = piix4_device_unplug_request_cb;
> hc->unplug = piix4_device_unplug_cb;
>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>index 0f61314b79..0b11ebe2c9 100644
>--- a/hw/i386/pc.c
>+++ b/hw/i386/pc.c
>@@ -1674,6 +1674,11 @@ static void pc_memory_pre_plug(HotplugHandler 
>*hotplug_dev, DeviceState *dev,
> return;
> }
> 
>+/*
>+ * Check acpi_dev memory-hotplug-support property
>+ */
>+hotplug_handler_pre_plug(pcms->acpi_dev, dev, errp);
>+
> if (is_nvdimm && !pcms->acpi_nvdimm_state.is_enabled) {
> error_setg(errp, "nvdimm is not enabled: missing 'nvdimm' in '-M'");
> return;
>diff --git a/hw/isa/lpc_ich9.c

[Qemu-devel] [PATCH v4] i386, acpi: check acpi_memory_hotplug capacity in pre_plug

[Wei Yang]

Currently we do device realization like below:

   hotplug_handler_pre_plug()
   dc->realize()
   hotplug_handler_plug()

Before we do device realization and plug, we should allocate necessary
resources and check if memory-hotplug-support property is enabled.

At the piix4 and ich9, the memory-hotplug-support property is checked at
plug stage. This means that device has been realized and mapped into guest
address space 'pc_dimm_plug()' by the time acpi plug handler is called,
where it might fail and crash QEMU due to reaching g_assert_not_reached()
(piix4) or error_abort (ich9).

Fix it by checking if memory hotplug is enabled at pre_plug stage
where we can gracefully abort hotplug request.

Signed-off-by: Wei Yang 
CC: Igor Mammedov 
CC: Eric Blake 

---
v4:
   * fix code alignment of piix4_device_pre_plug_cb
v3:
   * replace acpi_memory_hotplug with memory-hotplug-support in changelog
   * fix code alignment of ich9_pm_device_pre_plug_cb
   * print which device type memory-hotplug-support is disabled in
 ich9_pm_device_pre_plug_cb and piix4_device_pre_plug_cb
v2:
   * (imamm...@redhat.com)
 - Almost the whole third paragraph
   * apply this change to ich9
   * use hotplug_handler_pre_plug() instead of open-coding check
---
 hw/acpi/ich9.c | 15 +--
 hw/acpi/piix4.c| 15 +--
 hw/i386/pc.c   |  5 +
 hw/isa/lpc_ich9.c  |  1 +
 include/hw/acpi/ich9.h |  2 ++
 5 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index c5d8646abc..e53dfe1ee3 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -483,13 +483,24 @@ void ich9_pm_add_properties(Object *obj, ICH9LPCPMRegs 
*pm, Error **errp)
  NULL);
 }
 
+void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
+Error **errp)
+{
+ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
+
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
+!lpc->pm.acpi_memory_hotplug.is_enabled)
+error_setg(errp,
+   "memory hotplug is not enabled: %s.memory-hotplug-support "
+   "is not set", object_get_typename(OBJECT(lpc)));
+}
+
 void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
 Error **errp)
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
 nvdimm_acpi_plug_cb(hotplug_dev, dev);
 } else {
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index e330f24c71..699aca630e 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -370,13 +370,23 @@ static void piix4_pm_powerdown_req(Notifier *n, void 
*opaque)
 acpi_pm1_evt_power_down(&s->ar);
 }
 
+static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev,
+ DeviceState *dev, Error **errp)
+{
+PIIX4PMState *s = PIIX4_PM(hotplug_dev);
+
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
+!s->acpi_memory_hotplug.is_enabled)
+error_setg(errp,
+   "memory hotplug is not enabled: %s.memory-hotplug-support "
+   "is not set", object_get_typename(OBJECT(s)));
+}
 static void piix4_device_plug_cb(HotplugHandler *hotplug_dev,
  DeviceState *dev, Error **errp)
 {
 PIIX4PMState *s = PIIX4_PM(hotplug_dev);
 
-if (s->acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
 nvdimm_acpi_plug_cb(hotplug_dev, dev);
 } else {
@@ -702,6 +712,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void 
*data)
  */
 dc->user_creatable = false;
 dc->hotpluggable = false;
+hc->pre_plug = piix4_device_pre_plug_cb;
 hc->plug = piix4_device_plug_cb;
 hc->unplug_request = piix4_device_unplug_request_cb;
 hc->unplug = piix4_device_unplug_cb;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0f61314b79..0b11ebe2c9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1674,6 +1674,11 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
+/*
+ * Check acpi_dev memory-hotplug-support property
+ */
+hotplug_handler_pre_plug(pcms->acpi_dev, dev, errp);
+
 if (is_nvdimm && !pcms->acpi_nvdimm_state.is_enabled) {
 error_setg(errp, "nvdimm is not enabled: missing 'nvdimm' in '-M'");
 return;
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index e692b9fdc1..ac44aa53be 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -805,6 +805,7 @@ static void ich9_lpc_class_init(ObjectClass *klass, void 
*da

Re: [Qemu-devel] [RFC PATCH 3/4] spapr: Add NVDIMM device support

[Igor Mammedov]

On Tue, 05 Feb 2019 23:26:27 -0600
Shivaprasad G Bhat  wrote:

> Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
> device interface in QEMU to support virtual NVDIMM devices for Power (May have
> to re-look at this later).  Create the required DT entries for the
> device (some entries have dummy values right now).
> 
> The patch creates the required DT node and sends a hotplug
> interrupt to the guest. Guest is expected to undertake the normal
> DR resource add path in response and start issuing PAPR SCM hcalls.
> 
> This is how it can be used ..
> Add nvdimm=on to the qemu machine argument.
> Ex : -machine pseries,nvdimm=on
> For coldplug, the device to be added in qemu command line as shown below
> -object 
> memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0.img,share=yes,size=512m
> -device nvdimm,label-size=128k,memdev=memnvdimm0,id=nvdimm0,slot=0
> 
> For hotplug, the device to be added from monitor as below
> object_add 
> memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0.img,share=yes,size=512m
> device_add nvdimm,label-size=128k,memdev=memnvdimm0,id=nvdimm0,slot=0
> 
> Signed-off-by: Shivaprasad G Bhat 
> Signed-off-by: Bharata B Rao 
>[Early implementation]
> ---
>  default-configs/ppc64-softmmu.mak |1 
>  hw/ppc/spapr.c|  212 
> +++--
>  hw/ppc/spapr_drc.c|   17 +++
>  hw/ppc/spapr_events.c |4 +
>  include/hw/ppc/spapr.h|   10 ++
>  include/hw/ppc/spapr_drc.h|9 ++
>  6 files changed, 241 insertions(+), 12 deletions(-)
> 
> diff --git a/default-configs/ppc64-softmmu.mak 
> b/default-configs/ppc64-softmmu.mak
> index 7f34ad0528..b6e1aa5125 100644
> --- a/default-configs/ppc64-softmmu.mak
> +++ b/default-configs/ppc64-softmmu.mak
> @@ -20,4 +20,5 @@ CONFIG_XIVE=$(CONFIG_PSERIES)
>  CONFIG_XIVE_SPAPR=$(CONFIG_PSERIES)
>  CONFIG_MEM_DEVICE=y
>  CONFIG_DIMM=y
> +CONFIG_NVDIMM=y
>  CONFIG_SPAPR_RNG=y
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 0fcdd35cbe..7e7a1a8041 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -73,6 +73,7 @@
>  #include "qemu/cutils.h"
>  #include "hw/ppc/spapr_cpu_core.h"
>  #include "hw/mem/memory-device.h"
> +#include "hw/mem/nvdimm.h"
>  
>  #include 
>  
> @@ -690,6 +691,7 @@ static int spapr_populate_drmem_v2(sPAPRMachineState 
> *spapr, void *fdt,
>  uint8_t *int_buf, *cur_index, buf_len;
>  int ret;
>  uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
> +uint64_t scm_block_size = SPAPR_MINIMUM_SCM_BLOCK_SIZE;
>  uint64_t addr, cur_addr, size;
>  uint32_t nr_boot_lmbs = (machine->device_memory->base / lmb_size);
>  uint64_t mem_end = machine->device_memory->base +
> @@ -726,15 +728,24 @@ static int spapr_populate_drmem_v2(sPAPRMachineState 
> *spapr, void *fdt,
>  nr_entries++;
>  }
>  
> -/* Entry for DIMM */
> -drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / lmb_size);
> -g_assert(drc);
> -elem = spapr_get_drconf_cell(size / lmb_size, addr,
> - spapr_drc_index(drc), node,
> - SPAPR_LMB_FLAGS_ASSIGNED);
> +if (info->value->type == MEMORY_DEVICE_INFO_KIND_NVDIMM) {
> +/* Entry for NVDIMM */
> +drc = spapr_drc_by_id(TYPE_SPAPR_DRC_PMEM, addr / 
> scm_block_size);
> +g_assert(drc);
> +elem = spapr_get_drconf_cell(size / scm_block_size, addr,
> + spapr_drc_index(drc), -1, 0);
> +cur_addr = ROUND_UP(addr + size, scm_block_size);
> +} else {
> +/* Entry for DIMM */
> +drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / lmb_size);
> +g_assert(drc);
> +elem = spapr_get_drconf_cell(size / lmb_size, addr,
> + spapr_drc_index(drc), node,
> + SPAPR_LMB_FLAGS_ASSIGNED);
> +cur_addr = addr + size;
> +}
>  QSIMPLEQ_INSERT_TAIL(&drconf_queue, elem, entry);
>  nr_entries++;
> -cur_addr = addr + size;
>  }
>  
>  /* Entry for remaining hotpluggable area */
> @@ -1225,6 +1236,42 @@ static void spapr_dt_hypervisor(sPAPRMachineState 
> *spapr, void *fdt)
>  }
>  }
>  
> +static int spapr_populate_nvdimm_node(void *fdt, int fdt_offset,
> +  uint32_t node, uint64_t addr,
> +  uint64_t size, uint64_t label_size);
> +static void spapr_create_nvdimm(void *fdt)
> +{
> +int offset = fdt_subnode_offset(fdt, 0, "persistent-memory");
> +GSList *dimms = NULL;
> +
> +if (offset < 0) {
> +offset = fdt_add_subnode(fdt, 0, "persistent-memory");
> +_FDT(offset);
> +_FDT((fdt_setprop_cell(fdt, offset, "#address-cells", 0x2)));
> +_FDT((fdt_setprop_cell(fdt,

Re: [Qemu-devel] [PATCH v4 07/11] virtio: fill/flush/pop for packed ring

[Wei Xu]

On Tue, Feb 19, 2019 at 02:49:42PM +0800, Jason Wang wrote:
> 
> On 2019/2/18 下午10:46, Wei Xu wrote:
> >>Do we allow chain more descriptors than vq size in the case of indirect?
> >>According to the spec:
> >>
> >>"
> >>
> >>The device limits the number of descriptors in a list through a
> >>transport-specific and/or device-specific value. If not limited,
> >>the maximum number of descriptors in a list is the virt queue
> >>size.
> >>"
> >>
> >>This looks possible, so the above is probably wrong if the max number of
> >>chained descriptors is negotiated through a device specific way.
> >>
> >OK, I will remove this check, while it is necessary to have a limitation
> >for indirect descriptor anyway, otherwise it is possible to hit an overflow
> >since presumably u16 is used for most number/size in the spec.
> >
> 
> Please try to test block and scsi device for you changes as well.

Any idea about what kind of test should be covered? AFAICT, currently
packed ring is targeted for virtio-net as discussed during voting spec.

Wei

> 
> Thanks
> 
> 

Re: [Qemu-devel] Key repeat is no longer working on TTY and grub menu

[Gerd Hoffmann]

On Wed, Feb 13, 2019 at 07:01:35AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé  writes:
> 
> > Yes, this is another regression accidentally introduced by the keyboard
> > state tracker.
> >
> > When GTK does key repeat it omits the Up event for repeated keys.
> >
> > IOW, you get
> >
> > Press (a)
> > Press (a)
> > Press (a)
> > Release (a)
> 
> This is how keyboards commonly do it, if I remember correctly.

Yes, this is pretty much what the hardware sends, intentionally, so the
software can figure whenever the event is a autorepeat event or not.

These days most software just ignores repeated events from the hardware
and generates them in software instead, to not depend on the keyboard
hardware capabilities for autorepeat.

> > This might affect other frontends too if they use the same trick for
> > key repeat
> 
> Plausible.

UIs are not consistent here.  But, yes, we probably should just allow
down events even if the key is already in down state.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v4 06/11] virtio: get avail bytes check for packed ring

[Wei Xu]

On Tue, Feb 19, 2019 at 02:24:11PM +0800, Jason Wang wrote:
> 
> On 2019/2/19 上午1:07, Wei Xu wrote:
> >On Mon, Feb 18, 2019 at 03:27:21PM +0800, Jason Wang wrote:
> >>On 2019/2/14 下午12:26, w...@redhat.com wrote:
> >>>From: Wei Xu 
> >>>
> >>>Add packed ring headcount check.
> >>>
> >>>Common part of split/packed ring are kept.
> >>>
> >>>Signed-off-by: Wei Xu 
> >>>---
> >>>  hw/virtio/virtio.c | 197 
> >>> -
> >>>  1 file changed, 179 insertions(+), 18 deletions(-)
> >>>
> >>>diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> >>>index f2ff980..832287b 100644
> >>>--- a/hw/virtio/virtio.c
> >>>+++ b/hw/virtio/virtio.c
> >>>@@ -368,6 +368,17 @@ int virtio_queue_ready(VirtQueue *vq)
> >>>  return vq->vring.avail != 0;
> >>>  }
> >>>+static void vring_packed_desc_read(VirtIODevice *vdev, VRingPackedDesc 
> >>>*desc,
> >>>+MemoryRegionCache *cache, int i)
> >>>+{
> >>>+address_space_read_cached(cache, i * sizeof(VRingPackedDesc),
> >>>+  desc, sizeof(VRingPackedDesc));
> >>>+virtio_tswap16s(vdev, &desc->flags);
> >>>+virtio_tswap64s(vdev, &desc->addr);
> >>>+virtio_tswap32s(vdev, &desc->len);
> >>>+virtio_tswap16s(vdev, &desc->id);
> >>>+}
> >>>+
> >>>  static void vring_packed_desc_read_flags(VirtIODevice *vdev,
> >>>  VRingPackedDesc *desc, MemoryRegionCache *cache, int 
> >>> i)
> >>>  {
> >>>@@ -667,9 +678,9 @@ static int virtqueue_read_next_desc(VirtIODevice 
> >>>*vdev, VRingDesc *desc,
> >>>  return VIRTQUEUE_READ_DESC_MORE;
> >>>  }
> >>>-void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes,
> >>>-   unsigned int *out_bytes,
> >>>-   unsigned max_in_bytes, unsigned 
> >>>max_out_bytes)
> >>>+static void virtqueue_split_get_avail_bytes(VirtQueue *vq,
> >>>+unsigned int *in_bytes, unsigned int 
> >>>*out_bytes,
> >>>+unsigned max_in_bytes, unsigned max_out_bytes)
> >>>  {
> >>>  VirtIODevice *vdev = vq->vdev;
> >>>  unsigned int max, idx;
> >>>@@ -679,27 +690,12 @@ void virtqueue_get_avail_bytes(VirtQueue *vq, 
> >>>unsigned int *in_bytes,
> >>>  int64_t len = 0;
> >>>  int rc;
> >>>-if (unlikely(!vq->vring.desc)) {
> >>>-if (in_bytes) {
> >>>-*in_bytes = 0;
> >>>-}
> >>>-if (out_bytes) {
> >>>-*out_bytes = 0;
> >>>-}
> >>>-return;
> >>>-}
> >>>-
> >>>  rcu_read_lock();
> >>>  idx = vq->last_avail_idx;
> >>>  total_bufs = in_total = out_total = 0;
> >>>  max = vq->vring.num;
> >>>  caches = vring_get_region_caches(vq);
> >>>-if (caches->desc.len < max * sizeof(VRingDesc)) {
> >>>-virtio_error(vdev, "Cannot map descriptor ring");
> >>>-goto err;
> >>>-}
> >>>-
> >>>  while ((rc = virtqueue_num_heads(vq, idx)) > 0) {
> >>>  MemoryRegionCache *desc_cache = &caches->desc;
> >>>  unsigned int num_bufs;
> >>>@@ -792,6 +788,171 @@ err:
> >>>  goto done;
> >>>  }
> >>>+static void virtqueue_packed_get_avail_bytes(VirtQueue *vq,
> >>>+unsigned int *in_bytes, unsigned int 
> >>>*out_bytes,
> >>>+unsigned max_in_bytes, unsigned max_out_bytes)
> >>>+{
> >>>+VirtIODevice *vdev = vq->vdev;
> >>>+unsigned int max, idx;
> >>>+unsigned int total_bufs, in_total, out_total;
> >>>+MemoryRegionCache *desc_cache;
> >>>+VRingMemoryRegionCaches *caches;
> >>>+MemoryRegionCache indirect_desc_cache = MEMORY_REGION_CACHE_INVALID;
> >>>+int64_t len = 0;
> >>>+VRingPackedDesc desc;
> >>>+bool wrap_counter;
> >>>+
> >>>+rcu_read_lock();
> >>>+idx = vq->last_avail_idx;
> >>>+wrap_counter = vq->last_avail_wrap_counter;
> >>>+total_bufs = in_total = out_total = 0;
> >>>+
> >>>+max = vq->vring.num;
> >>>+caches = vring_get_region_caches(vq);
> >>>+desc_cache = &caches->desc;
> >>>+vring_packed_desc_read_flags(vdev, &desc, desc_cache, idx);
> >>>+while (is_desc_avail(&desc, wrap_counter)) {
> >>>+unsigned int num_bufs;
> >>>+unsigned int i = 0;
> >>>+
> >>>+num_bufs = total_bufs;
> >>>+
> >>>+/* Make sure flags has been read before all the fields. */
> >>>+smp_rmb();
> >>>+vring_packed_desc_read(vdev, &desc, desc_cache, idx);
> >>
> >>It's better to have single function to deal with reading flags and
> >>descriptors and check its availability like packed ring.
> >There is something different between split and packed ring here.
> >For split ring, 'avail_idx' and descriptor are separately used so the
> >interfaces of them are straightforward, while the flag and data fields
> >of the descriptors for packed ring are mixed and independent accesses to
> >them have been brought in, it is good to use them as what they are supposed
> >to w

Re: [Qemu-devel] [PATCH v1 0/1] Allow TAP to unnegotiate virtio-net header

[Vincenzo Maffione]

Il giorno mar 19 feb 2019 alle ore 07:48 Jason Wang 
ha scritto:

>
> On 2019/2/18 下午7:53, Vincenzo Maffione wrote:
> > Hi Jason,
> >Thanks for the quick reply.
> >
> > My PV device (to be open sourced soon) uses the QEMU net backend
> interface,
> > in a way similar to virtio-net.
> > For example it uses qemu_set_offload(), qemu_has_vnet_hdr_len(),
> > qemu_using_vnet_hdr(), qemu_send_packet(), etc.
> > This means that the device itself does not know which net backend is
> using,
> > of course.
> > In addition to TAP, also the netmap backend supports the virtio-net
> header,
> > and so the PV device will work with both.
> > Regarding the virtio-net header, the netmap backend is more flexible
> > because you can change the virtio-net header length as you wish (choosing
> > between 0, 10 and 12 bytes).
>
>
> Interesting, actually, there's case that vnet header is not used even
> for virtio-net, e.g for the case of XDP withouth csum support. If we
> don't pass vnet header in this case, we may get even higher PPS.
>

I guess in this case we simply pass a zeroed header. According to my
experience I think it's unlikely that PPS are affected by having 12
additional bytes to copy around, as long as no processing is done on the
header. I may be wrong of course.

>
>
> >
> > My problem cannot be solved by making sure that TAPs are opened without
> > IFF_VNET_HDR. What I want instead
> > is to dynamically change the length of the virtio-net header that the
> > backend accepts, switching between 12 bytes (virtio 1.0 header) and 0 (no
> > header). By "dynamically" I mean while the guest (and the device) is
> > running. This is possible and safe if we get rid of that assert().
> > The virtio-net device does not need that flexibility (once you enable the
> > vtnet header, you never disable that again), so I guess that's why you
> have
> > that assert().
> > My PV device can be reconfigured on the fly in such a way it may or not
> may
> > be aware of the virtio-net header, and as a consequence it may need to
> call
> > qemu_using_vnet_hdr() with true or false (multiple times).
> >
> > Does it make sense?
>
>
> Yes, it is. But I think maybe it's better to send this patch with your
> new PV device implementation.
>
> Sounds good, thanks.

Cheers,
  Vincenzo


> Thanks
>
>
> >
> > Cheers,
> >Vincenzo
> >
> >
> > Il giorno lun 18 feb 2019 alle ore 05:19 Jason Wang  >
> > ha scritto:
> >
> >> On 2019/2/16 上午1:46, Vincenzo Maffione wrote:
> >>> Hi,
> >>> I was doing experiments with a custom paravirtualized net device,
> >>> and I ran into a limitation of the TAP backend. I see from the kernel
> >>> code that it is not possible to set the TAP virtio-net header
> >>> length to something different from 10 or 12, which means that it
> >>> is not possible to set it to 0. That's fine.
> >>> The QEMU implementation of the TAP backend already supports
> >>> the case where virtio-net header is set to 10 or 12 in kernel,
> >>> but the emulated/paravirtualized net device is not using that:
> >>> the TAP backend will just strip/prepend a zeroed header in this case
> >>> (e.g., see the if statement in tap_receive_iov()).
> >>> However, the tap_using_vnet_hdr() has an assert() that prevents
> >>> this situation to happen, and I don't understand why. Maybe it
> >>> is a leftover? I tried to remove the assert and by doing that
> >>> my paravirtualized device was able to stop using the virtio-net
> >>> header.
> >>
> >> Hi:
> >>
> >> If  I understand this correctly, your PV device is API compatible with
> >> TAP? Then you may just adding code to call TUNSETIFF without
> IFF_VNET_HDR?
> >>
> >> Thanks
> >>
> >>
> >>> Vincenzo Maffione (1):
> >>> net: tap: allow net frontends to un-negotiate virtio-net header
> >>>
> >>>net/tap.c | 1 -
> >>>1 file changed, 1 deletion(-)
> >>>
> >
>


-- 
Vincenzo

[Qemu-devel] [PATCH 01/14] MAINTAINERS: Add some missing entries for the sun4m machine

[Thomas Huth]

These files / devices are only used by SPARC machines, so we can sort
them into the corresponding categories in the MAINTAINERS file.

Cc: Mark Cave-Ayland 
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b1d786c..7e4f70a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1082,12 +1082,15 @@ M: Mark Cave-Ayland 
 S: Maintained
 F: hw/sparc/sun4m.c
 F: hw/sparc/sun4m_iommu.c
+F: hw/display/cg3.c
+F: hw/display/tcx.c
 F: hw/dma/sparc32_dma.c
 F: hw/misc/eccmemctl.c
-F: hw/misc/slavio_misc.c
+F: hw/*/slavio_*.c
+F: include/hw/nvram/sun_nvram.h
 F: include/hw/sparc/sparc32_dma.h
-F: pc-bios/openbios-sparc32
 F: include/hw/sparc/sun4m_iommu.h
+F: pc-bios/openbios-sparc32
 
 Sun4u
 M: Mark Cave-Ayland 
-- 
1.8.3.1

[Qemu-devel] [PATCH 03/14] MAINTAINERS: Add missing entries for the PC machines

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index feb9095..2cc112c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1181,6 +1181,10 @@ F: hw/acpi/ich9.c
 F: include/hw/acpi/ich9.h
 F: include/hw/acpi/piix4.h
 F: hw/misc/sga.c
+F: hw/isa/apm.c
+F: include/hw/isa/apm.h
+F: tests/test-x86-cpuid.c
+F: tests/test-x86-cpuid-compat.c
 
 PC Chipset
 M: Michael S. Tsirkin 
-- 
1.8.3.1

[Qemu-devel] [PATCH 00/14] Various updates to the MAINTAINERS file

[Thomas Huth]

I recently noticed that we missed to include many updates to the
MAINTAINERS file that have been posted to the qemu-devel mailing
list within the last weeks. This patch series is now a collection
of these patches, with some tweaks to some of them according to
the discussions that have taken place after their initial version
has been posted.

Please have especially a look at the new patch 13 ('Allow "Odd Fixes"
with sole "L:" entries, too') to see whether that makes sense.

Jeff Cody (2):
  MAINTAINERS: Replace myself with John Snow for block jobs
  MAINTAINERS: Remove myself as block maintainer

Philippe Mathieu-Daudé (9):
  MAINTAINERS: Add missing entries for the sun4u machines
  MAINTAINERS: Add missing entries for the PC machines
  MAINTAINERS: Add missing entries for the QObject section
  MAINTAINERS: Add missing test entries to the Cryptography section
  MAINTAINERS: Add an entry for the Dino machine
  MAINTAINERS: Add maintainer to the POSIX subsystem
  MAINTAINERS: Orphanize the 'GDB stub' subsystem
  MAINTAINERS: Add maintainers to the Linux subsystem
  MAINTAINERS: Add maintainer to the TCG/i386 subsystem

Thomas Huth (3):
  MAINTAINERS: Add some missing entries for the sun4m machine
  MAINTAINERS: Clean up the RISC-V TCG backend section
  MAINTAINERS: Allow "Odd Fixes" with sole "L:" entries, too

 MAINTAINERS | 84 +
 1 file changed, 51 insertions(+), 33 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH 08/14] MAINTAINERS: Orphanize the 'GDB stub' subsystem

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Nobody is looking at those files, downgrade this subsystem as orphan.

Remove the qemu-devel@nongnu.org entry because the list is always
selected by the 'All patches CC here' section.

Suggested-by: Markus Armbruster 
Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 549f1f9..258ba5a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1811,8 +1811,7 @@ F: util/error.c
 F: util/qemu-error.c
 
 GDB stub
-L: qemu-devel@nongnu.org
-S: Odd Fixes
+S: Orphan
 F: gdbstub*
 F: gdb-xml/
 
-- 
1.8.3.1

[Qemu-devel] [PATCH 04/14] MAINTAINERS: Add missing entries for the QObject section

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Markus Armbruster 
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2cc112c..e7b4114 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1936,10 +1936,14 @@ F: include/qapi/qmp/
 X: include/qapi/qmp/dispatch.h
 F: scripts/coccinelle/qobject.cocci
 F: tests/check-qdict.c
-F: tests/check-qnum.c
 F: tests/check-qjson.c
 F: tests/check-qlist.c
+F: tests/check-qlit.c
+F: tests/check-qnull.c
+F: tests/check-qnum.c
+F: tests/check-qobject.c
 F: tests/check-qstring.c
+F: qdict-test-data.txt
 T: git https://repo.or.cz/qemu/armbru.git qapi-next
 
 QEMU Guest Agent
-- 
1.8.3.1

[Qemu-devel] [PATCH 02/14] MAINTAINERS: Add missing entries for the sun4u machines

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Reviewed-by: Mark Cave-Ayland 
Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7e4f70a..feb9095 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1096,9 +1096,13 @@ Sun4u
 M: Mark Cave-Ayland 
 S: Maintained
 F: hw/sparc64/sun4u.c
-F: pc-bios/openbios-sparc64
+F: hw/sparc64/sun4u_iommu.c
+F: include/hw/sparc/sun4u_iommu.h
 F: hw/pci-host/sabre.c
 F: include/hw/pci-host/sabre.h
+F: hw/pci-bridge/simba.c
+F: include/hw/pci-bridge/simba.h
+F: pc-bios/openbios-sparc64
 
 Sun4v
 M: Artyom Tarasenko 
-- 
1.8.3.1

[Qemu-devel] [PATCH 09/14] MAINTAINERS: Add maintainers to the Linux subsystem

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Add Michael, Cornelia and Paolo as maintainers of the Linux subsystem.

Remove the qemu-devel@nongnu.org entry because the list is always
selected by the 'All patches CC here' section.

Suggested-by: Paolo Bonzini 
Signed-off-by: Philippe Mathieu-Daudé 
Acked-by: Cornelia Huck 
[thuth: Add update-linux-headers.sh, too]
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 258ba5a..e6e08c2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -425,10 +425,12 @@ Hosts:
 --
 
 LINUX
-L: qemu-devel@nongnu.org
+M: Michael S. Tsirkin 
+M: Cornelia Huck 
+M: Paolo Bonzini 
 S: Maintained
-F: linux-*
 F: linux-headers/
+F: scripts/update-linux-headers.sh
 
 POSIX
 M: Paolo Bonzini 
-- 
1.8.3.1

[Qemu-devel] [PATCH 06/14] MAINTAINERS: Add an entry for the Dino machine

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Add Richard as maintainer, and Helge as reviewer.

Cc: Richard Henderson 
Cc: Helge Deller 
Signed-off-by: Philippe Mathieu-Daudé 
[thuth: Add the machine entry alphabetically]
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 59e4c8a..a1772d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -844,6 +844,15 @@ S: Maintained
 F: hw/cris/axis_dev88.c
 F: hw/*/etraxfs_*.c
 
+HP-PARISC Machines
+--
+Dino
+M: Richard Henderson 
+R: Helge Deller 
+S: Odd Fixes
+F: hw/hppa/
+F: pc-bios/hppa-firmware.img
+
 LM32 Machines
 -
 EVR32 and uclinux BSP
-- 
1.8.3.1

[Qemu-devel] [PATCH 11/14] MAINTAINERS: Clean up the RISC-V TCG backend section

[Thomas Huth]

The e-mail address m...@sifive.com of Micheal is not valid anymore.
Commit 7d04ac38959f8115f2a02 removed the entry already from the main
RISC-V section, but apparently forgot to remove it from the TCG
backend section, too.

Cc: Palmer Dabbelt 
Cc: Alistair Francis 
Fixes: 7d04ac38959f8115f2a029d81db1c8aac179aa95
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b00caaf..1d0dcde 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2232,7 +2232,6 @@ F: tcg/ppc/
 F: disas/ppc.c
 
 RISC-V
-M: Michael Clark 
 M: Palmer Dabbelt 
 M: Alistair Francis 
 L: qemu-ri...@nongnu.org
-- 
1.8.3.1

[Qemu-devel] [PATCH 05/14] MAINTAINERS: Add missing test entries to the Cryptography section

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Acked-by: Daniel P. Berrangé 
Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e7b4114..59e4c8a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2065,6 +2065,8 @@ F: crypto/
 F: include/crypto/
 F: tests/test-crypto-*
 F: tests/benchmark-crypto-*
+F: tests/crypto-tls-*
+F: tests/pkix_asn1_tab.c
 F: qemu.sasl
 
 Coroutines
-- 
1.8.3.1

[Qemu-devel] [PATCH 07/14] MAINTAINERS: Add maintainer to the POSIX subsystem

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Add Paolo as maintainer of the POSIX subsystem.

Remove the qemu-devel@nongnu.org entry because the list is always
selected by the 'All patches CC here' section.

Cc: Paolo Bonzini 
Suggested-by: Markus Armbruster 
Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a1772d9..549f1f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -431,9 +431,12 @@ F: linux-*
 F: linux-headers/
 
 POSIX
-L: qemu-devel@nongnu.org
+M: Paolo Bonzini 
 S: Maintained
-F: *posix*
+F: os-posix.c
+F: include/sysemu/os-posix.h
+F: util/*posix*.c
+F: include/qemu/*posix*.h
 
 NETBSD
 L: qemu-devel@nongnu.org
-- 
1.8.3.1

Re: [Qemu-devel] [RFC PATCH 06/11] qcow2: Don't assume 0 is an invalid cluster offset

[Kevin Wolf]

Am 19.02.2019 um 00:13 hat Max Reitz geschrieben:
> On 31.01.19 18:55, Kevin Wolf wrote:
> > The cluster allocation code uses 0 as an invalid offset that is used in
> > case of errors or as "offset not yet determined". With external data
> > files, a host cluster offset of 0 becomes valid, though.
> > 
> > Define a constant INV_OFFSET (which is not cluster aligned and will
> > therefore never be a valid offset) that can be used for such purposes.
> > 
> > This removes the additional host_offset == 0 check that commit
> > ff52aab2df5 introduced; the confusion between an invalid offset and
> > (erroneous) allocation at offset 0 is removed with this change.
> > 
> > Signed-off-by: Kevin Wolf 
> > ---
> >  block/qcow2.h |  2 ++
> >  block/qcow2-cluster.c | 59 ---
> >  2 files changed, 29 insertions(+), 32 deletions(-)
> 
> qcow2_get_cluster_offset() still returns 0 for unallocated clusters.
> (And qcow2_co_block_status() tests for that, so it would never report a
> valid offset for the first cluster in an externally allocated qcow2 file.)

I think the bug here is in qcow2_get_cluster_offset(). It shouldn't look
at cluster_offset, but at ret if it wants to know the allocation status.
So I think this needs to become something like:

if ((ret == QCOW2_CLUSTER_NORMAL || ret == QCOW2_CLUSTER_ZERO_ALLOC) &&
!s->crypto) {
...
}

> qcow2_alloc_compressed_cluster_offset() should return INV_OFFSET on
> error (yeah, there are no compressed clusters in external files, but
> this seems like the right thing to do still).

Ok, makes sense.

> (And there are cases like qcow2_co_preadv(), where cluster_offset is
> initialized to 0 -- it doesn't make a difference what it's initialized
> to (it's just to silence the compiler, I suppose), but it should still
> use this new constant now.  I think.)

I don't think I would change places where cluster_offset is never used
at all or never used alone without checking the cluster type, too.

qcow2_get_cluster_offset() still returns 0 for unallocated and
non-preallocated zero clusters, and I think that's fine because it also
returns the cluster type, which is information about whether the offset
is even valid.

In theory, it shouldn't matter at all if we return 0, INV_OFFSET or 42
there, but in practice I'd bet neither money nor production images on
this. If it ain't broke, don't fix it.

Kevin


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH 10/14] MAINTAINERS: Add maintainer to the TCG/i386 subsystem

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Richard obviously maintains this subdirectory, make this official :)

Remove the qemu-devel@nongnu.org entry because the list is always
selected by the 'All patches CC here' section.

Cc: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e6e08c2..b00caaf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2213,7 +2213,7 @@ F: tcg/arm/
 F: disas/arm.c
 
 i386 target
-L: qemu-devel@nongnu.org
+M: Richard Henderson 
 S: Maintained
 F: tcg/i386/
 F: disas/i386.c
-- 
1.8.3.1

Re: [Qemu-devel] nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2

[Gerd Hoffmann]

  Hi,

> (2) If I change the cmdline to "lun=5", then the exchange is:

Not supported (by the usb protocol).

The protocol has a control message to query the number of devices (grep
for GetMaxLun in qemu).  LUNs are not allowed to be sparse.  So, with a
single storage device the LUN must be zero.  With two devices the LUNs
must be 0,1, with three 0,1,2 etc., you get the idea :)

Maybe usb-bot should check for that and throw an error, I think right
now we only have the generic scsi code check which will verify the lun
isn't too big (<= 15) but will not check the non-sparse requirement.

cheers,
  Gerd

[Qemu-devel] [PATCH 0/5] QEMU VFIO live migration

[Yan Zhao]

This patchset enables VFIO devices to have live migration capability.
Currently it does not support post-copy phase.

It follows Alex's comments on last version of VFIO live migration patches,
including device states, VFIO device state region layout, dirty bitmap's
query.

Device Data
---
Device data is divided into three types: device memory, device config,
and system memory dirty pages produced by device.

Device config: data like MMIOs, page tables...
Every device is supposed to possess device config data.
Usually device config's size is small (no big than 10M), and it
needs to be loaded in certain strict order.
Therefore, device config only needs to be saved/loaded in
stop-and-copy phase.
The data of device config is held in device config region.
Size of device config data is smaller than or equal to that of
device config region.

Device Memory: device's internal memory, standalone and outside system
memory. It is usually very big.
This kind of data needs to be saved / loaded in pre-copy and
stop-and-copy phase.
The data of device memory is held in device memory region.
Size of devie memory is usually larger than that of device
memory region. qemu needs to save/load it in chunks of size of
device memory region.
Not all device has device memory. Like IGD only uses system memory.

System memory dirty pages: If a device produces dirty pages in system
memory, it is able to get dirty bitmap for certain range of system
memory. This dirty bitmap is queried in pre-copy and stop-and-copy
phase in .log_sync callback. By setting dirty bitmap in .log_sync
callback, dirty pages in system memory will be save/loaded by ram's
live migration code.
The dirty bitmap of system memory is held in dirty bitmap region.
If system memory range is larger than that dirty bitmap region can
hold, qemu will cut it into several chunks and get dirty bitmap in
succession.


Device State Regions

Vendor driver is required to expose two mandatory regions and another two
optional regions if it plans to support device state management.

So, there are up to four regions in total.
One control region: mandatory.
Get access via read/write system call.
Its layout is defined in struct vfio_device_state_ctl
Three data regions: mmaped into qemu.
device config region: mandatory, holding data of device config
device memory region: optional, holding data of device memory
dirty bitmap region: optional, holding bitmap of system memory
dirty pages

(The reason why four seperate regions are defined is that the unit of mmap
system call is PAGE_SIZE, i.e. 4k bytes. So one read/write region for
control and three mmaped regions for data seems better than one big region
padded and sparse mmaped).


kernel device state interface [1]
--
#define VFIO_DEVICE_STATE_INTERFACE_VERSION 1
#define VFIO_DEVICE_DATA_CAP_DEVICE_MEMORY 1
#define VFIO_DEVICE_DATA_CAP_SYSTEM_MEMORY 2

#define VFIO_DEVICE_STATE_RUNNING 0 
#define VFIO_DEVICE_STATE_STOP 1
#define VFIO_DEVICE_STATE_LOGGING 2

#define VFIO_DEVICE_DATA_ACTION_GET_BUFFER 1
#define VFIO_DEVICE_DATA_ACTION_SET_BUFFER 2
#define VFIO_DEVICE_DATA_ACTION_GET_BITMAP 3

struct vfio_device_state_ctl {
__u32 version;/* ro */
__u32 device_state;   /* VFIO device state, wo */
__u32 caps;  /* ro */
struct {
__u32 action;  /* wo, GET_BUFFER or SET_BUFFER */ 
__u64 size;/*rw*/
} device_config;
struct {
__u32 action;/* wo, GET_BUFFER or SET_BUFFER */ 
__u64 size; /* rw */  
__u64 pos; /*the offset in total buffer of device memory*/
} device_memory;
struct {
__u64 start_addr; /* wo */
__u64 page_nr;   /* wo */
} system_memory;
};

Devcie States
- 
After migration is initialzed, it will set device state via writing to
device_state field of control region.

Four states are defined for a VFIO device:
RUNNING, RUNNING & LOGGING, STOP & LOGGING, STOP 

RUNNING: In this state, a VFIO device is in active state ready to receive
commands from device driver.
It is the default state that a VFIO device enters initially.

STOP:  In this state, a VFIO device is deactivated to interact with
   device driver.

LOGGING: a special state that it CANNOT exist independently. It must be
   set alongside with state RUNNING or STOP (i.e. RUNNING & LOGGING,
   STOP & LOGGING).
   Qemu will set LOGGING state on in .save_setup callbacks, then vendor
   driver can start dirty data logging for device memory and system
   memory.
   LOGGING only impact

Re: [Qemu-devel] [PATCH 10/10] hw/arm hw/xtensa: De-duplicate pflash creation code some

[Max Filippov]

On Mon, Feb 18, 2019 at 5:07 AM Markus Armbruster  wrote:
>
> pflash_cfi01_register() creates a TYPE_CFI_PFLASH01 device, sets
> properties, realizes, and wires up.
>
> We have three modified copies of it, because their users need to set
> additional properties, or have the wiring done differently.
>
> Factor out their common part into pflash_cfi01_create().
>
> Signed-off-by: Markus Armbruster 
> ---
>  hw/arm/vexpress.c| 22 +-
>  hw/arm/virt.c| 26 +-
>  hw/block/pflash_cfi01.c  | 39 +++
>  hw/xtensa/xtfpga.c   | 18 +++---

I was told that it's better this way when I did that initially:
  http://lists.gnu.org/archive/html/qemu-devel/2015-09/msg06927.html

Has the idea of "better" changed since then?
I'm fine with the code either way, just curious.

-- 
Thanks.
-- Max

[Qemu-devel] [PATCH 3/5] vfio/migration: tracking of dirty page in system memory

[Yan Zhao]

register the log_sync interface to hook into ram's live migration
callbacks.

ram_save_pending
   |->migration_bitmap_sync
   |->memory_global_dirty_log_sync
   |->memory_region_sync_dirty_bitmap
   |->listener->log_sync(listener, &mrs);

So, the dirty page produced by vfio device in system memory will be
save/load by ram's live migration code iteratively.

Bitmap of device's dirty page in system memory is retrieved from Dirty Bitmap
Region

Signed-off-by: Yan Zhao 
Signed-off-by: Yulei Zhang 
---
 hw/vfio/common.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 7c185e5a..719e750 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -27,6 +27,7 @@
 
 #include "hw/vfio/vfio-common.h"
 #include "hw/vfio/vfio.h"
+#include "hw/vfio/pci.h"
 #include "exec/address-spaces.h"
 #include "exec/memory.h"
 #include "hw/hw.h"
@@ -698,9 +699,34 @@ static void vfio_listener_region_del(MemoryListener 
*listener,
 }
 }
 
+static void vfio_log_sync(MemoryListener *listener,
+  MemoryRegionSection *section)
+{
+VFIOContainer *container = container_of(listener, VFIOContainer, listener);
+VFIOGroup *group = QLIST_FIRST(&container->group_list);
+VFIODevice *vbasedev;
+VFIOPCIDevice *vdev;
+
+ram_addr_t size = int128_get64(section->size);
+uint64_t page_nr = size >> TARGET_PAGE_BITS;
+uint64_t start_addr = section->offset_within_address_space;
+
+QLIST_FOREACH(vbasedev, &group->device_list, next) {
+vdev = container_of(vbasedev, VFIOPCIDevice, vbasedev);
+if (!vdev->migration ||
+!vfio_device_data_cap_system_memory(vdev) ||
+!(vdev->migration->device_state & VFIO_DEVICE_STATE_LOGGING)) {
+continue;
+}
+
+vfio_set_dirty_page_bitmap(vdev, start_addr, page_nr);
+}
+}
+
 static const MemoryListener vfio_memory_listener = {
 .region_add = vfio_listener_region_add,
 .region_del = vfio_listener_region_del,
+.log_sync = vfio_log_sync,
 };
 
 static void vfio_listener_release(VFIOContainer *container)
-- 
2.7.4

[Qemu-devel] [PATCH 1/5] vfio/migration: define kernel interfaces

[Yan Zhao]

- defined 4 device states regions: one control region and 3 data regions
- defined layout of control region in struct vfio_device_state_ctl
- defined 4 device states: running, stop, running&logging, stop&logging
- define 3 device data categories: device config, device memory, system
  memory
- defined 2 device data capabilities: device memory and system memory
- defined device state interfaces' version and 12 device state interfaces

Signed-off-by: Yan Zhao 
Signed-off-by: Kevin Tian 
Signed-off-by: Yulei Zhang 
---
 linux-headers/linux/vfio.h | 260 +
 1 file changed, 260 insertions(+)

diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index ceb6453..a124fc1 100644
--- a/linux-headers/linux/vfio.h
+++ b/linux-headers/linux/vfio.h
@@ -303,6 +303,56 @@ struct vfio_region_info_cap_type {
 #define VFIO_REGION_SUBTYPE_INTEL_IGD_HOST_CFG (2)
 #define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG  (3)
 
+/* Device State region type and sub-type
+ *
+ * A VFIO device driver needs to register up to four device state regions in
+ * total: two mandatory and another two optional, if it plans to support device
+ * state management.
+ *
+ * 1. region CTL :
+ *  Mandatory.
+ *  This is a control region.
+ *  Its layout is defined in struct vfio_device_state_ctl.
+ *  Reading from this region can get version, capabilities and data
+ *  size of device state interfaces.
+ *  Writing to this region can set device state, data size and
+ *  choose which interface to use.
+ * 2. region DEVICE_CONFIG
+ *  Mandatory.
+ *  This is a data region that holds device config data.
+ *  Device config is such kind of data like MMIOs, page tables...
+ *  Every device is supposed to possess device config data.
+ *  Usually the size of device config data is small (no big
+ *  than 10M), and it needs to be loaded in certain strict
+ *  order.
+ *  Therefore no dirty data logging is enabled for device
+ *  config and it must be got/set as a whole.
+ *  Size of device config data is smaller than or equal to that of
+ *  device config region.
+ *  It is able to be mmaped into user space.
+ * 3. region DEVICE_MEMORY
+ *  Optional.
+ *  This is a data region that holds device memory data.
+ *  Device memory is device's internal memory, standalone and outside
+ *  system memory.  It is usually very big.
+ *  Not all device has device memory. Like IGD only uses system
+ *  memory and has no device memory.
+ *  Size of devie memory is usually larger than that of device
+ *  memory region. qemu needs to save/load it in chunks of size of
+ *  device memory region.
+ *  It is able to be mmaped into user space.
+ * 4. region DIRTY_BITMAP
+ *  Optional.
+ *  This is a data region that holds bitmap of dirty pages in system
+ *  memory that a VFIO devices produces.
+ *  It is able to be mmaped into user space.
+ */
+#define VFIO_REGION_TYPE_DEVICE_STATE   (1 << 1)
+#define VFIO_REGION_SUBTYPE_DEVICE_STATE_CTL   (1)
+#define VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_CONFIG  (2)
+#define VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_MEMORY  (3)
+#define VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_DIRTYBITMAP (4)
+
 /*
  * The MSIX mappable capability informs that MSIX data of a BAR can be mmapped
  * which allows direct access to non-MSIX registers which happened to be within
@@ -816,6 +866,216 @@ struct vfio_iommu_spapr_tce_remove {
 };
 #define VFIO_IOMMU_SPAPR_TCE_REMOVE_IO(VFIO_TYPE, VFIO_BASE + 20)
 
+/* version number of the device state interface */
+#define VFIO_DEVICE_STATE_INTERFACE_VERSION 1
+
+/*
+ * For devices that have devcie memory, it is required to expose
+ * DEVICE_MEMORY capability.
+ *
+ * For devices producing dirty pages in system memory, it is required to
+ * expose cap SYSTEM_MEMORY in order to get dirty bitmap in certain range
+ * of system memory.
+ */
+#define VFIO_DEVICE_DATA_CAP_DEVICE_MEMORY 1
+#define VFIO_DEVICE_DATA_CAP_SYSTEM_MEMORY 2
+
+/*
+ * DEVICE STATES
+ *
+ * Four states are defined for a VFIO device:
+ * RUNNING, RUNNING & LOGGING, STOP & LOGGING, STOP.
+ * They can be set by writing to device_state field of
+ * vfio_device_state_ctl region.
+ *
+ * RUNNING: In this state, a VFIO device is in active state ready to
+ * receive commands from device driver.
+ * It is the default state that a VFIO device enters initially.
+ *
+ * STOP: In this state, a VFIO device is deactivated to interact with
+ * device driver.
+ *
+ * LOGGING state is a special state that it CANNOT exist
+ * independently.
+ * It must be set alongside with state RUNNING or STOP, i.e,
+ * RUNNING & LOGGING, STOP & LOGGING.
+ * It is used for dirty data logging both for device memory
+ * and system memory.
+ *
+ * LOGGING only impact

Re: [Qemu-devel] [RFC PATCH 08/11] qcow2: Add basic data-file infrastructure

[Kevin Wolf]

Am 19.02.2019 um 00:57 hat Max Reitz geschrieben:
> On 31.01.19 18:55, Kevin Wolf wrote:
> > This adds a .bdrv_open option to specify the external data file node.
> > 
> > Signed-off-by: Kevin Wolf 
> > ---
> >  qapi/block-core.json |  3 ++-
> >  block/qcow2.h|  4 +++-
> >  block/qcow2.c| 25 +++--
> >  3 files changed, 28 insertions(+), 4 deletions(-)
> 
> [...]
> 
> > diff --git a/block/qcow2.h b/block/qcow2.h
> > index c161970882..e2114900b4 100644
> > --- a/block/qcow2.h
> > +++ b/block/qcow2.h
> 
> [...]
> 
> > @@ -205,7 +206,8 @@ enum {
> >  QCOW2_INCOMPAT_DATA_FILE= 1 << QCOW2_INCOMPAT_DATA_FILE_BITNR,
> >  
> >  QCOW2_INCOMPAT_MASK  = QCOW2_INCOMPAT_DIRTY
> > - | QCOW2_INCOMPAT_CORRUPT,
> > + | QCOW2_INCOMPAT_CORRUPT
> > + | QCOW2_INCOMPAT_DATA_FILE,
> 
> This hunk seems to belong somewhere else.

Isn't this the first patch that actually allows opening images that have
QCOW2_INCOMPAT_DATA_FILE set in their header?

> >  };
> >  
> >  /* Compatible feature bits */
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index ac9934b3ed..376232d3f0 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -1441,8 +1441,22 @@ static int coroutine_fn 
> > qcow2_do_open(BlockDriverState *bs, QDict *options,
> >  goto fail;
> >  }
> >  
> > -/* TODO Open external data file */
> > -s->data_file = bs->file;
> > +/* Open external data file */
> > +if (s->incompatible_features & QCOW2_INCOMPAT_DATA_FILE) {
> > +s->data_file = bdrv_open_child(NULL, options, "data-file", bs,
> > +   &child_file, false, errp);
> > +if (!s->data_file) {
> > +ret = -EINVAL;
> > +goto fail;
> > +}
> > +} else if (qdict_get(options, QCOW2_OPT_DATA_FILE)) {
> 
> I get the idea, but this isn't crumpled so this key may not exist (but
> data-file.driver and data-file.filename may).  Of course the fact that
> these options remain unused will be caught by the block layer, but that
> makes the error message below a bit less useful.

Hmm, good point... So you'd just leave out the check and always let the
block layer complain (with a less than helpful message)? Or are you
suggesting I should try and catch all cases somehow, even if that makes
things quite a bit more complicated?

Kevin


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH 5/5] vfio/migration: support device memory capability

[Yan Zhao]

If a device has device memory capability, save/load data from device memory
in pre-copy and stop-and-copy phases.

LOGGING state is set for device memory for dirty page logging:
in LOGGING state, get device memory returns whole device memory snapshot;
outside LOGGING state, get device memory returns dirty data since last get
operation.

Usually, device memory is very big, qemu needs to chunk it into several
pieces each with size of device memory region.

Signed-off-by: Yan Zhao 
Signed-off-by: Kirti Wankhede 
---
 hw/vfio/migration.c | 235 ++--
 hw/vfio/pci.h   |   1 +
 2 files changed, 231 insertions(+), 5 deletions(-)

diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index 16d6395..f1e9309 100644
--- a/hw/vfio/migration.c
+++ b/hw/vfio/migration.c
@@ -203,6 +203,201 @@ static int vfio_load_data_device_config(VFIOPCIDevice 
*vdev,
 return 0;
 }
 
+static int vfio_get_device_memory_size(VFIOPCIDevice *vdev)
+{
+VFIODevice *vbasedev = &vdev->vbasedev;
+VFIORegion *region_ctl =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
+uint64_t len;
+int sz;
+
+sz = sizeof(len);
+if (pread(vbasedev->fd, &len, sz,
+region_ctl->fd_offset +
+offsetof(struct vfio_device_state_ctl, device_memory.size))
+!= sz) {
+error_report("vfio: Failed to get length of device memory");
+return -1;
+}
+vdev->migration->devmem_size = len;
+return 0;
+}
+
+static int vfio_set_device_memory_size(VFIOPCIDevice *vdev, uint64_t size)
+{
+VFIODevice *vbasedev = &vdev->vbasedev;
+VFIORegion *region_ctl =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
+int sz;
+
+sz = sizeof(size);
+if (pwrite(vbasedev->fd, &size, sz,
+region_ctl->fd_offset +
+offsetof(struct vfio_device_state_ctl, device_memory.size))
+!= sz) {
+error_report("vfio: Failed to set length of device comemory");
+return -1;
+}
+vdev->migration->devmem_size = size;
+return 0;
+}
+
+static
+int vfio_save_data_device_memory_chunk(VFIOPCIDevice *vdev, QEMUFile *f,
+uint64_t pos, uint64_t len)
+{
+VFIODevice *vbasedev = &vdev->vbasedev;
+VFIORegion *region_ctl =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
+VFIORegion *region_devmem =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_DATA_DEVICE_MEMORY];
+void *dest;
+uint32_t sz;
+uint8_t *buf = NULL;
+uint32_t action = VFIO_DEVICE_DATA_ACTION_GET_BUFFER;
+
+if (len > region_devmem->size) {
+return -1;
+}
+
+sz = sizeof(pos);
+if (pwrite(vbasedev->fd, &pos, sz,
+region_ctl->fd_offset +
+offsetof(struct vfio_device_state_ctl, device_memory.pos))
+!= sz) {
+error_report("vfio: Failed to set save buffer pos");
+return -1;
+}
+sz = sizeof(action);
+if (pwrite(vbasedev->fd, &action, sz,
+region_ctl->fd_offset +
+offsetof(struct vfio_device_state_ctl, device_memory.action))
+!= sz) {
+error_report("vfio: Failed to set save buffer action");
+return -1;
+}
+
+if (!vfio_device_state_region_mmaped(region_devmem)) {
+buf = g_malloc(len);
+if (buf == NULL) {
+error_report("vfio: Failed to allocate memory for migrate");
+return -1;
+}
+if (pread(vbasedev->fd, buf, len, region_devmem->fd_offset) != len) {
+error_report("vfio: error load device memory buffer");
+return -1;
+}
+qemu_put_be64(f, len);
+qemu_put_be64(f, pos);
+qemu_put_buffer(f, buf, len);
+g_free(buf);
+} else {
+dest = region_devmem->mmaps[0].mmap;
+qemu_put_be64(f, len);
+qemu_put_be64(f, pos);
+qemu_put_buffer(f, dest, len);
+}
+return 0;
+}
+
+static int vfio_save_data_device_memory(VFIOPCIDevice *vdev, QEMUFile *f)
+{
+VFIORegion *region_devmem =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_DATA_DEVICE_MEMORY];
+uint64_t total_len = vdev->migration->devmem_size;
+uint64_t pos = 0;
+
+qemu_put_be64(f, total_len);
+while (pos < total_len) {
+uint64_t len = region_devmem->size;
+
+if (pos + len >= total_len) {
+len = total_len - pos;
+}
+if (vfio_save_data_device_memory_chunk(vdev, f, pos, len)) {
+return -1;
+}
+}
+
+return 0;
+}
+
+static
+int vfio_load_data_device_memory_chunk(VFIOPCIDevice *vdev, QEMUFile *f,
+uint64_t pos, uint64_t len)
+{
+VFIODevice *vbasedev = &vdev->vbasedev;
+VFIORegion *region_ctl =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
+VFIORegion *region_devmem =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_DATA_DEVICE_

Re: [Qemu-devel] [PATCH v6 09/18] hw/arm/virt: Implement kvm_type function for 4.0 machine

[Auger Eric]

Hi Igor,

On 2/19/19 8:49 AM, Igor Mammedov wrote:
> On Mon, 18 Feb 2019 22:29:40 +0100
> Auger Eric  wrote:
> 
>> Hi Peter,
>>
>> On 2/14/19 6:29 PM, Peter Maydell wrote:
>>> On Tue, 5 Feb 2019 at 17:33, Eric Auger  wrote:  

 This patch implements the machine class kvm_type() callback.
 It returns the max IPA shift needed to implement the whole GPA
 range including the RAM and IO regions located beyond.
 The returned value in passed though the KVM_CREATE_VM ioctl and
 this allows KVM to set the stage2 tables dynamically.

 At this stage the RAM limit still is limited to 255GB.

 Setting all the existing highmem IO regions beyond the RAM
 allows to have a single contiguous RAM region (initial RAM and
 possible hotpluggable device memory). That way we do not need
 to do invasive changes in the EDK2 FW to support a dynamic
 RAM base.

 Signed-off-by: Eric Auger 

 ---

 v5 -> v6:
 - add some comments
 - high IO region cannot start before 256GiB
 ---
  hw/arm/virt.c | 52 +--
  include/hw/arm/virt.h |  2 ++
  2 files changed, 52 insertions(+), 2 deletions(-)

 diff --git a/hw/arm/virt.c b/hw/arm/virt.c
 index 2b15839d0b..b90ffc2e5d 100644
 --- a/hw/arm/virt.c
 +++ b/hw/arm/virt.c
 @@ -1366,6 +1366,7 @@ static uint64_t 
 virt_cpu_mp_affinity(VirtMachineState *vms, int idx)

  static void virt_set_memmap(VirtMachineState *vms)
  {
 +MachineState *ms = MACHINE(vms);
  hwaddr base;
  int i;

 @@ -1375,7 +1376,17 @@ static void virt_set_memmap(VirtMachineState *vms)
  vms->memmap[i] = a15memmap[i];
  }

 -vms->high_io_base = 256 * GiB; /* Top of the legacy initial RAM 
 region */
 +/*
 + * We now compute the base of the high IO region depending on the
 + * amount of initial and device memory. The device memory start/size
 + * is aligned on 1GiB. We never put the high IO region below 256GiB
 + * so that if maxram_size is < 255GiB we keep the legacy memory map
 + */
 +vms->high_io_base = ROUND_UP(GiB + ms->ram_size, GiB) +
 +ROUND_UP(ms->maxram_size - ms->ram_size, GiB);  
>>>
>>> I don't understand this expression...  
>> My intent was to align the start of the device memory on a GiB boundary,
>> just after the initial RAM (ram_size). And then align the floating IO
>> region on a GiB boundary after the device memory (of size
>> ms->maxram_size - ms->ram_size). What do I miss?
> 
> It's not obvious what "GiB +  ms->ram_size" means and where it comes from,
I agree
> maybe substitute GiB with properly named constant/macro that's also re-used in
> memmap definition so it would be obvious that's it's where initial RAM
> is mapped. Also I'd move both ROUND_UPs into separate expressions using
> reasonable named local vars and possible overflow checks on top of that,
> so one won't have to guess that it's initial RAM end + device RAM end.
Makes sense too.

Thanks

Eric
> 
>>>   
 +if (vms->high_io_base < 256 * GiB) {
 +vms->high_io_base = 256 * GiB;
 +}
  base = vms->high_io_base;

  for (i = VIRT_LOWMEMMAP_LAST; i < ARRAY_SIZE(extended_memmap); i++) {
 @@ -1386,6 +1397,7 @@ static void virt_set_memmap(VirtMachineState *vms)
  vms->memmap[i].size = size;
  base += size;
  }
 +vms->highest_gpa = base - 1;
  }

  static void machvirt_init(MachineState *machine)
 @@ -1402,7 +1414,9 @@ static void machvirt_init(MachineState *machine)
  bool firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
  bool aarch64 = true;

 -virt_set_memmap(vms);
 +if (!vms->extended_memmap) {
 +virt_set_memmap(vms);
 +}

  /* We can probe only here because during property set
   * KVM is not available yet
 @@ -1784,6 +1798,36 @@ static HotplugHandler 
 *virt_machine_get_hotplug_handler(MachineState *machine,
  return NULL;
  }

 +/*
 + * for arm64 kvm_type [7-0] encodes the IPA size shift
 + */
 +static int virt_kvm_type(MachineState *ms, const char *type_str)
 +{
 +VirtMachineState *vms = VIRT_MACHINE(ms);
 +int max_vm_phys_shift = kvm_arm_get_max_vm_phys_shift(ms);
 +int max_pa_shift;
 +
 +vms->extended_memmap = true;
 +
 +virt_set_memmap(vms);
 +
 +max_pa_shift = 64 - clz64(vms->highest_gpa);
 +
 +if (max_pa_shift > max_vm_phys_shift) {
 +error_report("-m and ,maxmem option values "
 + "require an IPA range (%d bits) larger than "
 + "the one supported by the host (%d bits)",
 + max_pa_shift, max_vm_phys_shift);
 +   e

[Qemu-devel] [PATCH 4/5] vfio/migration: turn on migration

[Yan Zhao]

init vfio migration in vfio_realize() and register migraton blocker if
failure met.
finalize all migration resources when vfio_instance_finalize().

Signed-off-by: Yan Zhao 
Signed-off-by: Yulei Zhang 
---
 hw/vfio/pci.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index b8e006b..8bf625e 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3068,6 +3068,8 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
 goto out_teardown;
 }
 
+vfio_migration_init(vdev, errp);
+
 vfio_register_err_notifier(vdev);
 vfio_register_req_notifier(vdev);
 vfio_setup_resetfn_quirk(vdev);
@@ -3089,6 +3091,7 @@ static void vfio_instance_finalize(Object *obj)
 
 vfio_display_finalize(vdev);
 vfio_bars_finalize(vdev);
+vfio_migration_finalize(vdev);
 g_free(vdev->emulated_config_bits);
 g_free(vdev->rom);
 /*
@@ -3221,11 +3224,6 @@ static Property vfio_pci_dev_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
-static const VMStateDescription vfio_pci_vmstate = {
-.name = "vfio-pci",
-.unmigratable = 1,
-};
-
 static void vfio_pci_dev_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -3233,7 +3231,6 @@ static void vfio_pci_dev_class_init(ObjectClass *klass, 
void *data)
 
 dc->reset = vfio_pci_reset;
 dc->props = vfio_pci_dev_properties;
-dc->vmsd = &vfio_pci_vmstate;
 dc->desc = "VFIO-based PCI device assignment";
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
 pdc->realize = vfio_realize;
-- 
2.7.4

[Qemu-devel] [PATCH 2/5] vfio/migration: support device of device config capability

[Yan Zhao]

Device config is the default data that every device should have. so
device config capability is by default on, no need to set.

- Currently two type of resources are saved/loaded for device of device
  config capability:
  General PCI config data, and Device config data.
  They are copies as a whole when precopy is stopped.

Migration setup flow:
- Setup device state regions, check its device state version and capabilities.
  Mmap Device Config Region and Dirty Bitmap Region, if available.
- If device state regions are failed to get setup, a migration blocker is
  registered instead.
- Added SaveVMHandlers to register device state save/load handlers.
- Register VM state change handler to set device's running/stop states.
- On migration startup on source machine, set device's state to
  VFIO_DEVICE_STATE_LOGGING

Signed-off-by: Yan Zhao 
Signed-off-by: Yulei Zhang 
---
 hw/vfio/Makefile.objs |   2 +-
 hw/vfio/migration.c   | 633 ++
 hw/vfio/pci.c |   1 -
 hw/vfio/pci.h |  25 +-
 include/hw/vfio/vfio-common.h |   1 +
 5 files changed, 659 insertions(+), 3 deletions(-)
 create mode 100644 hw/vfio/migration.c

diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
index 8b3f664..f32ff19 100644
--- a/hw/vfio/Makefile.objs
+++ b/hw/vfio/Makefile.objs
@@ -1,6 +1,6 @@
 ifeq ($(CONFIG_LINUX), y)
 obj-$(CONFIG_SOFTMMU) += common.o
-obj-$(CONFIG_PCI) += pci.o pci-quirks.o display.o
+obj-$(CONFIG_PCI) += pci.o pci-quirks.o display.o migration.o
 obj-$(CONFIG_VFIO_CCW) += ccw.o
 obj-$(CONFIG_SOFTMMU) += platform.o
 obj-$(CONFIG_VFIO_XGMAC) += calxeda-xgmac.o
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
new file mode 100644
index 000..16d6395
--- /dev/null
+++ b/hw/vfio/migration.c
@@ -0,0 +1,633 @@
+#include "qemu/osdep.h"
+
+#include "hw/vfio/vfio-common.h"
+#include "migration/blocker.h"
+#include "migration/register.h"
+#include "qapi/error.h"
+#include "pci.h"
+#include "sysemu/kvm.h"
+#include "exec/ram_addr.h"
+
+#define VFIO_SAVE_FLAG_SETUP 0
+#define VFIO_SAVE_FLAG_PCI 1
+#define VFIO_SAVE_FLAG_DEVCONFIG 2
+#define VFIO_SAVE_FLAG_DEVMEMORY 4
+#define VFIO_SAVE_FLAG_CONTINUE 8
+
+static int vfio_device_state_region_setup(VFIOPCIDevice *vdev,
+VFIORegion *region, uint32_t subtype, const char *name)
+{
+VFIODevice *vbasedev = &vdev->vbasedev;
+struct vfio_region_info *info;
+int ret;
+
+ret = vfio_get_dev_region_info(vbasedev, VFIO_REGION_TYPE_DEVICE_STATE,
+subtype, &info);
+if (ret) {
+error_report("Failed to get info of region %s", name);
+return ret;
+}
+
+if (vfio_region_setup(OBJECT(vdev), vbasedev,
+region, info->index, name)) {
+error_report("Failed to setup migrtion region %s", name);
+return ret;
+}
+
+if (vfio_region_mmap(region)) {
+error_report("Failed to mmap migrtion region %s", name);
+}
+
+return 0;
+}
+
+bool vfio_device_data_cap_system_memory(VFIOPCIDevice *vdev)
+{
+   return !!(vdev->migration->data_caps & VFIO_DEVICE_DATA_CAP_SYSTEM_MEMORY);
+}
+
+bool vfio_device_data_cap_device_memory(VFIOPCIDevice *vdev)
+{
+   return !!(vdev->migration->data_caps & VFIO_DEVICE_DATA_CAP_DEVICE_MEMORY);
+}
+
+static bool vfio_device_state_region_mmaped(VFIORegion *region)
+{
+bool mmaped = true;
+if (region->nr_mmaps != 1 || region->mmaps[0].offset ||
+(region->size != region->mmaps[0].size) ||
+(region->mmaps[0].mmap == NULL)) {
+mmaped = false;
+}
+
+return mmaped;
+}
+
+static int vfio_get_device_config_size(VFIOPCIDevice *vdev)
+{
+VFIODevice *vbasedev = &vdev->vbasedev;
+VFIORegion *region_ctl =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
+VFIORegion *region_config =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_DATA_CONFIG];
+uint64_t len;
+int sz;
+
+sz = sizeof(len);
+if (pread(vbasedev->fd, &len, sz,
+region_ctl->fd_offset +
+offsetof(struct vfio_device_state_ctl, device_config.size))
+!= sz) {
+error_report("vfio: Failed to get length of device config");
+return -1;
+}
+if (len > region_config->size) {
+error_report("vfio: Error device config length");
+return -1;
+}
+vdev->migration->devconfig_size = len;
+
+return 0;
+}
+
+static int vfio_set_device_config_size(VFIOPCIDevice *vdev, uint64_t size)
+{
+VFIODevice *vbasedev = &vdev->vbasedev;
+VFIORegion *region_ctl =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
+VFIORegion *region_config =
+&vdev->migration->region[VFIO_DEVSTATE_REGION_DATA_CONFIG];
+int sz;
+
+if (size > region_config->size) {
+return -1;
+}
+
+sz = sizeof(size);
+if (pwrite(vbasedev->fd, &size, sz,
+region_ctl->fd_offset +
+offsetof(struct vfio_device_state_ctl, device_con

Re: [Qemu-devel] nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2

[Laszlo Ersek]

On 02/19/19 09:49, Gerd Hoffmann wrote:
>   Hi,
> 
>> (2) If I change the cmdline to "lun=5", then the exchange is:
> 
> Not supported (by the usb protocol).
> 
> The protocol has a control message to query the number of devices (grep
> for GetMaxLun in qemu).  LUNs are not allowed to be sparse.  So, with a
> single storage device the LUN must be zero.  With two devices the LUNs
> must be 0,1, with three 0,1,2 etc., you get the idea :)

Yes, Phil explained the same -- I originally missed this part of the
documentation (because the requirement is documented, so the fault is
clearly mine).

However, once I fixed the configuration (so that I'd have LUNs 0 and 1),
edk2 still tripped an assert. Please see my message elsewhere in this
thread; the fixed config case is marked as item (4).

Thanks!
Laszlo

> Maybe usb-bot should check for that and throw an error, I think right
> now we only have the generic scsi code check which will verify the lun
> isn't too big (<= 15) but will not check the non-sparse requirement.
> 
> cheers,
>   Gerd
> 

Re: [Qemu-devel] [RFC PATCH 10/11] qcow2: Store data file name in the image

[Kevin Wolf]

Am 19.02.2019 um 01:18 hat Max Reitz geschrieben:
> On 31.01.19 18:55, Kevin Wolf wrote:
> > Rather than requiring that the external data file node is passed
> > explicitly when creating the qcow2 node, store the filename in the
> > designated header extension during .bdrv_create and read it from there
> > as a default during .bdrv_open.
> > 
> > Signed-off-by: Kevin Wolf 
> > ---
> >  block/qcow2.h  |  1 +
> >  block/qcow2.c  | 69 +-
> >  tests/qemu-iotests/082.out | 27 +++
> >  3 files changed, 96 insertions(+), 1 deletion(-)
> 
> [...]
> 
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index 6cf862e8b9..4959bf16a4 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -398,6 +398,20 @@ static int qcow2_read_extensions(BlockDriverState *bs, 
> > uint64_t start_offset,
> >  #endif
> >  break;
> >  
> > +case QCOW2_EXT_MAGIC_DATA_FILE:
> > +{
> > +s->image_data_file = g_malloc0(ext.len + 1);
> > +ret = bdrv_pread(bs->file, offset, s->image_data_file, 
> > ext.len);
> > +if (ret < 0) {
> > +error_setg_errno(errp, -ret, "ERROR: Could not data file 
> > name");
> 
> I think you accidentally a word.
> 
> > +return ret;
> > +}
> > +#ifdef DEBUG_EXT
> > +printf("Qcow2: Got external data file %s\n", 
> > s->image_data_file);
> > +#endif
> > +break;
> > +}
> > +
> >  default:
> >  /* unknown magic - save it in case we need to rewrite the 
> > header */
> >  /* If you add a new feature, make sure to also update the fast
> > @@ -1444,7 +1458,18 @@ static int coroutine_fn 
> > qcow2_do_open(BlockDriverState *bs, QDict *options,
> >  /* Open external data file */
> >  if (s->incompatible_features & QCOW2_INCOMPAT_DATA_FILE) {
> >  s->data_file = bdrv_open_child(NULL, options, "data-file", bs,
> > -   &child_file, false, errp);
> > +   &child_file, false, &local_err);
> > +if (!s->data_file) {
> > +if (s->image_data_file) {
> > +error_free(local_err);
> > +local_err = NULL;
> 
> This looked a bit weird to me at first because I was wondering why you
> wouldn't just pass allow_none=true and then handle errors (by passing
> them on).  But right, we want to retry with a filename set, maybe that
> makes more sense of the options.

I think we want the normal error message for the !s->image_data_file
case. With allow_none=true, we would have to come up with a new one here
(in the else branch below).

> Hm.  But then again, do we really?  It matches what we do with backing
> files, but that does give at least me headaches from time to time.  How
> bad would it be to allow either passing all valid options through
> @options (which would make qcow2 ignore the string in the header), or
> use the filename given in the header alone?

You mean offering only one of the two ways to configure the node?

The 'data-file' runtime option is a must so that libvirt can build the
graph node by node (and possibly use file descriptor passing one day).
But having to specify the option every time is very unfriendly for human
users, so I think allowing to store the file name in the header is a
must, too.

> > +s->data_file = bdrv_open_child(s->image_data_file, options,
> > +   "data-file", bs, 
> > &child_file,
> > +   false, errp);
> > +} else {
> > +error_propagate(errp, local_err);
> > +}
> > +}
> >  if (!s->data_file) {
> >  ret = -EINVAL;
> >  goto fail;
> 
> [...]
> 
> > @@ -3229,6 +3270,26 @@ static int coroutine_fn qcow2_co_create_opts(const 
> > char *filename, QemuOpts *opt
> >  goto finish;
> >  }
> >  
> > +/* Create and open an external data file (protocol layer) */
> > +val = qdict_get_try_str(qdict, BLOCK_OPT_DATA_FILE);
> > +if (val) {
> > +ret = bdrv_create_file(val, opts, errp);
> 
> I suppose taking an existing file is saved for later?

I think it's saved for the day that 'qemu-img create' is extended (or
replaced with an alternative) to provide the same functionality as QMP
blockdev-create.

Kevin


signature.asc
Description: PGP signature

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Thomas Huth]

On 19/02/2019 08.53, Kevin Wolf wrote:
> Am 19.02.2019 um 07:44 hat Thomas Huth geschrieben:
>> On 18/02/2019 19.22, Cleber Rosa wrote:
>>>
>>>
>>> On 2/13/19 6:54 AM, Thomas Huth wrote:
 This is very convenient for people like me who store their QEMU git trees
 on gitlab.com: Automatic CI pipelines are now run for each branch that is
 pushed to the server - useful for some extra-testing before sending PULL-
 requests for example. Since the runtime of the jobs is limited to 1h, the
 jobs are distributed into multiple pipelines - this way everything finishs
 fine within time (ca. 30 minutes currently).

 Signed-off-by: Thomas Huth 
 ---
  An example can be seen here: https://gitlab.com/huth/qemu/pipelines/

  I'd really like to get this into the main QEMU repository, so that I don't
  have to cherry-pick this patch onto my testing branches anymore each time
  I want to test before sending a PULL request...

  .gitlab-ci.yml | 73 
 ++
  MAINTAINERS|  5 
  2 files changed, 78 insertions(+)
  create mode 100644 .gitlab-ci.yml

 diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
 new file mode 100644
 index 000..79d02cf
 --- /dev/null
 +++ b/.gitlab-ci.yml
 @@ -0,0 +1,73 @@
 +before_script:
 + - apt-get update -qq
 + - apt-get install -y -qq flex bison libglib2.0-dev libpixman-1-dev 
 genisoimage
 +
 +build-system1:
 + script:
 + - apt-get install -y -qq libgtk-3-dev libvte-dev nettle-dev libcacard-dev
 +  libusb-dev libvde-dev libspice-protocol-dev libgl1-mesa-dev
 + - ./configure --enable-werror --target-list="aarch64-softmmu 
 alpha-softmmu
 +  cris-softmmu hppa-softmmu lm32-softmmu moxie-softmmu 
 microblazeel-softmmu
 +  mips64el-softmmu m68k-softmmu ppc-softmmu riscv64-softmmu 
 sparc-softmmu"
 + - make -j2
 + - make -j2 check
 +
 +build-system2:
 + script:
 + - apt-get install -y -qq libsdl2-dev libgcrypt-dev libbrlapi-dev 
 libaio-dev
 +  libfdt-dev liblzo2-dev librdmacm-dev libibverbs-dev libibumad-dev
 + - ./configure --enable-werror --target-list="tricore-softmmu 
 unicore32-softmmu
 +  microblaze-softmmu mips-softmmu riscv32-softmmu s390x-softmmu 
 sh4-softmmu
 +  sparc64-softmmu x86_64-softmmu xtensa-softmmu nios2-softmmu 
 or1k-softmmu"
 + - make -j2
 + - make -j2 check
 +
 +build-disabled:
 + script:
 + - ./configure --enable-werror --disable-rdma --disable-slirp 
 --disable-curl
 +  --disable-capstone --disable-live-block-migration 
 --disable-glusterfs
 +  --disable-replication --disable-coroutine-pool --disable-smartcard
 +  --disable-guest-agent --disable-curses --disable-libxml2 
 --disable-tpm
 +  --disable-qom-cast-debug --disable-spice --disable-vhost-vsock
 +  --disable-vhost-net --disable-vhost-crypto --disable-vhost-user
 +  --target-list="i386-softmmu ppc64-softmmu mips64-softmmu 
 i386-linux-user"
 + - make -j2
 + - make -j2 check-qtest SPEED=slow
 +
 +build-tcg-disabled:
 + script:
 + - apt-get install -y -qq clang libgtk-3-dev libbluetooth-dev libusb-dev
 + - ./configure --cc=clang --enable-werror --disable-tcg 
 --audio-drv-list=""
 + - make -j2
 + - make check-unit
 + - make check-qapi-schema
 + - cd tests/qemu-iotests/
 + - ./check -raw 001 002 003 004 005 008 009 010 011 012 021 025 032 033 
 048
 +052 063 077 086 101 104 106 113 147 148 150 151 152 157 159 
 160
 +163 170 171 183 184 192 194 197 205 208 215 221 222 226 227 
 236
 + - ./check -qcow2 001 002 003 004 005 007 008 009 010 011 012 013 017 018 
 019
 +020 021 022 024 025 027 028 029 031 032 033 034 035 036 037 
 038
 +039 040 042 043 046 047 048 049 050 051 052 053 054 056 057 
 058
 +060 061 062 063 065 066 067 068 069 071 072 073 074 079 080 
 082
 +085 086 089 090 091 095 096 097 098 099 102 103 104 105 107 
 108
 +110 111 114 117 120 122 124 126 127 129 130 132 133 134 137 
 138
 +139 140 141 142 143 144 145 147 150 151 152 154 155 156 157 
 158
 +161 165 170 172 174 176 177 179 184 186 187 190 192 194 195 
 196
 +197 200 202 203 205 208 209 214 215 216 217 218 222 226 227 
 229 234
 +
>>>
>>> On the matter of "make check-block" or "./check xxx", I've seen
>>> arguments for both sides.  I've sent a similar (but using make
>>> check-block) patch for Travis:
>>>
>>> https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg02334.html
>>>
>>> I'd be nice to hear from the qemu-iotest's maintainers which approach
>>> is preferable for upstream + shared computing res

[Qemu-devel] [Bug 1816052] Re: qemu system emulator fails to start if no sound card is present on host

[Gerd Hoffmann]

What happens if you remove "try-alsa" from the configure line?

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

Title:
  qemu system emulator fails to start if no sound card is present on
  host

Status in QEMU:
  New

Bug description:
  A plain build from git master at
  81dbcfa9e1d8bab3f7c4cc923c0b40cd666f374f on Fedora 29 x86_64 host,
  with no options passed to configure.

  Trying to launch QEMU on a  host with no audio card present:

  # ls /dev/snd/
  seq  timer

  It will fail to initialize alsa and abort startup:

  # qemu-system-x86_64 -cdrom Fedora-Workstation-Live-x86_64-29-1.2.iso  -m 
4000 -vnc 0.0.0.0:1 
  ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
  ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
  ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or 
directory
  ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
  ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
  ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
  ALSA lib conf.c:4555:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
  ALSA lib conf.c:5034:(snd_config_expand) Evaluate error: No such file or 
directory
  ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM default
  alsa: Could not initialize DAC
  alsa: Failed to open `default':
  alsa: Reason: No such file or directory
  init fail
  audio: Failed to create voice `pcspk'
  qemu-system-x86_64: Initialization of device isa-pcspk failed: Initializing 
audio voice failed

  
  git bisect blames this change:

  
commit 6a48541873f14b597630283f8f5397674ad82ea9 (HEAD, refs/bisect/bad)
Author: Gerd Hoffmann 
Date:   Thu Jan 24 12:20:55 2019 +0100

  audio: probe audio drivers by default
  
  Add the drivers listed in audio_possible_drivers to audio_drv_list,
  using the try-* variants.  That way the probable drivers are compiled by
  default if possible.
  
  Additioal tweaks:
linux: reorder to: pa alsa sdl oss.
*bsd: drop pa.
  
  Signed-off-by: Gerd Hoffmann 
  Message-id: 20190124112055.547-7-kra...@redhat.com

  
  This changed our probe order:

 Linux)
-  audio_drv_list="oss"
+  audio_drv_list="try-pa try-alsa try-sdl oss"

  After some debugging I can see that 'audio_init' successfully
  initializes the alsa driver.

  When the pcspk devices goes to AUD_open_out though, the alsa driver
  fails spewing the above text to stderr and thus causes QEMU to fail.

  This looks very much like the ALSA driver in QEMU is broken -
  audio_init() should not have succeeded unless the ALSA driver knew it
  could later succesfully honour AUD_open_out.

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

Re: [Qemu-devel] [RFC PATCH 11/11] qcow2: Add data file to ImageInfoSpecificQCow2

[Kevin Wolf]

Am 19.02.2019 um 01:47 hat Max Reitz geschrieben:
> On 31.01.19 18:55, Kevin Wolf wrote:
> > Signed-off-by: Kevin Wolf 
> > ---
> >  qapi/block-core.json | 1 +
> >  block/qcow2.c| 6 +-
> >  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> [...]
> 
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index 4959bf16a4..e3427f9fcd 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -1459,7 +1459,9 @@ static int coroutine_fn 
> > qcow2_do_open(BlockDriverState *bs, QDict *options,
> >  if (s->incompatible_features & QCOW2_INCOMPAT_DATA_FILE) {
> >  s->data_file = bdrv_open_child(NULL, options, "data-file", bs,
> > &child_file, false, &local_err);
> > -if (!s->data_file) {
> > +if (s->data_file) {
> > +s->image_data_file = g_strdup(s->data_file->bs->filename);
> > +} else {
> >  if (s->image_data_file) {
> >  error_free(local_err);
> >  local_err = NULL;
> 
> Ah, this is what I looked for in the last patch. :-)
> 
> (i.e. it should be in the last patch, not here)

[RFC PATCH 11/11] qcow2: Add data file to ImageInfoSpecificQCow2

This is the last patch. :-P

> I think as it is it is just wrong, though.  If I pass enough options at
> runtime, this will overwrite the image header:
> 
> $ ./qemu-img create -f qcow2 -o data_file=foo.raw foo.qcow2 64M
> $ ./qemu-img create -f raw bar.raw 64M
> $ ./qemu-img info foo.qcow2
> [...]
> data file: foo.raw
> [...]
> $ ./qemu-io --image-opts \
> file.filename=foo.qcow2,data-file.driver=file,\
> data-file.filename=bar.raw,lazy-refcounts=on \
> -c 'write 0 64k'
> # (The lazy-refcounts is so the image header is updated)
> $ ./qemu-img info foo.qcow2
> [...]
> data file: bar.raw
> [...]
> 
> The right thing would probably to check whether the header extension
> exists (i.e. if s->image_data_file is non-NULL) and if it does not (it
> is NULL), s->image_data_file gets set; because there are no valid images
> with the external data file flag set where there is no such header
> extension.  So we must be in the process of creating the image right now.
> 
> But even then, I don't quite like setting it here and not creating the
> header extension as part of qcow2_co_create().  I can see why you've
> done it this way, but creating a "bad" image on purpose (one with the
> external data file bit set, but no such header extension present yet) in
> order to detect and rectify this case when it is first opened (and the
> opening code assuming that any such broken image must be one that is
> opened the first time) is a bit weird.

It's not really a bad image, just one that's a bit cumbersome to use
because you need to specify the 'data-file' option manually.

> I suppose doing it right (if you agree with the paragraph before the
> last one) and adding a comment would make it less weird
> ("s->image_data_file must be non-NULL for any valid image, so this image
> must be one we are creating right now" or something like that).
> 
> But still, the issue you point out in your cover letter remains; which
> is that the node's filename and the filename given by the user may be
> two different things.

I think what I was planning to do was leaving the path from the image
header in s->image_data_file even when a runtime option overrides it.
After all, ImageInfo is about the image, not about the runtime state.

Image creation would just manually set s->image_data_file before
updating the header.

Kevin


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] hw/display: Add basic ATI VGA emulation

[Gerd Hoffmann]

On Mon, Feb 11, 2019 at 04:19:14AM +0100, BALATON Zoltan wrote:
> At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
> gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
> guests running on these and the PMON2000 firmware of the fulong2e
> expect this to be available. Fortunately these are very similar chips
> so they can be mostly emulated in the same device model. This patch
> adds basic emulation of these ATI VGA chips.
> 
> While this is incomplete and currently only enough to run the MIPS
> firmware and get console output with Linux,

Which linux driver is this?

If linux has a native driver it might make sense to also enable it on
x86.  Makes testing easier.

You can add the driver to default_list[] in vl.c, then you don't need
-vga none to remove the default vga when adding -device ati-vga.

>From a very brief look this looks sane overall, will have to find some
time for a more detailed review.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v11 7/7] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

[Wang, Wei W]

On Friday, December 14, 2018 7:17 PM, Dr. David Alan Gilbert wrote:
> > On 12/14/2018 05:56 PM, Dr. David Alan Gilbert wrote:
> > > * Wei Wang (wei.w.w...@intel.com) wrote:
> > > > On 12/13/2018 11:45 PM, Dr. David Alan Gilbert wrote:
> > > > > * Wei Wang (wei.w.w...@intel.com) wrote:
> > > > > > The new feature enables the virtio-balloon device to receive
> > > > > > hints of guest free pages from the free page vq.
> > > > > >
> > > > > > A notifier is registered to the migration precopy notifier
> > > > > > chain. The notifier calls free_page_start after the migration
> > > > > > thread syncs the dirty bitmap, so that the free page
> > > > > > optimization starts to clear bits of free pages from the
> > > > > > bitmap. It calls the free_page_stop before the migration
> > > > > > thread syncs the bitmap, which is the end of the current round
> > > > > > of ram save. The free_page_stop is also called to stop the
> optimization in the case when there is an error occurred in the process of
> ram saving.
> > > > > >
> > > > > > Note: balloon will report pages which were free at the time of this
> call.
> > > > > > As the reporting happens asynchronously, dirty bit logging
> > > > > > must be enabled before this free_page_start call is made.
> > > > > > Guest reporting must be disabled before the migration dirty bitmap
> is synchronized.
> > > > > >
> > > > > > Signed-off-by: Wei Wang 
> > > > > > CC: Michael S. Tsirkin 
> > > > > > CC: Dr. David Alan Gilbert 
> > > > > > CC: Juan Quintela 
> > > > > > CC: Peter Xu 
> > > > > I think I'm OK for this from the migration side, I'd appreciate
> > > > > someone checking the virtio and aio bits.
> > > > >
> > > > > I'm not too sure how it gets switched on and off - i.e. if we
> > > > > get a nice new qemu on a new kernel, what happens when I try and
> > > > > migrate to the same qemu on an older kernel without these hints?
> > > > >
> > > > This feature doesn't rely on the host kernel. Those hints are
> > > > reported from the guest kernel.
> > > > So migration across different hosts wouldn't affect the use of this
> feature.
> > > > Please correct me if I didn't get your point.
> > > Ah OK, yes;  now what about migrating from new->old qemu with a new
> > > guest but old machine type?
> > >
> >
> > I think normally, the source QEMU and destination QEMU should have the
> > same QEMU booting parameter. If the destination QEMU doesn't support
> > "--device virtio-balloon,free-page-hint=true", which the source QEMU
> > has, the destination side QEMU will fail to boot, and migration will
> > not happen then.
> 
> Ah that's OK; as long as free-page-hint is false by default that will work 
> fine.
> 
> Dave
> 

Hi Dave,

Could we have this feature in QEMU 4.0 (freeze on Mar 12)?

Best,
Wei

Re: [Qemu-devel] [RFC PATCH 3/4] spapr: Add NVDIMM device support

[Shivaprasad G Bhat]

On 02/19/2019 01:41 PM, Igor Mammedov wrote:

On Tue, 05 Feb 2019 23:26:27 -0600
Shivaprasad G Bhat  wrote:


Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power (May have
to re-look at this later).  Create the required DT entries for the
device (some entries have dummy values right now).

The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.

This is how it can be used ..
Add nvdimm=on to the qemu machine argument.
Ex : -machine pseries,nvdimm=on
For coldplug, the device to be added in qemu command line as shown below
-object 
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0.img,share=yes,size=512m
-device nvdimm,label-size=128k,memdev=memnvdimm0,id=nvdimm0,slot=0

For hotplug, the device to be added from monitor as below
object_add 
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0.img,share=yes,size=512m
device_add nvdimm,label-size=128k,memdev=memnvdimm0,id=nvdimm0,slot=0

Signed-off-by: Shivaprasad G Bhat 
Signed-off-by: Bharata B Rao 
[Early implementation]
---
  default-configs/ppc64-softmmu.mak |1
  hw/ppc/spapr.c|  212 +++--
  hw/ppc/spapr_drc.c|   17 +++
  hw/ppc/spapr_events.c |4 +
  include/hw/ppc/spapr.h|   10 ++
  include/hw/ppc/spapr_drc.h|9 ++
  6 files changed, 241 insertions(+), 12 deletions(-)

diff --git a/default-configs/ppc64-softmmu.mak 
b/default-configs/ppc64-softmmu.mak
index 7f34ad0528..b6e1aa5125 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -20,4 +20,5 @@ CONFIG_XIVE=$(CONFIG_PSERIES)
  CONFIG_XIVE_SPAPR=$(CONFIG_PSERIES)
  CONFIG_MEM_DEVICE=y
  CONFIG_DIMM=y
+CONFIG_NVDIMM=y
  CONFIG_SPAPR_RNG=y
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 0fcdd35cbe..7e7a1a8041 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -73,6 +73,7 @@
  #include "qemu/cutils.h"
  #include "hw/ppc/spapr_cpu_core.h"
  #include "hw/mem/memory-device.h"
+#include "hw/mem/nvdimm.h"
  
  #include 
  
@@ -690,6 +691,7 @@ static int spapr_populate_drmem_v2(sPAPRMachineState *spapr, void *fdt,

  uint8_t *int_buf, *cur_index, buf_len;
  int ret;
  uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
+uint64_t scm_block_size = SPAPR_MINIMUM_SCM_BLOCK_SIZE;
  uint64_t addr, cur_addr, size;
  uint32_t nr_boot_lmbs = (machine->device_memory->base / lmb_size);
  uint64_t mem_end = machine->device_memory->base +
@@ -726,15 +728,24 @@ static int spapr_populate_drmem_v2(sPAPRMachineState 
*spapr, void *fdt,
  nr_entries++;
  }
  
-/* Entry for DIMM */

-drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / lmb_size);
-g_assert(drc);
-elem = spapr_get_drconf_cell(size / lmb_size, addr,
- spapr_drc_index(drc), node,
- SPAPR_LMB_FLAGS_ASSIGNED);
+if (info->value->type == MEMORY_DEVICE_INFO_KIND_NVDIMM) {
+/* Entry for NVDIMM */
+drc = spapr_drc_by_id(TYPE_SPAPR_DRC_PMEM, addr / scm_block_size);
+g_assert(drc);
+elem = spapr_get_drconf_cell(size / scm_block_size, addr,
+ spapr_drc_index(drc), -1, 0);
+cur_addr = ROUND_UP(addr + size, scm_block_size);
+} else {
+/* Entry for DIMM */
+drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / lmb_size);
+g_assert(drc);
+elem = spapr_get_drconf_cell(size / lmb_size, addr,
+ spapr_drc_index(drc), node,
+ SPAPR_LMB_FLAGS_ASSIGNED);
+cur_addr = addr + size;
+}
  QSIMPLEQ_INSERT_TAIL(&drconf_queue, elem, entry);
  nr_entries++;
-cur_addr = addr + size;
  }
  
  /* Entry for remaining hotpluggable area */

@@ -1225,6 +1236,42 @@ static void spapr_dt_hypervisor(sPAPRMachineState 
*spapr, void *fdt)
  }
  }
  
+static int spapr_populate_nvdimm_node(void *fdt, int fdt_offset,

+  uint32_t node, uint64_t addr,
+  uint64_t size, uint64_t label_size);
+static void spapr_create_nvdimm(void *fdt)
+{
+int offset = fdt_subnode_offset(fdt, 0, "persistent-memory");
+GSList *dimms = NULL;
+
+if (offset < 0) {
+offset = fdt_add_subnode(fdt, 0, "persistent-memory");
+_FDT(offset);
+_FDT((fdt_setprop_cell(fdt, offset, "#address-cells", 0x2)));
+_FDT((fdt_setprop_cell(fdt, offset, "#size-cells", 0x0)));
+_FDT((fdt_setprop_string(fdt, offset, "name", "persistent-memory")));
+_FDT((fdt_setprop_string(fdt, of

Re: [Qemu-devel] [Qemu-ppc] [PATCH v3] ppc: add host-serial and host-model machine attributes

[Daniel P . Berrangé]

On Tue, Feb 19, 2019 at 12:21:04PM +1100, David Gibson wrote:
> On Mon, Feb 18, 2019 at 11:52:18AM +, Daniel P. Berrangé wrote:
> > On Mon, Feb 18, 2019 at 12:38:11PM +0100, Greg Kurz wrote:
> > > On Mon, 18 Feb 2019 15:42:18 +0530
> > > P J P  wrote:
> > > 
> > > > From: Prasad J Pandit 
> > > > 
> > > > On ppc hosts, hypervisor shares following system attributes
> > > > 
> > > >   - /proc/device-tree/system-id
> > > >   - /proc/device-tree/model
> > > > 
> > > > with a guest. This could lead to information leakage and misuse.[*]
> > > > Add machine attributes to control such system information exposure
> > > > to a guest.
> > > > 
> > > > [*] https://wiki.openstack.org/wiki/OSSN/OSSN-0028
> > > > 
> > > > Reported-by: Daniel P. Berrangé 
> > > > Fix-suggested-by: Daniel P. Berrangé 
> > > > Signed-off-by: Prasad J Pandit 
> > > > ---
> > > >  hw/ppc/spapr.c | 79 ++
> > > >  include/hw/ppc/spapr.h |  2 ++
> > > >  2 files changed, 75 insertions(+), 6 deletions(-)
> > > > 
> > > > Update v3: move host-serial,host-model options to ppc sPAPR machine
> > > >   -> 
> > > > https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg03182.html  
> > > > 
> > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > index 0942f35bf8..666e500376 100644
> > > > --- a/hw/ppc/spapr.c
> > > > +++ b/hw/ppc/spapr.c
> > > > @@ -1249,13 +1249,30 @@ static void *spapr_build_fdt(sPAPRMachineState 
> > > > *spapr,
> > > >   * Add info to guest to indentify which host is it being run on
> > > >   * and what is the uuid of the guest
> > > >   */
> > > > -if (kvmppc_get_host_model(&buf)) {
> > > > -_FDT(fdt_setprop_string(fdt, 0, "host-model", buf));
> > > > -g_free(buf);
> > > > +if (spapr->host_model && !g_str_equal(spapr->host_model, "none")) {
> > > > +if (g_str_equal(spapr->host_model, "passthrough")) {
> > > > +/* -M host-model=passthrough */
> > > > +if (kvmppc_get_host_model(&buf)) {
> > > > +_FDT(fdt_setprop_string(fdt, 0, "host-model", buf));
> > > > +g_free(buf);
> > > > +}
> > > > +} else {
> > > > +/* -M host-model= */
> > > > +_FDT(fdt_setprop_string(fdt, 0, "host-model", 
> > > > spapr->host_model));
> > > > +}
> > > >  }
> > > > -if (kvmppc_get_host_serial(&buf)) {
> > > > -_FDT(fdt_setprop_string(fdt, 0, "host-serial", buf));
> > > > -g_free(buf);
> > > > +
> > > > +if (spapr->host_serial && !g_str_equal(spapr->host_serial, 
> > > > "none")) {
> > > > +if (g_str_equal(spapr->host_serial, "passthrough")) {
> > > > +/* -M host-serial=passthrough */
> > > > +if (kvmppc_get_host_serial(&buf)) {
> > > > +_FDT(fdt_setprop_string(fdt, 0, "host-serial", buf));
> > > > +g_free(buf);
> > > > +}
> > > > +} else {
> > > > +/* -M host-serial= */
> > > > +_FDT(fdt_setprop_string(fdt, 0, "host-serial", 
> > > > spapr->host_serial));
> > > > +}
> > > >  }
> > > >  
> > > >  buf = qemu_uuid_unparse_strdup(&qemu_uuid);
> > > > @@ -3138,6 +3155,36 @@ static void spapr_set_ic_mode(Object *obj, const 
> > > > char *value, Error **errp)
> > > >  }
> > > >  }
> > > >  
> > > > +static char *spapr_get_host_model(Object *obj, Error **errp)
> > > > +{
> > > > +sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> > > > +
> > > > +return g_strdup(spapr->host_model);
> > > > +}
> > > > +
> > > > +static void spapr_set_host_model(Object *obj, const char *value, Error 
> > > > **errp)
> > > > +{
> > > > +sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> > > > +
> > > > +g_free(spapr->host_model);
> > > > +spapr->host_model = g_strdup(value);
> > > > +}
> > > > +
> > > > +static char *spapr_get_host_serial(Object *obj, Error **errp)
> > > > +{
> > > > +sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> > > > +
> > > > +return g_strdup(spapr->host_serial);
> > > > +}
> > > > +
> > > > +static void spapr_set_host_serial(Object *obj, const char *value, 
> > > > Error **errp)
> > > > +{
> > > > +sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> > > > +
> > > > +g_free(spapr->host_serial);
> > > > +spapr->host_serial = g_strdup(value);
> > > > +}
> > > > +
> > > >  static void spapr_instance_init(Object *obj)
> > > >  {
> > > >  sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> > > > @@ -3183,6 +3230,20 @@ static void spapr_instance_init(Object *obj)
> > > >  object_property_set_description(obj, "ic-mode",
> > > >   "Specifies the interrupt controller mode (xics, xive, 
> > > > dual)",
> > > >   NULL);
> > > > +
> > > > +spapr->host_model = NULL;
> > > 
> > > This isn't needed since object_initialize_with_type() already takes care
> > > of zeroing the instance for us.
> > > 
> > > > +object_property_add_str(obj, "host-m

Re: [Qemu-devel] [PATCH v4 07/11] virtio: fill/flush/pop for packed ring

[Jason Wang]

On 2019/2/19 下午4:21, Wei Xu wrote:

On Tue, Feb 19, 2019 at 02:49:42PM +0800, Jason Wang wrote:

On 2019/2/18 下午10:46, Wei Xu wrote:

Do we allow chain more descriptors than vq size in the case of indirect?
According to the spec:

"

The device limits the number of descriptors in a list through a
transport-specific and/or device-specific value. If not limited,
the maximum number of descriptors in a list is the virt queue
size.
"

This looks possible, so the above is probably wrong if the max number of
chained descriptors is negotiated through a device specific way.


OK, I will remove this check, while it is necessary to have a limitation
for indirect descriptor anyway, otherwise it is possible to hit an overflow
since presumably u16 is used for most number/size in the spec.


Please try to test block and scsi device for you changes as well.

Any idea about what kind of test should be covered? AFAICT, currently
packed ring is targeted for virtio-net as discussed during voting spec.

Wei



Well it's not only for net for sure, it should support all kinds of 
device. For testing, you should test basic function plus migration.


Thanks





Thanks

Re: [Qemu-devel] [PATCH v1 0/1] Allow TAP to unnegotiate virtio-net header

[Jason Wang]

On 2019/2/19 下午4:28, Vincenzo Maffione wrote:

Il giorno mar 19 feb 2019 alle ore 07:48 Jason Wang 
ha scritto:


On 2019/2/18 下午7:53, Vincenzo Maffione wrote:

Hi Jason,
Thanks for the quick reply.

My PV device (to be open sourced soon) uses the QEMU net backend

interface,

in a way similar to virtio-net.
For example it uses qemu_set_offload(), qemu_has_vnet_hdr_len(),
qemu_using_vnet_hdr(), qemu_send_packet(), etc.
This means that the device itself does not know which net backend is

using,

of course.
In addition to TAP, also the netmap backend supports the virtio-net

header,

and so the PV device will work with both.
Regarding the virtio-net header, the netmap backend is more flexible
because you can change the virtio-net header length as you wish (choosing
between 0, 10 and 12 bytes).


Interesting, actually, there's case that vnet header is not used even
for virtio-net, e.g for the case of XDP withouth csum support. If we
don't pass vnet header in this case, we may get even higher PPS.


I guess in this case we simply pass a zeroed header. According to my
experience I think it's unlikely that PPS are affected by having 12
additional bytes to copy around, as long as no processing is done on the
header. I may be wrong of course.



The problem is device doesn't know whether it was zeroed, so it need to 
examine some fields.


Thanks







My problem cannot be solved by making sure that TAPs are opened without
IFF_VNET_HDR. What I want instead
is to dynamically change the length of the virtio-net header that the
backend accepts, switching between 12 bytes (virtio 1.0 header) and 0 (no
header). By "dynamically" I mean while the guest (and the device) is
running. This is possible and safe if we get rid of that assert().
The virtio-net device does not need that flexibility (once you enable the
vtnet header, you never disable that again), so I guess that's why you

have

that assert().
My PV device can be reconfigured on the fly in such a way it may or not

may

be aware of the virtio-net header, and as a consequence it may need to

call

qemu_using_vnet_hdr() with true or false (multiple times).

Does it make sense?


Yes, it is. But I think maybe it's better to send this patch with your
new PV device implementation.

Sounds good, thanks.

Cheers,
   Vincenzo



Thanks



Cheers,
Vincenzo


Il giorno lun 18 feb 2019 alle ore 05:19 Jason Wang 
On 2019/2/16 上午1:46, Vincenzo Maffione wrote:

Hi,
 I was doing experiments with a custom paravirtualized net device,
and I ran into a limitation of the TAP backend. I see from the kernel
code that it is not possible to set the TAP virtio-net header
length to something different from 10 or 12, which means that it
is not possible to set it to 0. That's fine.
The QEMU implementation of the TAP backend already supports
the case where virtio-net header is set to 10 or 12 in kernel,
but the emulated/paravirtualized net device is not using that:
the TAP backend will just strip/prepend a zeroed header in this case
(e.g., see the if statement in tap_receive_iov()).
However, the tap_using_vnet_hdr() has an assert() that prevents
this situation to happen, and I don't understand why. Maybe it
is a leftover? I tried to remove the assert and by doing that
my paravirtualized device was able to stop using the virtio-net
header.

Hi:

If  I understand this correctly, your PV device is API compatible with
TAP? Then you may just adding code to call TUNSETIFF without

IFF_VNET_HDR?

Thanks



Vincenzo Maffione (1):
 net: tap: allow net frontends to un-negotiate virtio-net header

net/tap.c | 1 -
1 file changed, 1 deletion(-)

Re: [Qemu-devel] [PULL 00/43] ppc-for-4.0 queue 20190219

[Peter Maydell]

On Mon, 18 Feb 2019 at 14:30, David Gibson  wrote:
>
> The following changes since commit 1e36232994c8ad01774501d2e299deba3a2469af:
>
>   Merge remote-tracking branch 'remotes/mcayland/tags/qemu-openbios-20190215' 
> into staging (2019-02-15 11:12:14 +)
>
> are available in the Git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-4.0-20190219
>
> for you to fetch changes up to 73e14c6a9cdefb94c01ea488f04e7fba7ac0dc5b:
>
>   target/ppc: convert vmin* and vmax* to vector operations (2019-02-18 
> 11:00:44 +1100)
>
> 
> ppc patch queue 2019-02-19
>
> Here's the next batch of ppc and spapr patches.  Higlights are:
>
>  * A bunch of improvements to TCG handling of vector instructions from
>Richard Henderson and Marc Cave-Ayland
>
>  * Cleanup to the XICS interrupt controller from Greg Kurz, removing
>the special KVM subclasses which were a bad idea
>
>  * Some refinements to the XIVE interrupt controller from Cédric Le
>Goater
>
>  * Fix from Fabiano Rosas for a really dumb buffer overflow in the
>device tree code for memory hotplug
>
>  * Code for allowing access to SPRs from the gdb stub from Fabiano
>Rosas
>
>  * Assorted minor fixes and cleanups
>

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

^^^ I notice the PowerPC section of the changelog is still pretty bare...

-- PMM

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Kevin Wolf]

Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> On 19/02/2019 08.53, Kevin Wolf wrote:
> > Am 19.02.2019 um 07:44 hat Thomas Huth geschrieben:
> >> On 18/02/2019 19.22, Cleber Rosa wrote:
> >>>
> >>>
> >>> On 2/13/19 6:54 AM, Thomas Huth wrote:
>  This is very convenient for people like me who store their QEMU git trees
>  on gitlab.com: Automatic CI pipelines are now run for each branch that is
>  pushed to the server - useful for some extra-testing before sending PULL-
>  requests for example. Since the runtime of the jobs is limited to 1h, the
>  jobs are distributed into multiple pipelines - this way everything 
>  finishs
>  fine within time (ca. 30 minutes currently).
> 
>  Signed-off-by: Thomas Huth 
>  ---
>   An example can be seen here: https://gitlab.com/huth/qemu/pipelines/
> 
>   I'd really like to get this into the main QEMU repository, so that I 
>  don't
>   have to cherry-pick this patch onto my testing branches anymore each 
>  time
>   I want to test before sending a PULL request...
> 
>   .gitlab-ci.yml | 73 
>  ++
>   MAINTAINERS|  5 
>   2 files changed, 78 insertions(+)
>   create mode 100644 .gitlab-ci.yml
> 
>  diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>  new file mode 100644
>  index 000..79d02cf
>  --- /dev/null
>  +++ b/.gitlab-ci.yml
>  @@ -0,0 +1,73 @@
>  +before_script:
>  + - apt-get update -qq
>  + - apt-get install -y -qq flex bison libglib2.0-dev libpixman-1-dev 
>  genisoimage
>  +
>  +build-system1:
>  + script:
>  + - apt-get install -y -qq libgtk-3-dev libvte-dev nettle-dev 
>  libcacard-dev
>  +  libusb-dev libvde-dev libspice-protocol-dev libgl1-mesa-dev
>  + - ./configure --enable-werror --target-list="aarch64-softmmu 
>  alpha-softmmu
>  +  cris-softmmu hppa-softmmu lm32-softmmu moxie-softmmu 
>  microblazeel-softmmu
>  +  mips64el-softmmu m68k-softmmu ppc-softmmu riscv64-softmmu 
>  sparc-softmmu"
>  + - make -j2
>  + - make -j2 check
>  +
>  +build-system2:
>  + script:
>  + - apt-get install -y -qq libsdl2-dev libgcrypt-dev libbrlapi-dev 
>  libaio-dev
>  +  libfdt-dev liblzo2-dev librdmacm-dev libibverbs-dev libibumad-dev
>  + - ./configure --enable-werror --target-list="tricore-softmmu 
>  unicore32-softmmu
>  +  microblaze-softmmu mips-softmmu riscv32-softmmu s390x-softmmu 
>  sh4-softmmu
>  +  sparc64-softmmu x86_64-softmmu xtensa-softmmu nios2-softmmu 
>  or1k-softmmu"
>  + - make -j2
>  + - make -j2 check
>  +
>  +build-disabled:
>  + script:
>  + - ./configure --enable-werror --disable-rdma --disable-slirp 
>  --disable-curl
>  +  --disable-capstone --disable-live-block-migration 
>  --disable-glusterfs
>  +  --disable-replication --disable-coroutine-pool --disable-smartcard
>  +  --disable-guest-agent --disable-curses --disable-libxml2 
>  --disable-tpm
>  +  --disable-qom-cast-debug --disable-spice --disable-vhost-vsock
>  +  --disable-vhost-net --disable-vhost-crypto --disable-vhost-user
>  +  --target-list="i386-softmmu ppc64-softmmu mips64-softmmu 
>  i386-linux-user"
>  + - make -j2
>  + - make -j2 check-qtest SPEED=slow
>  +
>  +build-tcg-disabled:
>  + script:
>  + - apt-get install -y -qq clang libgtk-3-dev libbluetooth-dev libusb-dev
>  + - ./configure --cc=clang --enable-werror --disable-tcg 
>  --audio-drv-list=""
>  + - make -j2
>  + - make check-unit
>  + - make check-qapi-schema
>  + - cd tests/qemu-iotests/
>  + - ./check -raw 001 002 003 004 005 008 009 010 011 012 021 025 032 033 
>  048
>  +052 063 077 086 101 104 106 113 147 148 150 151 152 157 159 
>  160
>  +163 170 171 183 184 192 194 197 205 208 215 221 222 226 227 
>  236
>  + - ./check -qcow2 001 002 003 004 005 007 008 009 010 011 012 013 017 
>  018 019
>  +020 021 022 024 025 027 028 029 031 032 033 034 035 036 037 
>  038
>  +039 040 042 043 046 047 048 049 050 051 052 053 054 056 057 
>  058
>  +060 061 062 063 065 066 067 068 069 071 072 073 074 079 080 
>  082
>  +085 086 089 090 091 095 096 097 098 099 102 103 104 105 107 
>  108
>  +110 111 114 117 120 122 124 126 127 129 130 132 133 134 137 
>  138
>  +139 140 141 142 143 144 145 147 150 151 152 154 155 156 157 
>  158
>  +161 165 170 172 174 176 177 179 184 186 187 190 192 194 195 
>  196
>  +197 200 202 203 205 208 209 214 215 216 217 218 222 226 227 
>  229 234
>  +
> >>>
> >>> On the matter of "make check-block" or "./check xxx", I

Re: [Qemu-devel] [PATCH] hw/display: Add basic ATI VGA emulation

[Peter Maydell]

On Tue, 12 Feb 2019 at 23:59, BALATON Zoltan  wrote:
>
> Hello,
>
> On Tue, 12 Feb 2019, Philippe Mathieu-Daudé wrote:
> > Hi Zoltan,
>
> Thanks for the quick review and testing. I'll use your suggestions for the
> other (mips) patches in a v2. For this one I'm not convinced.
>
> > On 2/11/19 4:19 AM, BALATON Zoltan wrote:
> [...]
> >> +
> >> +static void ati_reg_write_offs(uint32_t *reg, int offs,
> >> +   uint64_t data, unsigned int size)
> >> +{
> >> +int shift, i;
> >> +uint32_t mask;
> >> +
> >> +for (i = 0; i < size; i++) {
> >> +shift = (offs + i) * 8;
> >> +mask = 0xffUL << shift;
> >> +*reg &= ~mask;
> >> +*reg |= (data & 0xff) << shift;
> >> +data >>= 8;
> >
> > I'd have use a pair of extract32/deposit32 but this is probably easier
> > to singlestep.
>
> You've told me that before but I have concerns about the asserts in those
> functions which to me seem like unnecessary overhead in such low level
> functions so unless these are removed or *_noassert versions introduced
> I'll stay away from them.

The code above is IMHO pretty hard to read -- you have to
think through all the shifts and masks to figure out exactly
what is being done. I would definitely recommend extract32/deposit32,
as they convey the intent much better. You're already inside a
register accessor for a device model, there is much more overhead
on this path than a few assert condition checks. (And they do
catch bugs -- they found one in the arm code last month.)

(Alternatively, if you believe the overhead of the asserts matters,
then provide benchmarking demonstrating it, and we could look
at restricting this assert to the case where start and length are
compile-time constant, or to only the --enable-debug build.)

> But I'm also not too happy about these *_offs functions but some registers
> support 8/16/32 bit access and guest code seems to actually do this to
> update bits in the middle of the register at an odd address. Best would be
> if I could just set .impl.min = 4, .impl.max = 4 and .valid.min = 1
> .valid.max = 4 for the mem region ops but I'm not sure that would work or
> would it? If that's working maybe I should just go with that instead.

This will work, but only if all the registers in the memory region
are happy with "read 32 bits, write back 32 bits", ie they have
no "write-1-to-clear", "special behaviour on read", etc. (The
memory system will implement byte reads as "read 32 bits, modify,
write back".) If it does work then that's a nice way to do it.

> I won't and here's why: This is not a finished device model and I expect
> to need to add debug logs and change them frequently during further
> development and for such ad-hoc debugging DPRINF is still easier to use
> because I don't have to define the format string at one file and use them
> somewhere else.

If you want to use local debug printfs for your convenience that's fine.
You don't have to submit them in the patches you send. (I use them
quite a bit in development, and my stack of patches usually has a
patch at the end called "debug junk" with that kind of thing in it.)
But new code we take into upstream should be preferring trace events
over ad-hoc DPRINTF.

> Anything that
> distracts from actual values and makes it harder to read (such as
> timestamps and pids added by trace)

-d trace:your_trace_event doesn't add timestamps or PIDs, FWIW.

thanks
-- PMM

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Thomas Huth]

On 19/02/2019 10.37, Kevin Wolf wrote:
> Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
>> On 19/02/2019 08.53, Kevin Wolf wrote:
[...]
>>> Which are the cases that fail for you with '--disable-tcg'?
>>
>> These tests are failing: 087 169 188 232 235 238
> 
> Hm, 087 and 232 just do something like:
> 
> $QEMU_PROG -nodefaults -machine accel=qtest -nographic \
>-qmp stdio -serial none \
>...some -drive and -object options...
> 
> This should be fine with --disable-tcg, I think?
> 
> 169 runs a VM, but I don't see anything that makes it use TCG.
> 
> 188 doesn't even run QEMU at all, it's only qemu-io. I don't see how
> this could be possibly related to --disable-tcg.

087 and 188 obviously simply lack a check for the required crypto support.


Output of 087:

087[08:33:55] [08:33:56] - output mismatch (see 087.out.bad)
--- /builds/huth/qemu/tests/qemu-iotests/087.out2019-02-19 
08:23:54.0 +
+++ /builds/huth/qemu/tests/qemu-iotests/087.out.bad2019-02-19 
08:33:56.0 +
@@ -46,12 +46,13 @@
 
 === Encrypted image LUKS ===
 
+qemu-img: TEST_DIR/t.IMGFMT: No crypto library supporting PBKDF in this build: 
Function not implemented
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encrypt.format=luks 
encrypt.key-secret=sec0
 Testing:
 QMP_VERSION
 {"return": {}}
 {"return": {}}
-{"return": {}}
+{"error": {"class": "GenericError", "desc": "No encryption in image header, 
but options specified format 'luks'"}}
 {"return": {}}
 {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}}


And the output of 188:

188[08:34:53] [08:34:54] - output mismatch (see 188.out.bad)
--- /builds/huth/qemu/tests/qemu-iotests/188.out2019-02-19 
08:23:54.0 +
+++ /builds/huth/qemu/tests/qemu-iotests/188.out.bad2019-02-19 
08:34:54.0 +
@@ -1,4 +1,5 @@
 QA output created by 188
+qemu-img: TEST_DIR/t.IMGFMT: No crypto library supporting PBKDF in this build: 
Function not implemented
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 encrypt.format=luks 
encrypt.key-secret=sec0 encrypt.iter-time=10
 
 == reading whole image ==
@@ -14,5 +15,6 @@
 16 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 
 == verify open failure with wrong password ==
-can't open: Invalid password, cannot unlock any keyslot
+read 16777216/16777216 bytes at offset 0
+16 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 *** done


169 got killed via abort():

169[08:34:39] [08:34:46] [failed, exit status 1] - output 
mismatch (see 169.out.bad)
--- /builds/huth/qemu/tests/qemu-iotests/169.out2019-02-19 
08:23:54.0 +
+++ /builds/huth/qemu/tests/qemu-iotests/169.out.bad2019-02-19 
08:34:46.0 +
@@ -1,5 +1,29 @@
-
+WARNING:qemu:qemu received signal 6: 
/builds/huth/qemu/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64 
-chardev 
socket,id=mon,path=/tmp/qemu-iotests-quick-25045/tmpGQOExQ/qemua-13044-monitor.sock
 -mon chardev=mon,mode=control -display none -vga none -qtest 
unix:path=/tmp/qemu-iotests-quick-25045/qemua-13044-qtest.sock -machine 
accel=qtest -nodefaults -machine accel=qtest -drive 
if=virtio,id=drive0,file=/tmp/qemu-iotests-quick-25045/disk_a,format=qcow2,cache=writeback
[...]

No clue why.


232 is also strange, no idea what is going on here:

232[08:38:53] [08:38:56] - output mismatch (see 232.out.bad)
--- /builds/huth/qemu/tests/qemu-iotests/232.out2019-02-19 
08:23:54.0 +
+++ /builds/huth/qemu/tests/qemu-iotests/232.out.bad2019-02-19 
08:38:56.0 +
@@ -21,13 +21,13 @@
 NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
 NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
 
-QEMU_PROG: -drive 
driver=file,file=TEST_DIR/t.IMGFMT,if=none,read-only=off,auto-read-only=off: 
Could not open 'TEST_DIR/t.IMGFMT': Permission denied
-NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
-NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
-
-QEMU_PROG: -drive 
driver=file,file=TEST_DIR/t.IMGFMT,if=none,auto-read-only=off: Could not open 
'TEST_DIR/t.IMGFMT': Permission denied
-NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
-NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
+NODE_NAME: TEST_DIR/t.IMGFMT (file)
+NODE_NAME: TEST_DIR/t.IMGFMT (file)
+NODE_NAME: TEST_DIR/t.IMGFMT (file)
+
+NODE_NAME: TEST_DIR/t.IMGFMT (file)
+NODE_NAME: TEST_DIR/t.IMGFMT (file)
+NODE_NAME: TEST_DIR/t.IMGFMT (file)

>> 235 and 238 apparently try to use accel=kvm, so they likely should not
>> be in the "quick" group.
> 
> Yes, I agree.
> 
> Or maybe we should check again why they need kvm at all, in theory they
> shouldn't. They are throttling tests, so the obvious reason seems to be
> that they need a running clock. Using -M qtest and advancing the clock
> manually could do the trick then (and would even be more reliable).
> 
>> 

[Qemu-devel] [PATCH] audio: don't use alsa by default

[Gerd Hoffmann]

In case no sound hardware is present the driver initializes
successfully and throws errors later on, i.e. effectively the
automatic probing doesn't work.  So the driver should not be
used by default (until that is fixed).  Drop the can_be_default
flag.

Explicitly picking the alsa driver (using QEMU_AUDIO_DRV=alsa
environment variable) will continue to work.

Buglink: https://bugs.launchpad.net/qemu/+bug/1816052
Signed-off-by: Gerd Hoffmann 
---
 audio/alsaaudio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index 635be73bf4..1cc570e30b 100644
--- a/audio/alsaaudio.c
+++ b/audio/alsaaudio.c
@@ -1218,7 +1218,6 @@ static struct audio_driver alsa_audio_driver = {
 .init   = alsa_audio_init,
 .fini   = alsa_audio_fini,
 .pcm_ops= &alsa_pcm_ops,
-.can_be_default = 1,
 .max_voices_out = INT_MAX,
 .max_voices_in  = INT_MAX,
 .voice_size_out = sizeof (ALSAVoiceOut),
-- 
2.9.3

Re: [Qemu-devel] [PATCH v2 2/6] block/dirty-bitmaps: rename frozen predicate helper

[Vladimir Sementsov-Ogievskiy]

19.02.2019 1:32, John Snow wrote:
> 
> 
> On 2/18/19 8:57 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 14.02.2019 2:23, John Snow wrote:
>>> "Frozen" was a good description a long time ago, but it isn't adequate now.
>>> Rename the frozen predicate to has_successor to make the semantics of the
>>> predicate more clear to outside callers.
>>>
>>> In the process, remove some calls to frozen() that no longer semantically
>>> make sense. For enabled and disabled in particular, it's actually okay for
>>> the internals to do this but only forbidden for users to invoke them, and
>>
>> I'm a bit lost in this paragraph.. to this - what?, to invoke them - whom?
>> I think, it would be simpler for me to read patch itself :)
>>
> 
> Touched this up. I meant enable and disable, not enabled and disabled.
> 
>>> all of the QMP entry uses already check against qmp_locked.
>>>
>>> Several other assertions really want to check that the bitmap isn't in-use
>>> by another operation -- use the qmp_locked function for this instead, which
>>> presently also checks for has_successor.
>>
>> hm, you mean user_locked, not qmp_locked.
>>
> 
> Yes.
> 
> [...]
> 
>>>/**
>>> * Create a successor bitmap destined to replace this bitmap after an 
>>> operation.
>>> - * Requires that the bitmap is not frozen and has no successor.
>>> + * Requires that the bitmap is not locked and has no successor.
>>
>> I think, user_locked, to not interfere with bitmaps mutex. And you use 
>> user_locked in
>> other comments in this patch.
>>
> 
> You're right. It gets changed again later, but I didn't make this easy
> to read.
> 
>>> * Called with BQL taken.
>>> */
>>>int bdrv_dirty_bitmap_create_successor(BlockDriverState *bs,
>>> @@ -244,12 +244,16 @@ int 
>>> bdrv_dirty_bitmap_create_successor(BlockDriverState *bs,
>>>uint64_t granularity;
>>>BdrvDirtyBitmap *child;
>>>
>>> -if (bdrv_dirty_bitmap_frozen(bitmap)) {
>>> -error_setg(errp, "Cannot create a successor for a bitmap that is "
>>> -   "currently frozen");
>>> +if (bdrv_dirty_bitmap_user_locked(bitmap)) {
>>> +error_setg(errp, "Cannot create a successor for a bitmap that is 
>>> in-use "
>>> +   "by an operation");
>>> +return -1;
>>> +}
>>> +if (bdrv_dirty_bitmap_has_successor(bitmap)) {
>>> +error_setg(errp, "Cannot create a successor for a bitmap that 
>>> already "
>>> +   "has one");
>>
>>
>> Amm, dead code? _user_locked() implies no successor, so we instead can keep 
>> an assertion..
>>
> 
> It gets changed later in the series, but I didn't do a great job of
> explaining that in advance. I'll amend the commit message to explain
> what I'm trying to do.
> 
> I tried to hint at this with: "which presently also checks for
> has_successor" as an admission that it was redundant, but I need to call
> it out in stronger language.
> 

Hmm, isn't it better to keep an assertion, than add dead code, to be fixed in 
later commits?

-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH 04/12] io: Make qio_channel_yield() interruptible

[Kevin Wolf]

Am 18.02.2019 um 18:11 hat Paolo Bonzini geschrieben:
> On 18/02/19 17:18, Kevin Wolf wrote:
> > Similar to how qemu_co_sleep_ns() allows to be preempted by an external
> > coroutine entry, allow reentering qio_channel_yield() early.
> > 
> > Signed-off-by: Kevin Wolf 
> > ---
> >  include/io/channel.h |  9 ++---
> >  io/channel.c | 10 ++
> >  2 files changed, 16 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/io/channel.h b/include/io/channel.h
> > index da2f138200..59460cb1ec 100644
> > --- a/include/io/channel.h
> > +++ b/include/io/channel.h
> > @@ -739,10 +739,13 @@ void qio_channel_detach_aio_context(QIOChannel *ioc);
> >   * addition, no two coroutine can be waiting on the same condition
> >   * and channel at the same time.
> >   *
> > - * This must only be called from coroutine context
> > + * This must only be called from coroutine context. It is safe to
> > + * reenter the coroutine externally while it is waiting; in this
> > + * case the function will return even if @condition is not yet
> > + * available.
> >   */
> > -void qio_channel_yield(QIOChannel *ioc,
> > -   GIOCondition condition);
> > +void coroutine_fn qio_channel_yield(QIOChannel *ioc,
> > +GIOCondition condition);
> >  
> >  /**
> >   * qio_channel_wait:
> > diff --git a/io/channel.c b/io/channel.c
> > index 8dd0684f5d..303376e08d 100644
> > --- a/io/channel.c
> > +++ b/io/channel.c
> > @@ -469,6 +469,16 @@ void coroutine_fn qio_channel_yield(QIOChannel *ioc,
> >  }
> >  qio_channel_set_aio_fd_handlers(ioc);
> >  qemu_coroutine_yield();
> > +
> > +/* Allow interrupting the operation by reentering the coroutine other 
> > than
> > + * through the aio_fd_handlers. */
> > +if (condition == G_IO_IN && ioc->read_coroutine) {
> > +ioc->read_coroutine = NULL;
> > +qio_channel_set_aio_fd_handlers(ioc);
> > +} else if (condition == G_IO_OUT && ioc->write_coroutine) {
> > +ioc->write_coroutine = NULL;
> > +qio_channel_set_aio_fd_handlers(ioc);
> > +}
> >  }
> 
> Perhaps it's a bit cleaner to remove the ioc->..._coroutine assignments,
> and the call to qio_channel_set_aio_fd_handlers, from
> qio_channel_restart_read and qio_channel_restart_write.

I wasn't sure if this was correct because aio_co_wake() doesn't
necessarily enter the coroutine immediately, so the value between there
and actually entering the coroutine would change compared to the old
state.

On closer look, these handlers are never in coroutine context, and
qio_channel_attach_aio_context() asserts that the handlers are inactive,
so I guess we could replace the aio_co_wake() with a direct
qemu_coroutine_enter() and possibly an assertion that we're already in
the right AioContext.

That would make it obvious that removing the assignment and call to
qio_channel_set_aio_fd_handlers() there is safe.

In any case, I think this needs to be a separate patch where the commit
message can explain the above.

Kevin

Re: [Qemu-devel] [PATCH] iotests: handle TypeError for Python3 in test 242

[Vladimir Sementsov-Ogievskiy]

18.02.2019 22:59, Andrey Shinkevich wrote:
> To write one byte to disk, Python2 may use 'chr' type.
> In Python3, conversion to 'byte' type is required.
> 
> Signed-off-by: Andrey Shinkevich 

Reviewed-by: Vladimir Sementsov-Ogievskiy 

Forget to say to Andrey that we should add

Reported-by: Kevin Wolf 

> ---
>   tests/qemu-iotests/242 | 9 +++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/qemu-iotests/242 b/tests/qemu-iotests/242
> index 16c65ed..6b1f7b8 100755
> --- a/tests/qemu-iotests/242
> +++ b/tests/qemu-iotests/242
> @@ -65,9 +65,14 @@ def toggle_flag(offset):
>   with open(disk, "r+b") as f:
>   f.seek(offset, 0)
>   c = f.read(1)
> -toggled = chr(ord(c) ^ bitmap_flag_unknown)
> +toggled = ord(c) ^ bitmap_flag_unknown
>   f.seek(-1, 1)
> -f.write(toggled)
> +try:
> +# python2
> +f.write(chr(toggled))
> +except TypeError:
> +# python3
> +f.write(bytes([toggled]))
>   
>   
>   qemu_img_create('-f', iotests.imgfmt, disk, '1M')
> 


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH] audio: don't use alsa by default

[David Hildenbrand]

On 19.02.19 11:15, Gerd Hoffmann wrote:
> ardware is present the driver initializes
> successfully and throws errors later on, i.e. effectively the
> automatic probing doesn't work.  So the driver should not be
> used by default (until that is fixed).  Drop the can_be_default
> flag.
> 
> Explicitly picking the alsa driver (using QEMU_AUDIO_DRV=alsa
> environment variable) will continue to work.

Just pointing out that with this patch, audio initialization still
hinders me from starting guests on my Fedora 29 when running under root
(I don't think this patch was also intended to fix that, just pointing
out for me the problem still exists).


ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
Connection refused

sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
Connection refused

sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
audio: Failed to create voice `pcspk'
qemu-system-x86_64: Initialization of device isa-pcspk failed:
Initializing audio voice failed


For whatever reason, on my Fedora29 root cannot access alsa devices.
Maybe it is a Fedora 29 problem, maybe only my setup is messed up (e.g.
because of an upgrade). The workaround for me is to not run QEMU as
root. (I don't have time to look into the details)

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 2/4] nbd/client: do negotiation in coroutine

[Vladimir Sementsov-Ogievskiy]

12.02.2019 0:38, Eric Blake wrote:
> On 2/11/19 6:55 AM, Vladimir Sementsov-Ogievskiy wrote:
>> As a first step to non-blocking negotiation, move it to coroutine.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>   nbd/client.c | 123 +--
>>   1 file changed, 109 insertions(+), 14 deletions(-)
>>
>> diff --git a/nbd/client.c b/nbd/client.c
>> index 10a52ad7d0..2ba2220a4a 100644
>> --- a/nbd/client.c
>> +++ b/nbd/client.c
>> @@ -859,13 +859,14 @@ static int nbd_list_meta_contexts(QIOChannel *ioc,
>>*  2: server is newstyle, but lacks structured replies
>>*  3: server is newstyle and set up for structured replies
>>*/
>> -static int nbd_start_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
>> -   const char *hostname, QIOChannel **outioc,
>> -   bool structured_reply, bool *zeroes,
>> -   Error **errp)
>> +static int coroutine_fn nbd_co_start_negotiate(
>> +QIOChannel *ioc, QCryptoTLSCreds *tlscreds, const char *hostname,
>> +QIOChannel **outioc, bool structured_reply, bool *zeroes, Error 
>> **errp)
>>   {
>>   uint64_t magic;
>>   
>> +assert(qemu_in_coroutine());
>> +
> 
> Do we need this assert, since this function is static, and only called by:

OK, I think this can be dropped

> 
>>   trace_nbd_start_negotiate(tlscreds, hostname ? hostname : "");
>>   
>>   if (zeroes) {
>> @@ -990,19 +991,20 @@ static int nbd_negotiate_finish_oldstyle(QIOChannel 
>> *ioc, NBDExportInfo *info,
>>* Returns: negative errno: failure talking to server
>>*  0: server is connected
>>*/
>> -int nbd_receive_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
>> -  const char *hostname, QIOChannel **outioc,
>> -  NBDExportInfo *info, Error **errp)
>> +static int coroutine_fn nbd_co_receive_negotiate(
>> +QIOChannel *ioc, QCryptoTLSCreds *tlscreds, const char *hostname,
>> +QIOChannel **outioc, NBDExportInfo *info, Error **errp)
>>   {
>>   int result;
>>   bool zeroes;
>>   bool base_allocation = info->base_allocation;
>>   
>> +assert(qemu_in_coroutine());
>>   assert(info->name);
>>   trace_nbd_receive_negotiate_name(info->name);
>>   
>> -result = nbd_start_negotiate(ioc, tlscreds, hostname, outioc,
>> - info->structured_reply, &zeroes, errp);
>> +result = nbd_co_start_negotiate(ioc, tlscreds, hostname, outioc,
>> +   info->structured_reply, &zeroes, errp);
> 
> other functions in the same file that have also made the same assertion?
>   For that matter, does the assert() add any value over the fact that we
> already annotated things as coroutine_fn?
> 
> I know that at some point, there was a proposal on the list for having
> the compiler enforce coroutine_fn annotations (ensuring that a
> coroutine_fn only calls other coroutine_fns, and that coroutines can
> only be started on an entry point properly marked), but that's a
> different task for another day.
> 

I thought, that converting function to be "coroutine_fn" (not creating a new 
one)
is a good reason to add an assertion.

> 
>> +static int nbd_receive_common(CoroutineEntry *entry,
>> +  NbdReceiveNegotiateCo *data)
>> +{
>> +data->ret = -EINPROGRESS;
>> +
>> +if (qemu_in_coroutine()) {
>> +entry(data);
>> +} else {
>> +AioContext *ctx = qio_channel_get_attached_aio_context(data->ioc);
>> +bool attach = !ctx;
> 
> There's where you used the function added in 1/4.
> 
>> +
>> +if (attach) {
>> +ctx = qemu_get_current_aio_context();
>> +qio_channel_attach_aio_context(data->ioc, ctx);
>> +}
>> +
>> +qemu_aio_coroutine_enter(ctx, qemu_coroutine_create(entry, data));
>> +AIO_WAIT_WHILE(ctx, data->ret == -EINPROGRESS);
>> +
>> +if (attach) {
>> +qio_channel_detach_aio_context(data->ioc);
>> +}
>> +}
>> +
>> +return data->ret;
>> +}
> 
> Looks reasonable.
> 
>> +
>> +int nbd_receive_negotiate(
>> +QIOChannel *ioc, QCryptoTLSCreds *tlscreds, const char *hostname,
>> +QIOChannel **outioc, NBDExportInfo *info, Error **errp)
>> +{
> 
> Why the reflowed parameter list, compared to its existing listing (as
> shown by the - lines where you added nbd_receive_co_negotiate)? That's
> only cosmetic, so I can live with it, but it seems like it makes the
> diff slightly larger.
> 

Hmm, maybe, will change it back.

-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH 3/4] nbd: do qemu_coroutine_yield during tls handshake

[Vladimir Sementsov-Ogievskiy]

12.02.2019 0:55, Eric Blake wrote:
> On 2/11/19 6:56 AM, Vladimir Sementsov-Ogievskiy wrote:
>> We always call qio_channel_tls_handshake in nbd from couroutine. Take
>> benefit of it and just yield instead of creating personal main loop.
>>
>> Mark and rename the function and it's callers correspondingly and
>> trace-points too.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>   nbd/client.c | 26 +-
>>   nbd/common.c |  6 ++
>>   nbd/server.c | 45 +
>>   nbd/trace-events | 15 +++
>>   4 files changed, 35 insertions(+), 57 deletions(-)
>>
>> diff --git a/nbd/client.c b/nbd/client.c
>> index 2ba2220a4a..e3919be30e 100644
>> --- a/nbd/client.c
>> +++ b/nbd/client.c
>> @@ -578,13 +578,14 @@ static int nbd_request_simple_option(QIOChannel *ioc, 
>> int opt, Error **errp)
>>   return 1;
>>   }
>>   
>> -static QIOChannel *nbd_receive_starttls(QIOChannel *ioc,
>> -QCryptoTLSCreds *tlscreds,
>> -const char *hostname, Error **errp)
>> +static QIOChannel *nbd_co_receive_starttls(
> 
> Missing coroutine_fn ?

hmm, yes.

> 
>> +QIOChannel *ioc, QCryptoTLSCreds *tlscreds, const char *hostname,
>> +Error **errp)
>>   {
>>   int ret;
>>   QIOChannelTLS *tioc;
>> -struct NBDTLSHandshakeData data = { 0 };
>> +
>> +assert(qemu_in_coroutine());
> 
> Again, I'm not sure these assertions add much.
> 
>>   
>>   ret = nbd_request_simple_option(ioc, NBD_OPT_STARTTLS, errp);
> 
> Should we also be marking these helper functions as coroutine_fn by the
> end of the series, once all callers are marked that way?

I think, not. It still may be called from non-coroutine context.

> 
>>   if (ret <= 0) {
>> @@ -601,23 +602,13 @@ static QIOChannel *nbd_receive_starttls(QIOChannel 
>> *ioc,
>>   return NULL;
>>   }
>>   qio_channel_set_name(QIO_CHANNEL(tioc), "nbd-client-tls");
>> -data.loop = g_main_loop_new(g_main_context_default(), FALSE);
>>   trace_nbd_receive_starttls_tls_handshake();
>>   qio_channel_tls_handshake(tioc,
>> nbd_tls_handshake,
>> -  &data,
>> +  qemu_coroutine_self(),
>> NULL,
>> NULL);
>> -
>> -if (!data.complete) {
>> -g_main_loop_run(data.loop);
>> -}
>> -g_main_loop_unref(data.loop);
>> -if (data.error) {
>> -error_propagate(errp, data.error);
>> -object_unref(OBJECT(tioc));
>> -return NULL;
>> -}
>> +qemu_coroutine_yield();
> 
> Nice.
> 
>> +++ b/nbd/server.c
>> @@ -668,16 +668,15 @@ static int nbd_negotiate_handle_info(NBDClient 
>> *client, uint16_t myflags,
>>   
>>   /* Handle NBD_OPT_STARTTLS. Return NULL to drop connection, or else the
>>* new channel for all further (now-encrypted) communication. */
>> -static QIOChannel *nbd_negotiate_handle_starttls(NBDClient *client,
>> - Error **errp)
>> +static QIOChannel coroutine_fn *nbd_co_negotiate_handle_starttls(
> 
> Awkward split of the return type; the coroutine_fn should instead be
> placed after the *, as in:

Oops, agree.

> 
> block/mirror.c:static MirrorOp *coroutine_fn active_write_prepare(...
> 
>> +NBDClient *client, Error **errp)
>>   {
>>   QIOChannel *ioc;
>>   QIOChannelTLS *tioc;
>> -struct NBDTLSHandshakeData data = { 0 };
> 
> All uses of this type have been deleted; you should also remove it from
> nbd-internal.h.

OK

> 
> 
>> @@ -1093,7 +1082,7 @@ static int nbd_negotiate_options(NBDClient *client, 
>> uint16_t myflags,
>>   return -EINVAL;
>>   }
>>   
>> -trace_nbd_negotiate_options_check_option(option,
>> +trace_nbd_co_negotiate_options_check_option(option,
>>nbd_opt_lookup(option));
> 
> Indentation looks off.
> 


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH v4 08/11] virtio: event suppression support for packed ring

[Wei Xu]

On Tue, Feb 19, 2019 at 03:19:58PM +0800, Jason Wang wrote:
> 
> On 2019/2/14 下午12:26, w...@redhat.com wrote:
> >From: Wei Xu 
> >
> >Difference between 'avail_wrap_counter' and 'last_avail_wrap_counter':
> >For Tx(guest transmitting), they are the same after each pop of a desc.
> >
> >For Rx(guest receiving), they are also the same when there are enough
> >descriptors to carry the payload for a packet(e.g. usually 16 descs are
> >needed for a 64k packet in typical iperf tcp connection with tso enabled),
> >however, when the ring is running out of descriptors while there are
> >still a few free ones, e.g. 6 descriptors are available which is not
> >enough to carry an entire packet which needs 16 descriptors, in this
> >case the 'avail_wrap_counter' should be set as the first one pending
> >being handled by guest driver in order to get a notification, and the
> >'last_avail_wrap_counter' should stay unchanged to the head of available
> >descriptors, like below:
> >
> >Mark meaning:
> > | | -- available
> > |*| -- used
> >
> >A Snapshot of the queue:
> >   last_avail_idx = 253
> >   last_avail_wrap_counter = 1
> >  |
> > +-+
> >  0  | | | |*|*|*|*|*|*|*|*|*|*|*|*|*|*|*|*|*| | | | 255
> > +-+
> >|
> >   shadow_avail_idx = 3
> >   avail_wrap_counter = 0
> 
> 
> Well this might not be the good place to describe the difference between
> shadow_avail_idx and last_avail_idx. And the comments above their definition
> looks good enough?

Sorry, I do not get it, can you elaborate more? 

This is one of the buggy parts of packed ring, it is good to make it clear here.

> 
>     /* Next head to pop */
>     uint16_t last_avail_idx;
> 
>     /* Last avail_idx read from VQ. */
>     uint16_t shadow_avail_idx;
> 

What is the meaning of these comment? Do you mean I should replace put them 
to the comments also? thanks.

> Instead, how or why need event suppress is not mentioned ...

Yes, but presumably this knowledge has been acquired from reading through the
spec, so I skipped this part.

Wei

> 
> 
> 
> >
> >Signed-off-by: Wei Xu 
> >---
> >  hw/virtio/virtio.c | 137 
> > +
> >  1 file changed, 128 insertions(+), 9 deletions(-)
> >
> >diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> >index 7e276b4..8cfc7b6 100644
> >--- a/hw/virtio/virtio.c
> >+++ b/hw/virtio/virtio.c
> >@@ -234,6 +234,34 @@ static void vring_desc_read(VirtIODevice *vdev, 
> >VRingDesc *desc,
> >  virtio_tswap16s(vdev, &desc->next);
> >  }
> >+static void vring_packed_event_read(VirtIODevice *vdev,
> >+MemoryRegionCache *cache, VRingPackedDescEvent 
> >*e)
> >+{
> >+address_space_read_cached(cache, 0, e, sizeof(*e));
> >+virtio_tswap16s(vdev, &e->off_wrap);
> >+virtio_tswap16s(vdev, &e->flags);
> >+}
> >+
> >+static void vring_packed_off_wrap_write(VirtIODevice *vdev,
> >+MemoryRegionCache *cache, uint16_t off_wrap)
> >+{
> >+virtio_tswap16s(vdev, &off_wrap);
> >+address_space_write_cached(cache, offsetof(VRingPackedDescEvent, 
> >off_wrap),
> >+&off_wrap, sizeof(off_wrap));
> >+address_space_cache_invalidate(cache,
> >+offsetof(VRingPackedDescEvent, off_wrap), sizeof(off_wrap));
> >+}
> >+
> >+static void vring_packed_flags_write(VirtIODevice *vdev,
> >+MemoryRegionCache *cache, uint16_t flags)
> >+{
> >+virtio_tswap16s(vdev, &flags);
> >+address_space_write_cached(cache, offsetof(VRingPackedDescEvent, flags),
> >+&flags, sizeof(flags));
> >+address_space_cache_invalidate(cache,
> >+offsetof(VRingPackedDescEvent, flags), 
> >sizeof(flags));
> >+}
> >+
> >  static VRingMemoryRegionCaches *vring_get_region_caches(struct VirtQueue 
> > *vq)
> >  {
> >  VRingMemoryRegionCaches *caches = atomic_rcu_read(&vq->vring.caches);
> >@@ -340,14 +368,8 @@ static inline void vring_set_avail_event(VirtQueue *vq, 
> >uint16_t val)
> >  address_space_cache_invalidate(&caches->used, pa, sizeof(val));
> >  }
> >-void virtio_queue_set_notification(VirtQueue *vq, int enable)
> >+static void virtio_queue_set_notification_split(VirtQueue *vq, int enable)
> >  {
> >-vq->notification = enable;
> >-
> >-if (!vq->vring.desc) {
> >-return;
> >-}
> >-
> >  rcu_read_lock();
> >  if (virtio_vdev_has_feature(vq->vdev, VIRTIO_RING_F_EVENT_IDX)) {
> >  vring_set_avail_event(vq, vring_avail_idx(vq));
> >@@ -363,6 +385,57 @@ void virtio_queue_set_notification(VirtQueue *vq, int 
> >enable)
> >  rcu_read_unlock();
> >  }
> >+static void virtio_queue_set_notification_packed(VirtQueue *vq, int enable)
> >+{
> >+VRingPackedDescEvent e;
> >+ 

Re: [Qemu-devel] Failing qemu-iotest 233

[Daniel P . Berrangé]

On Tue, Feb 19, 2019 at 07:36:07AM +0100, Thomas Huth wrote:
> 
>  Hi Eric, hi Daniel,
> 
> QEMU iotest 233 is failing for me on RHEL7:
> 
> 233[07:29:30] [07:29:30] [failed, exit status 1] - output 
> mismatch (see 233.out.bad)
> --- /home/thuth/devel/qemu/tests/qemu-iotests/233.out 2019-02-19 
> 07:14:45.0 +0100
> +++ /home/thuth/tmp/qemu-build/tests/qemu-iotests/233.out.bad 2019-02-19 
> 07:29:30.0 +0100
> @@ -13,45 +13,7 @@
>  1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>  
>  == check TLS client to plain server fails ==
> -qemu-img: Could not open 
> 'driver=nbd,host=127.0.0.1,port=PORT,tls-creds=tls0': Denied by server for 
> option 5 (starttls)
> -server reported: TLS not configured
> -qemu-nbd: Denied by server for option 5 (starttls)
> -server reported: TLS not configured
> +qemu-nbd: Unable to import client certificate 
> /tmp/qemu-iotests-quick-28354/tls/client1/client-cert.pem: Base64 unexpected 
> header error.

This is fun, because it is actually non-determinstic, failing in a different
place in the test everytime it is run !

Turns out that piping certtool to "head -1" is bad because it causes
certtool to get a broken pipe making it quit before it has written
the certificate to disk leaving a zero length file. This in turn
causes the base64 error above.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] Object instantiation vs. device realization: what to do when?

[Igor Mammedov]

On Thu, 14 Feb 2019 17:58:06 +0100
Paolo Bonzini  wrote:

> On 14/02/19 17:21, Markus Armbruster wrote:
> >  * As an interim step, the #DeviceState:realized property can also be
> >  * set with qdev_init_nofail().
> >  * In the future, devices will propagate this state change to their children
> >  * and along busses they expose.
> > 
> > This sentence is five years old.  Any progress?  If not, any intentions
> > to make progress?  
> 
> Good news, it's done!  What we still don't do is removing
> qdev_init_nofail and realizing the whole machine in one fell swoop.
> 
> Bad news, it's been done for five years:
> 
> commit 5c21ce77d7e5643089ceec556c0408445d017f32
> Author: Bandan Das 
> Date:   Wed Mar 12 21:02:12 2014 +0100
> 
> qdev: Realize buses on device realization
> 
> Integrate (un)realization of child buses with
> realization/unrealization
> of the device hosting them. Code in device_unparent() is reordered
> for unrealization of buses to work as part of device unrealization.
> 
> That way no changes need to be made to bus instantiation.
> 
> Signed-off-by: Bandan Das 
> Signed-off-by: Andreas Färber 
> 
> so I don't expect that the next step will ever happen...

that isn't really used (realize part) last time we've looked at it
https://www.mail-archive.com/qemu-devel@nongnu.org/msg570424.html


> >  * The point in time will be deferred to machine creation, so that values
> >  * set in @realize will not be introspectable beforehand. Therefore devices
> >  * must not create children during @realize; they should initialize them via
> >  * object_initialize() in their own #TypeInfo.instance_init and forward the
> >  * realization events appropriately.
> > 
> > This is mostly greek to me.  Pity the developer who knows less about
> > qdev than I do.  
> 
> The first part refers to what virtio_instance_init_common does:
> 
> object_initialize(vdev, vdev_size, vdev_name);
> object_property_add_child(proxy_obj, "virtio-backend", OBJECT(vdev),
>   NULL);
> object_unref(OBJECT(vdev));
> 
> The second part doesn't apply to virtio because it has a bus (so the
> code from the above commit handles recursive realization automatically).
> 
> hw/sd/milkymist-memcard.c has an example of this:
> 
> object_property_set_bool(OBJECT(carddev), true, "realized", &err);
> 
> but it should create the device in milkymist_memcard_init rather than
> milkymist_memcard_realize, in order to obey the directives of the sacred
> book of QEMU.
> 
> Paolo
> 

Re: [Qemu-devel] [PATCH v4 09/11] virtio-net: update the head descriptor in a chain lastly

[Wei Xu]

On Tue, Feb 19, 2019 at 03:23:01PM +0800, Jason Wang wrote:
> 
> On 2019/2/14 下午12:26, w...@redhat.com wrote:
> >From: Wei Xu 
> >
> >This is a helper for packed ring.
> >
> >To support packed ring, the head descriptor in a chain should be updated
> >lastly since no 'avail_idx' like in packed ring to explicitly tell the
> >driver side that all payload is ready after having done the chain, so
> >the head is always visible immediately.
> >
> >This patch fills the header after done all the other ones.
> >
> >Signed-off-by: Wei Xu 
> 
> 
> It's really odd to workaround API issue in the implementation of device.
> Please introduce batched used updating helpers instead.
Can you elaborate a bit more? I don't get it as well.

The exact batch as vhost-net or dpdk pmd is not supported by userspace
backend. The change here is to keep the header descriptor updated at
last in case of a chaining descriptors and the helper might not help
too much.

Wei
> 
> Thanks
> 
> 
> >---
> >  hw/net/virtio-net.c | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> >diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> >index 3f319ef..330abea 100644
> >--- a/hw/net/virtio-net.c
> >+++ b/hw/net/virtio-net.c
> >@@ -1251,6 +1251,8 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
> >*nc, const uint8_t *buf,
> >  struct virtio_net_hdr_mrg_rxbuf mhdr;
> >  unsigned mhdr_cnt = 0;
> >  size_t offset, i, guest_offset;
> >+VirtQueueElement head;
> >+int head_len = 0;
> >  if (!virtio_net_can_receive(nc)) {
> >  return -1;
> >@@ -1328,7 +1330,13 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
> >*nc, const uint8_t *buf,
> >  }
> >  /* signal other side */
> >-virtqueue_fill(q->rx_vq, elem, total, i++);
> >+if (i == 0) {
> >+head_len = total;
> >+head = *elem;
> >+} else {
> >+virtqueue_fill(q->rx_vq, elem, len, i);
> >+}
> >+i++;
> >  g_free(elem);
> >  }
> >@@ -1339,6 +1347,7 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
> >*nc, const uint8_t *buf,
> >   &mhdr.num_buffers, sizeof mhdr.num_buffers);
> >  }
> >+virtqueue_fill(q->rx_vq, &head, head_len, 0);
> >  virtqueue_flush(q->rx_vq, i);
> >  virtio_notify(vdev, q->rx_vq);
> 

Re: [Qemu-devel] [PATCH 2/5] vfio/migration: support device of device config capability

[Dr. David Alan Gilbert]

* Yan Zhao (yan.y.z...@intel.com) wrote:
> Device config is the default data that every device should have. so
> device config capability is by default on, no need to set.
> 
> - Currently two type of resources are saved/loaded for device of device
>   config capability:
>   General PCI config data, and Device config data.
>   They are copies as a whole when precopy is stopped.
> 
> Migration setup flow:
> - Setup device state regions, check its device state version and capabilities.
>   Mmap Device Config Region and Dirty Bitmap Region, if available.
> - If device state regions are failed to get setup, a migration blocker is
>   registered instead.
> - Added SaveVMHandlers to register device state save/load handlers.
> - Register VM state change handler to set device's running/stop states.
> - On migration startup on source machine, set device's state to
>   VFIO_DEVICE_STATE_LOGGING
> 
> Signed-off-by: Yan Zhao 
> Signed-off-by: Yulei Zhang 
> ---
>  hw/vfio/Makefile.objs |   2 +-
>  hw/vfio/migration.c   | 633 
> ++
>  hw/vfio/pci.c |   1 -
>  hw/vfio/pci.h |  25 +-
>  include/hw/vfio/vfio-common.h |   1 +
>  5 files changed, 659 insertions(+), 3 deletions(-)
>  create mode 100644 hw/vfio/migration.c
> 
> diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
> index 8b3f664..f32ff19 100644
> --- a/hw/vfio/Makefile.objs
> +++ b/hw/vfio/Makefile.objs
> @@ -1,6 +1,6 @@
>  ifeq ($(CONFIG_LINUX), y)
>  obj-$(CONFIG_SOFTMMU) += common.o
> -obj-$(CONFIG_PCI) += pci.o pci-quirks.o display.o
> +obj-$(CONFIG_PCI) += pci.o pci-quirks.o display.o migration.o
>  obj-$(CONFIG_VFIO_CCW) += ccw.o
>  obj-$(CONFIG_SOFTMMU) += platform.o
>  obj-$(CONFIG_VFIO_XGMAC) += calxeda-xgmac.o
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> new file mode 100644
> index 000..16d6395
> --- /dev/null
> +++ b/hw/vfio/migration.c
> @@ -0,0 +1,633 @@
> +#include "qemu/osdep.h"
> +
> +#include "hw/vfio/vfio-common.h"
> +#include "migration/blocker.h"
> +#include "migration/register.h"
> +#include "qapi/error.h"
> +#include "pci.h"
> +#include "sysemu/kvm.h"
> +#include "exec/ram_addr.h"
> +
> +#define VFIO_SAVE_FLAG_SETUP 0
> +#define VFIO_SAVE_FLAG_PCI 1
> +#define VFIO_SAVE_FLAG_DEVCONFIG 2
> +#define VFIO_SAVE_FLAG_DEVMEMORY 4
> +#define VFIO_SAVE_FLAG_CONTINUE 8
> +
> +static int vfio_device_state_region_setup(VFIOPCIDevice *vdev,
> +VFIORegion *region, uint32_t subtype, const char *name)
> +{
> +VFIODevice *vbasedev = &vdev->vbasedev;
> +struct vfio_region_info *info;
> +int ret;
> +
> +ret = vfio_get_dev_region_info(vbasedev, VFIO_REGION_TYPE_DEVICE_STATE,
> +subtype, &info);
> +if (ret) {
> +error_report("Failed to get info of region %s", name);
> +return ret;
> +}
> +
> +if (vfio_region_setup(OBJECT(vdev), vbasedev,
> +region, info->index, name)) {
> +error_report("Failed to setup migrtion region %s", name);
> +return ret;
> +}
> +
> +if (vfio_region_mmap(region)) {
> +error_report("Failed to mmap migrtion region %s", name);
> +}
> +
> +return 0;
> +}
> +
> +bool vfio_device_data_cap_system_memory(VFIOPCIDevice *vdev)
> +{
> +   return !!(vdev->migration->data_caps & 
> VFIO_DEVICE_DATA_CAP_SYSTEM_MEMORY);
> +}
> +
> +bool vfio_device_data_cap_device_memory(VFIOPCIDevice *vdev)
> +{
> +   return !!(vdev->migration->data_caps & 
> VFIO_DEVICE_DATA_CAP_DEVICE_MEMORY);
> +}
> +
> +static bool vfio_device_state_region_mmaped(VFIORegion *region)
> +{
> +bool mmaped = true;
> +if (region->nr_mmaps != 1 || region->mmaps[0].offset ||
> +(region->size != region->mmaps[0].size) ||
> +(region->mmaps[0].mmap == NULL)) {
> +mmaped = false;
> +}
> +
> +return mmaped;
> +}
> +
> +static int vfio_get_device_config_size(VFIOPCIDevice *vdev)
> +{
> +VFIODevice *vbasedev = &vdev->vbasedev;
> +VFIORegion *region_ctl =
> +&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
> +VFIORegion *region_config =
> +&vdev->migration->region[VFIO_DEVSTATE_REGION_DATA_CONFIG];
> +uint64_t len;
> +int sz;
> +
> +sz = sizeof(len);
> +if (pread(vbasedev->fd, &len, sz,
> +region_ctl->fd_offset +
> +offsetof(struct vfio_device_state_ctl, device_config.size))
> +!= sz) {
> +error_report("vfio: Failed to get length of device config");
> +return -1;
> +}
> +if (len > region_config->size) {
> +error_report("vfio: Error device config length");
> +return -1;
> +}
> +vdev->migration->devconfig_size = len;
> +
> +return 0;
> +}
> +
> +static int vfio_set_device_config_size(VFIOPCIDevice *vdev, uint64_t size)
> +{
> +VFIODevice *vbasedev = &vdev->vbasedev;
> +VFIORegion *region_ctl =
> +&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
> +VFIORegion *

Re: [Qemu-devel] [PATCH v4 10/11] virtio: migration support for packed ring

[Wei Xu]

On Tue, Feb 19, 2019 at 03:30:41PM +0800, Jason Wang wrote:
> 
> On 2019/2/14 下午12:26, w...@redhat.com wrote:
> >From: Wei Xu 
> >
> >Both userspace and vhost-net/user are supported with this patch.
> >
> >A new subsection is introduced for packed ring, only 'last_avail_idx'
> >and 'last_avail_wrap_counter' are saved/loaded presumably based on
> >all the others relevant data(inuse, used/avail index and wrap count
> >should be the same.
> 
> 
> This is probably only true for net device, see comment in virtio_load():
> 
>     /*
>  * Some devices migrate VirtQueueElements that have been popped
>  * from the avail ring but not yet returned to the used ring.
>  * Since max ring size < UINT16_MAX it's safe to use modulo
>  * UINT16_MAX + 1 subtraction.
>  */
>     vdev->vq[i].inuse = (uint16_t)(vdev->vq[i].last_avail_idx -
>     vdev->vq[i].used_idx);
> 
> 
> So you need to migrate used_idx and used_wrap_counter since we don't have
> used idx.

This is trying to align with vhost-net/user as we discussed, since all we
have done is to support  virtio-net device for packed ring, maybe we can
consider supporting other devices after we have got it verified.

> 
> 
> >
> >Signed-off-by: Wei Xu 
> >---
> >  hw/virtio/virtio.c | 69 
> > +++---
> >  1 file changed, 66 insertions(+), 3 deletions(-)
> >
> >diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> >index 8cfc7b6..7c5de07 100644
> >--- a/hw/virtio/virtio.c
> >+++ b/hw/virtio/virtio.c
> >@@ -2349,6 +2349,13 @@ static bool virtio_virtqueue_needed(void *opaque)
> >  return virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1);
> >  }
> >+static bool virtio_packed_virtqueue_needed(void *opaque)
> >+{
> >+VirtIODevice *vdev = opaque;
> >+
> >+return virtio_host_has_feature(vdev, VIRTIO_F_RING_PACKED);
> >+}
> >+
> >  static bool virtio_ringsize_needed(void *opaque)
> >  {
> >  VirtIODevice *vdev = opaque;
> >@@ -2390,6 +2397,17 @@ static const VMStateDescription vmstate_virtqueue = {
> >  }
> >  };
> >+static const VMStateDescription vmstate_packed_virtqueue = {
> >+.name = "packed_virtqueue_state",
> >+.version_id = 1,
> >+.minimum_version_id = 1,
> >+.fields = (VMStateField[]) {
> >+VMSTATE_UINT16(last_avail_idx, struct VirtQueue),
> >+VMSTATE_BOOL(last_avail_wrap_counter, struct VirtQueue),
> >+VMSTATE_END_OF_LIST()
> >+}
> >+};
> >+
> >  static const VMStateDescription vmstate_virtio_virtqueues = {
> >  .name = "virtio/virtqueues",
> >  .version_id = 1,
> >@@ -2402,6 +2420,18 @@ static const VMStateDescription 
> >vmstate_virtio_virtqueues = {
> >  }
> >  };
> >+static const VMStateDescription vmstate_virtio_packed_virtqueues = {
> >+.name = "virtio/packed_virtqueues",
> >+.version_id = 1,
> >+.minimum_version_id = 1,
> >+.needed = &virtio_packed_virtqueue_needed,
> >+.fields = (VMStateField[]) {
> >+VMSTATE_STRUCT_VARRAY_POINTER_KNOWN(vq, struct VirtIODevice,
> >+  VIRTIO_QUEUE_MAX, 0, vmstate_packed_virtqueue, 
> >VirtQueue),
> >+VMSTATE_END_OF_LIST()
> >+}
> >+};
> >+
> >  static const VMStateDescription vmstate_ringsize = {
> >  .name = "ringsize_state",
> >  .version_id = 1,
> >@@ -2522,6 +2552,7 @@ static const VMStateDescription vmstate_virtio = {
> >  &vmstate_virtio_ringsize,
> >  &vmstate_virtio_broken,
> >  &vmstate_virtio_extra_state,
> >+&vmstate_virtio_packed_virtqueues,
> >  NULL
> >  }
> >  };
> >@@ -2794,6 +2825,17 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f, int 
> >version_id)
> >  virtio_queue_update_rings(vdev, i);
> >  }
> >+if (virtio_vdev_has_feature(vdev, VIRTIO_F_RING_PACKED)) {
> >+vdev->vq[i].shadow_avail_idx = vdev->vq[i].last_avail_idx;
> >+vdev->vq[i].avail_wrap_counter =
> >+vdev->vq[i].last_avail_wrap_counter;
> >+
> >+vdev->vq[i].used_idx = vdev->vq[i].last_avail_idx;
> >+vdev->vq[i].used_wrap_counter =
> >+vdev->vq[i].last_avail_wrap_counter;
> >+continue;
> >+}
> >+
> >  nheads = vring_avail_idx(&vdev->vq[i]) - 
> > vdev->vq[i].last_avail_idx;
> >  /* Check it isn't doing strange things with descriptor 
> > numbers. */
> >  if (nheads > vdev->vq[i].vring.num) {
> >@@ -2955,17 +2997,34 @@ hwaddr virtio_queue_get_used_size(VirtIODevice 
> >*vdev, int n)
> >  uint16_t virtio_queue_get_last_avail_idx(VirtIODevice *vdev, int n)
> >  {
> >-return vdev->vq[n].last_avail_idx;
> >+uint16_t idx;
> >+
> >+if (virtio_vdev_has_feature(vdev, VIRTIO_F_RING_PACKED)) {
> >+idx = vdev->vq[n].last_avail_idx;
> >+idx |= ((int)vdev->vq[n].

Re: [Qemu-devel] [PATCH v3 4/6] vfio-ccw: add capabilities chain

[Cornelia Huck]

On Fri, 15 Feb 2019 10:46:08 -0500
Eric Farman  wrote:

> On 01/30/2019 08:22 AM, Cornelia Huck wrote:
> > Allow to extend the regions used by vfio-ccw. The first user will be
> > handling of halt and clear subchannel.
> > 
> > Signed-off-by: Cornelia Huck 
> > ---
> >   drivers/s390/cio/vfio_ccw_ops.c | 181 
> >   drivers/s390/cio/vfio_ccw_private.h |  38 ++
> >   include/uapi/linux/vfio.h   |   2 +
> >   3 files changed, 195 insertions(+), 26 deletions(-)

(...)

> > @@ -237,9 +301,51 @@ static int vfio_ccw_mdev_get_region_info(struct 
> > vfio_region_info *info,
> > info->flags = VFIO_REGION_INFO_FLAG_READ
> >   | VFIO_REGION_INFO_FLAG_WRITE;
> > return 0;
> > -   default:
> > -   return -EINVAL;
> > +   default: /* all other regions are handled via capability chain */
> > +   {
> > +   struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
> > +   struct vfio_region_info_cap_type cap_type = {
> > +   .header.id = VFIO_REGION_INFO_CAP_TYPE,
> > +   .header.version = 1 };
> > +   int ret;
> > +
> > +   if (info->index >=
> > +   VFIO_CCW_NUM_REGIONS + private->num_regions)
> > +   return -EINVAL;  
> 
> I notice the similarity of this hunk to drivers/vfio/pci/vfio_pci.c ... 
> While I was trying to discern the likelihood/possibility/usefulness of 
> combining the two, I noticed that there is one difference at this point 
> in the other file, which was added by commit 0e714d27786c ("vfio/pci: 
> Fix potential Spectre v1")
> 
> This got me off on a tangent of setting up smatch in my environment, and 
> sure enough it flags this point [1] as being problematic:
> 
> drivers/s390/cio/vfio_ccw_ops.c:328 vfio_ccw_mdev_get_region_info() 
> warn: potential spectre issue 'private->region' [r]

This makes sense, added.

> 
> Might need to consider the same?  (And lends credence to my concern 
> about the capability chain code being duplicated.)

Yeah, there's definitely duplication there. I initially tried to make
this use some common infrastructure, but I remember that it was harder
than it looked and that I stopped trying (don't remember the details,
sorry).

> 
> > +
> > +   i = info->index - VFIO_CCW_NUM_REGIONS;
> > +
> > +   info->offset = VFIO_CCW_INDEX_TO_OFFSET(info->index);
> > +   info->size = private->region[i].size;  
> 
> [1] smatch actually points to this line, though the referenced commit 
> inserts a line up there.
> 
> > +   info->flags = private->region[i].flags;
> > +
> > +   cap_type.type = private->region[i].type;
> > +   cap_type.subtype = private->region[i].subtype;
> > +
> > +   ret = vfio_info_add_capability(&caps, &cap_type.header,
> > +  sizeof(cap_type));
> > +   if (ret)
> > +   return ret;
> > +
> > +   info->flags |= VFIO_REGION_INFO_FLAG_CAPS;
> > +   if (info->argsz < sizeof(*info) + caps.size) {
> > +   info->argsz = sizeof(*info) + caps.size;
> > +   info->cap_offset = 0;
> > +   } else {
> > +   vfio_info_cap_shift(&caps, sizeof(*info));
> > +   if (copy_to_user((void __user *)arg + sizeof(*info),
> > +caps.buf, caps.size)) {
> > +   kfree(caps.buf);
> > +   return -EFAULT;
> > +   }
> > +   info->cap_offset = sizeof(*info);
> > +   }
> > +
> > +   kfree(caps.buf);
> > +
> > +   }
> > }
> > +   return 0;
> >   }

(...)

> > @@ -19,6 +21,38 @@
> >   #include "css.h"
> >   #include "vfio_ccw_cp.h"
> >   
> > +#define VFIO_CCW_OFFSET_SHIFT   40
> > +#define VFIO_CCW_OFFSET_TO_INDEX(off)  (off >> VFIO_CCW_OFFSET_SHIFT)
> > +#define VFIO_CCW_INDEX_TO_OFFSET(index)((u64)(index) << 
> > VFIO_CCW_OFFSET_SHIFT)
> > +#define VFIO_CCW_OFFSET_MASK   (((u64)(1) << VFIO_CCW_OFFSET_SHIFT) - 
> > 1)  
> 
> I know Farhan asked this back in v1, but I'd still love a better answer 
> than "vfio-pci did this" to what this is.  There's a lot more regions 
> prior to the capability chain in vfio-pci than here (9 versus 1), so I'd 
> like to be certain it's not related to that.

If we assume that we'll only add new regions via the capability chain
(and I think we can assume that), we can probably change that value. I
tried with a value of 10 (should be enough) and things still seem to
work, so that might be a nice, round value.

(...)

> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 02bb7ad6e986..56e2413d3e00 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -353,6 +353,8 @@ struct vfio_region_gfx_edid {
> >   #define VFIO_DEVICE_GFX_LINK_STATE_DOWN  2
> >   };
> >   
> > +#define VFIO_REGION_TYP

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Daniel P . Berrangé]

On Tue, Feb 19, 2019 at 10:37:16AM +0100, Kevin Wolf wrote:
> Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> > 
> >  https://gitlab.com/huth/qemu/-/jobs/163680780
> > 
> > Some of them apparently need encryption to be enabled (as already
> > mentioned by Cleber in his patch) - thus should they really be in the
> > quick check, too? Or could they at least check whether QEMU has been
> > built with encryption?
> 
> The correct solution would be that they detect the situation
> automatically and skip the test by calling _notrun.
> 
> I'm not sure how to detect if a given QEMU binary supports encryption,
> but Dan might know.

It isn't easy & depends which encryption feature you're trying to use.

For TLS related features you can do something gross like

qemu-img info --object tls-creds-anon,id=dummy README 2>&1
test $? != 0 && exit 0

This relies on fact that 'tls-creds-anon' object type will report a
runtime error during initialization if gnutls isn't enabled.

For more general ciphers you pretty much have to just try the higher level
feature and see if it fails.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 1/4] target/arm: Split out recompute_hflags et al

[Alex Bennée]

Richard Henderson  writes:

> We will use these to minimize the computation for every call to
> cpu_get_tb_cpu_state.  For now, the env->hflags variable is not used.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/cpu.h   |  22 +++-
>  target/arm/helper.h|   3 +
>  target/arm/internals.h |   3 +
>  target/arm/helper.c| 268 -
>  4 files changed, 180 insertions(+), 116 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 47238e4245..8b0dea947b 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -240,6 +240,9 @@ typedef struct CPUARMState {
>  uint32_t pstate;
>  uint32_t aarch64; /* 1 if CPU is in aarch64 state; inverse of PSTATE.nRW 
> */
>
> +/* Cached TBFLAGS state.  See below for which bits are included.  */
> +uint32_t hflags;
> +
>  /* Frequently accessed CPSR bits are stored separately for efficiency.
> This contains all the other bits.  Use cpsr_{read,write} to access
> the whole CPSR.  */
> @@ -3019,25 +3022,28 @@ static inline bool 
> arm_cpu_data_is_big_endian(CPUARMState *env)
>
>  #include "exec/cpu-all.h"
>
> -/* Bit usage in the TB flags field: bit 31 indicates whether we are
> +/*
> + * Bit usage in the TB flags field: bit 31 indicates whether we are
>   * in 32 or 64 bit mode. The meaning of the other bits depends on that.
>   * We put flags which are shared between 32 and 64 bit mode at the top
>   * of the word, and flags which apply to only one mode at the bottom.
> + *
> + * Unless otherwise noted, these bits are cached in env->hflags.
>   */
>  FIELD(TBFLAG_ANY, AARCH64_STATE, 31, 1)
>  FIELD(TBFLAG_ANY, MMUIDX, 28, 3)
>  FIELD(TBFLAG_ANY, SS_ACTIVE, 27, 1)
> -FIELD(TBFLAG_ANY, PSTATE_SS, 26, 1)
> +FIELD(TBFLAG_ANY, PSTATE_SS, 26, 1) /* Not cached. */
>  /* Target EL if we take a floating-point-disabled exception */
>  FIELD(TBFLAG_ANY, FPEXC_EL, 24, 2)
>  FIELD(TBFLAG_ANY, BE_DATA, 23, 1)
>
>  /* Bit usage when in AArch32 state: */
> -FIELD(TBFLAG_A32, THUMB, 0, 1)
> +FIELD(TBFLAG_A32, THUMB, 0, 1)  /* Not cached. */
>  FIELD(TBFLAG_A32, VECLEN, 1, 3)
>  FIELD(TBFLAG_A32, VECSTRIDE, 4, 2)
>  FIELD(TBFLAG_A32, VFPEN, 7, 1)
> -FIELD(TBFLAG_A32, CONDEXEC, 8, 8)
> +FIELD(TBFLAG_A32, CONDEXEC, 8, 8)   /* Not cached. */
>  FIELD(TBFLAG_A32, SCTLR_B, 16, 1)
>  /* We store the bottom two bits of the CPAR as TB flags and handle
>   * checks on the other bits at runtime
> @@ -3059,7 +3065,7 @@ FIELD(TBFLAG_A64, SVEEXC_EL, 2, 2)
>  FIELD(TBFLAG_A64, ZCR_LEN, 4, 4)
>  FIELD(TBFLAG_A64, PAUTH_ACTIVE, 8, 1)
>  FIELD(TBFLAG_A64, BT, 9, 1)
> -FIELD(TBFLAG_A64, BTYPE, 10, 2)
> +FIELD(TBFLAG_A64, BTYPE, 10, 2) /* Not cached. */
>  FIELD(TBFLAG_A64, TBID, 12, 2)
>
>  static inline bool bswap_code(bool sctlr_b)
> @@ -3144,6 +3150,12 @@ void arm_register_pre_el_change_hook(ARMCPU *cpu, 
> ARMELChangeHookFn *hook,
>  void arm_register_el_change_hook(ARMCPU *cpu, ARMELChangeHookFn *hook, void
>  *opaque);
>
> +/**
> + * arm_rebuild_hflags:
> + * Rebuild the cached TBFLAGS for arbitrary changed processor state.
> + */
> +void arm_rebuild_hflags(CPUARMState *env);
> +
>  /**
>   * aa32_vfp_dreg:
>   * Return a pointer to the Dn register within env in 32-bit mode.
> diff --git a/target/arm/helper.h b/target/arm/helper.h
> index 53a38188c6..e3c98913e6 100644
> --- a/target/arm/helper.h
> +++ b/target/arm/helper.h
> @@ -653,6 +653,9 @@ DEF_HELPER_FLAGS_6(gvec_fmla_idx_s, TCG_CALL_NO_RWG,
>  DEF_HELPER_FLAGS_6(gvec_fmla_idx_d, TCG_CALL_NO_RWG,
> void, ptr, ptr, ptr, ptr, ptr, i32)
>
> +DEF_HELPER_FLAGS_2(rebuild_hflags_a32, TCG_CALL_NO_RWG, void, env, i32)
> +DEF_HELPER_FLAGS_2(rebuild_hflags_a64, TCG_CALL_NO_RWG, void, env, i32)
> +
>  #ifdef TARGET_AARCH64
>  #include "helper-a64.h"
>  #include "helper-sve.h"
> diff --git a/target/arm/internals.h b/target/arm/internals.h
> index a4bd1becb7..8c1b813364 100644
> --- a/target/arm/internals.h
> +++ b/target/arm/internals.h
> @@ -968,4 +968,7 @@ ARMVAParameters aa64_va_parameters_both(CPUARMState *env, 
> uint64_t va,
>  ARMVAParameters aa64_va_parameters(CPUARMState *env, uint64_t va,
> ARMMMUIdx mmu_idx, bool data);
>
> +uint32_t rebuild_hflags_a32(CPUARMState *env, int el);
> +uint32_t rebuild_hflags_a64(CPUARMState *env, int el);
> +
>  #endif
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 520ceea7a4..7a77f53ba8 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -13745,122 +13745,15 @@ ARMMMUIdx arm_stage1_mmu_idx(CPUARMState *env)
>  }
>  #endif
>
> -void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
> -  target_ulong *cs_base, uint32_t *pflags)
> +static uint32_t common_hflags(CPUARMState *env, int el, ARMMMUIdx mmu_idx,
> +  int fp_el, uint32_t flags)
>  {
> -ARMMMUIdx mmu_idx = arm_mmu_idx(env);
> -int current_el = arm_current_el(env);
> - 

[Qemu-devel] [Bug 1808928] Re: Bitmap Extra data is not supported

[Ali Sag]

Sorry, because of log time, VM logs were removed. Journalctl for libvirtd is 
remain.. It was like that.
018-12-17 17:01:50.990+: 43198: error : qemuMonitorIORead:606 : Unable to 
read from monitor: Connection reset by peer
Dec 17 20:01:50 vm-kvm09 libvirtd[43198]: 2018-12-17 17:01:50.991+: 43198: 
error : qemuProcessReportLogError:1935 : internal error: qemu unexpectedly 
closed the monitor: .guest_agent.0 -chardev 
spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio
Dec 17 20:01:51 vm-kvm09 libvirtd[43198]: 2018-12-17T17:01:50.984315Z qemu-kvm: 
-drive 
file=/var/lib/libvirt/images/exo1-jb-h01-2.qcow2,format=qcow2,if=none,id=drive-virtio-disk1,cache=none:
 Bitmap extra data is not supported
Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.652+: 43203: 
warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.668+: 68990: 
warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.683+: 17099: 
warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.700+: 68889: 
warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.717+: 43200: 
warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.732+: 43202: 
warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
Dec 17 20:09:59 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:59.144+: 43198: 
error : qemuMonitorIORead:606 : Unable to read from monitor: Connection reset 
by peer
Dec 17 20:09:59 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:59.145+: 43198: 
error : qemuProcessReportLogError:1935 : internal error: qemu unexpectedly 
closed the monitor: 2018-12-17T17:09:59.132340Z qemu-kvm: -drive 
file=/var/lib/libvirt/images/exo1-jb-h01-2.qcow2,f...

I keep the broken image file. I run some qemu-img commands:

> qemu-img check /var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712
qemu-img: Could not open '/var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712': 
Bitmap extra data is not supported

> qemu-img info /var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712
qemu-img: Could not open '/var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712': 
Bitmap extra data is not supported

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

Title:
  Bitmap Extra data is not supported

Status in QEMU:
  New

Bug description:
  i am using dirty bitmaps and drive-backup. It works as aspected.

  Lately, i encounter a disastrous error. There is not any information
  about that situation. I cannot reach/open/attach/info or anything with
  a qcow2 file.

  virsh version
  Compiled against library: libvirt 4.10.0
  Using library: libvirt 4.10.0
  Using API: QEMU 4.10.0
  Running hypervisor: QEMU 2.12.0

  "qemu-img: Could not open '/var/lib/libvirt/images/test.qcow2': Bitmap
  extra data is not supported"

  what is that mean? what should i do?
  i cannot remove bitmap. i cannot open image or query.

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

Re: [Qemu-devel] [PATCH 07/12] nbd: Increase bs->in_flight during AioContext switch

[Kevin Wolf]

Am 18.02.2019 um 18:22 hat Paolo Bonzini geschrieben:
> On 18/02/19 17:18, Kevin Wolf wrote:
> > +/* aio_ctx_switch is only supposed to be set if we're sitting 
> > in
> > + * the qio_channel_yield() below. */
> > +assert(!*aio_ctx_switch);
> >  bdrv_dec_in_flight(bs);
> >  qio_channel_yield(ioc, G_IO_IN);
> > -bdrv_inc_in_flight(bs);
> > +if (*aio_ctx_switch) {
> > +/* nbd_client_attach_aio_context() already increased 
> > in_flight
> > + * when scheduling this coroutine for reentry */
> > +*aio_ctx_switch = false;
> > +} else {
> > +bdrv_inc_in_flight(bs);
> > +}
> 
> Hmm, my first thought would have been to do the bdrv_inc_in_flight(bs);
> unconditionally here, and in nbd_connection_entry do the opposite, like
> 
>   if (s->aio_ctx_switch) {
>   s->aio_ctx_switch = false;
>   bdrv_dec_in_flight(bs);
>   }
> 
> but I guess the problem is that then bdrv_drain could hang.

Yes, the important part is that in_flight can drop to 0 while we're in
qio_channel_yield().

> So my question is:
> 
> 1) is there a testcase that shows the problem with this "obvious"
> refactoring;

I haven't actually tried it out because it's "obviously" wrong, but in
any test case where no requests are running, you'd never leave this
loop, so it should trivially trigger the problem.

In other words, I think qemu-iotests 094 covers this.

> 2) maybe instead of aio_co_schedul-ing client->connection_co and having
> the s->aio_ctx_switch flag, you could go through a bottom half that does
> the bdrv_inc_in_flight and then enters client->connection_co?

That would be too easy. :-)

But I agree, that might indeed be the better solution.

I think I'd keep patch 6 anyway so that we know the exact yield that
we'll interrupt, even if it's not strictly necessary as long as we know
that nbd_receive_reply() can only yield in places that are safe to be
interrupted. While intuitively I think it's true, I don't feel like
actually auditing the code, and at some point we'd probably fail to
check that new code won't violate this invariant.

Kevin

Re: [Qemu-devel] [PATCH] audio: don't use alsa by default

[Daniel P . Berrangé]

On Tue, Feb 19, 2019 at 11:15:10AM +0100, Gerd Hoffmann wrote:
> In case no sound hardware is present the driver initializes
> successfully and throws errors later on, i.e. effectively the
> automatic probing doesn't work.  So the driver should not be
> used by default (until that is fixed).  Drop the can_be_default
> flag.
> 
> Explicitly picking the alsa driver (using QEMU_AUDIO_DRV=alsa
> environment variable) will continue to work.
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1816052
> Signed-off-by: Gerd Hoffmann 
> ---
>  audio/alsaaudio.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
> index 635be73bf4..1cc570e30b 100644
> --- a/audio/alsaaudio.c
> +++ b/audio/alsaaudio.c
> @@ -1218,7 +1218,6 @@ static struct audio_driver alsa_audio_driver = {
>  .init   = alsa_audio_init,
>  .fini   = alsa_audio_fini,
>  .pcm_ops= &alsa_pcm_ops,
> -.can_be_default = 1,
>  .max_voices_out = INT_MAX,
>  .max_voices_in  = INT_MAX,
>  .voice_size_out = sizeof (ALSAVoiceOut),

This fixes the problem with  alsa, but then we get exactly the same
problem with sdl audio iniitalizing but then not working.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH] audio: don't use alsa by default

[Daniel P . Berrangé]

On Tue, Feb 19, 2019 at 11:39:49AM +0100, David Hildenbrand wrote:
> On 19.02.19 11:15, Gerd Hoffmann wrote:
> > ardware is present the driver initializes
> > successfully and throws errors later on, i.e. effectively the
> > automatic probing doesn't work.  So the driver should not be
> > used by default (until that is fixed).  Drop the can_be_default
> > flag.
> > 
> > Explicitly picking the alsa driver (using QEMU_AUDIO_DRV=alsa
> > environment variable) will continue to work.
> 
> Just pointing out that with this patch, audio initialization still
> hinders me from starting guests on my Fedora 29 when running under root
> (I don't think this patch was also intended to fix that, just pointing
> out for me the problem still exists).
> 
> 
> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
> Connection refused
> 
> sdl: SDL_OpenAudio failed
> sdl: Reason: ALSA: Couldn't open audio device: Connection refused
> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
> Connection refused
> 
> sdl: SDL_OpenAudio failed
> sdl: Reason: ALSA: Couldn't open audio device: Connection refused
> audio: Failed to create voice `pcspk'
> qemu-system-x86_64: Initialization of device isa-pcspk failed:
> Initializing audio voice failed
> 
> 
> For whatever reason, on my Fedora29 root cannot access alsa devices.
> Maybe it is a Fedora 29 problem, maybe only my setup is messed up (e.g.
> because of an upgrade). The workaround for me is to not run QEMU as
> root. (I don't have time to look into the details)

Does your machine actually have any sound card in it ?  ie does
/dev/snd/ report any pcm*  devices ?

Based on your logs here, I suspect it has no sound card. The reason
it will work as non-root, is that QEMU will activate the pulseaudio
backend that works fine [1] even if no sound card is present.



Regards,
Daniel

[1] by "fine" I mean it'll happily accept the audio stream from the app
and send it to /dev/null :-)
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 11/12] block: Use normal drain for bdrv_set_aio_context()

[Kevin Wolf]

Am 18.02.2019 um 21:57 hat Eric Blake geschrieben:
> On 2/18/19 10:18 AM, Kevin Wolf wrote:
> > Now that bdrv_set_aio_context() works inside drained sections, it can
> > also use the real drain function instead of open coding something
> > similar.
> > 
> > Signed-off-by: Kevin Wolf 
> > ---
> >  block.c | 14 +-
> >  1 file changed, 5 insertions(+), 9 deletions(-)
> > 
> > diff --git a/block.c b/block.c
> > index aefb5701f5..7024172db8 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -5268,18 +5268,15 @@ void bdrv_attach_aio_context(BlockDriverState *bs,
> >  bs->walking_aio_notifiers = false;
> >  }
> >  
> > +/* The caller must own the AioContext lock for the old AioContext of bs, 
> > but it
> > + * must not own the AioContext lock for new_context. */
> 
> Is this comment still accurate, given
> 
> >  void bdrv_set_aio_context(BlockDriverState *bs, AioContext *new_context)
> >  {
> > -AioContext *ctx = bdrv_get_aio_context(bs);
> > -
> > -if (ctx == new_context) {
> > +if (bdrv_get_aio_context(bs) == new_context) {
> >  return;
> >  }
> 
> the short-circuiting when the old context is the new context?

Hm, yes, old == new is an exception where you quite obviously can't have
old locked and new unlocked at the same time.

So is adding this enough?

(unless new_context is the same as the current context of bs)

Kevin

Re: [Qemu-devel] [PATCH 5/5] vfio/migration: support device memory capability

[Dr. David Alan Gilbert]

* Yan Zhao (yan.y.z...@intel.com) wrote:
> If a device has device memory capability, save/load data from device memory
> in pre-copy and stop-and-copy phases.
> 
> LOGGING state is set for device memory for dirty page logging:
> in LOGGING state, get device memory returns whole device memory snapshot;
> outside LOGGING state, get device memory returns dirty data since last get
> operation.
> 
> Usually, device memory is very big, qemu needs to chunk it into several
> pieces each with size of device memory region.
> 
> Signed-off-by: Yan Zhao 
> Signed-off-by: Kirti Wankhede 
> ---
>  hw/vfio/migration.c | 235 
> ++--
>  hw/vfio/pci.h   |   1 +
>  2 files changed, 231 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index 16d6395..f1e9309 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -203,6 +203,201 @@ static int vfio_load_data_device_config(VFIOPCIDevice 
> *vdev,
>  return 0;
>  }
>  
> +static int vfio_get_device_memory_size(VFIOPCIDevice *vdev)
> +{
> +VFIODevice *vbasedev = &vdev->vbasedev;
> +VFIORegion *region_ctl =
> +&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
> +uint64_t len;
> +int sz;
> +
> +sz = sizeof(len);
> +if (pread(vbasedev->fd, &len, sz,
> +region_ctl->fd_offset +
> +offsetof(struct vfio_device_state_ctl, device_memory.size))
> +!= sz) {
> +error_report("vfio: Failed to get length of device memory");
> +return -1;
> +}
> +vdev->migration->devmem_size = len;
> +return 0;
> +}
> +
> +static int vfio_set_device_memory_size(VFIOPCIDevice *vdev, uint64_t size)
> +{
> +VFIODevice *vbasedev = &vdev->vbasedev;
> +VFIORegion *region_ctl =
> +&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
> +int sz;
> +
> +sz = sizeof(size);
> +if (pwrite(vbasedev->fd, &size, sz,
> +region_ctl->fd_offset +
> +offsetof(struct vfio_device_state_ctl, device_memory.size))
> +!= sz) {
> +error_report("vfio: Failed to set length of device comemory");
> +return -1;
> +}
> +vdev->migration->devmem_size = size;
> +return 0;
> +}
> +
> +static
> +int vfio_save_data_device_memory_chunk(VFIOPCIDevice *vdev, QEMUFile *f,
> +uint64_t pos, uint64_t len)
> +{
> +VFIODevice *vbasedev = &vdev->vbasedev;
> +VFIORegion *region_ctl =
> +&vdev->migration->region[VFIO_DEVSTATE_REGION_CTL];
> +VFIORegion *region_devmem =
> +&vdev->migration->region[VFIO_DEVSTATE_REGION_DATA_DEVICE_MEMORY];
> +void *dest;
> +uint32_t sz;
> +uint8_t *buf = NULL;
> +uint32_t action = VFIO_DEVICE_DATA_ACTION_GET_BUFFER;
> +
> +if (len > region_devmem->size) {
> +return -1;
> +}
> +
> +sz = sizeof(pos);
> +if (pwrite(vbasedev->fd, &pos, sz,
> +region_ctl->fd_offset +
> +offsetof(struct vfio_device_state_ctl, device_memory.pos))
> +!= sz) {
> +error_report("vfio: Failed to set save buffer pos");
> +return -1;
> +}
> +sz = sizeof(action);
> +if (pwrite(vbasedev->fd, &action, sz,
> +region_ctl->fd_offset +
> +offsetof(struct vfio_device_state_ctl, device_memory.action))
> +!= sz) {
> +error_report("vfio: Failed to set save buffer action");
> +return -1;
> +}
> +
> +if (!vfio_device_state_region_mmaped(region_devmem)) {
> +buf = g_malloc(len);
> +if (buf == NULL) {
> +error_report("vfio: Failed to allocate memory for migrate");
> +return -1;
> +}
> +if (pread(vbasedev->fd, buf, len, region_devmem->fd_offset) != len) {
> +error_report("vfio: error load device memory buffer");

That's forgotten to g_free(buf)

> +return -1;
> +}
> +qemu_put_be64(f, len);
> +qemu_put_be64(f, pos);
> +qemu_put_buffer(f, buf, len);
> +g_free(buf);
> +} else {
> +dest = region_devmem->mmaps[0].mmap;
> +qemu_put_be64(f, len);
> +qemu_put_be64(f, pos);
> +qemu_put_buffer(f, dest, len);
> +}
> +return 0;
> +}
> +
> +static int vfio_save_data_device_memory(VFIOPCIDevice *vdev, QEMUFile *f)
> +{
> +VFIORegion *region_devmem =
> +&vdev->migration->region[VFIO_DEVSTATE_REGION_DATA_DEVICE_MEMORY];
> +uint64_t total_len = vdev->migration->devmem_size;
> +uint64_t pos = 0;
> +
> +qemu_put_be64(f, total_len);
> +while (pos < total_len) {
> +uint64_t len = region_devmem->size;
> +
> +if (pos + len >= total_len) {
> +len = total_len - pos;
> +}
> +if (vfio_save_data_device_memory_chunk(vdev, f, pos, len)) {
> +return -1;
> +}
> +}
> +
> +return 0;
> +}
> +
> +static
> 

Re: [Qemu-devel] [PATCH] audio: don't use alsa by default

[David Hildenbrand]

On 19.02.19 12:17, Daniel P. Berrangé wrote:
> On Tue, Feb 19, 2019 at 11:39:49AM +0100, David Hildenbrand wrote:
>> On 19.02.19 11:15, Gerd Hoffmann wrote:
>>> ardware is present the driver initializes
>>> successfully and throws errors later on, i.e. effectively the
>>> automatic probing doesn't work.  So the driver should not be
>>> used by default (until that is fixed).  Drop the can_be_default
>>> flag.
>>>
>>> Explicitly picking the alsa driver (using QEMU_AUDIO_DRV=alsa
>>> environment variable) will continue to work.
>>
>> Just pointing out that with this patch, audio initialization still
>> hinders me from starting guests on my Fedora 29 when running under root
>> (I don't think this patch was also intended to fix that, just pointing
>> out for me the problem still exists).
>>
>>
>> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
>> Connection refused
>>
>> sdl: SDL_OpenAudio failed
>> sdl: Reason: ALSA: Couldn't open audio device: Connection refused
>> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
>> Connection refused
>>
>> sdl: SDL_OpenAudio failed
>> sdl: Reason: ALSA: Couldn't open audio device: Connection refused
>> audio: Failed to create voice `pcspk'
>> qemu-system-x86_64: Initialization of device isa-pcspk failed:
>> Initializing audio voice failed
>>
>>
>> For whatever reason, on my Fedora29 root cannot access alsa devices.
>> Maybe it is a Fedora 29 problem, maybe only my setup is messed up (e.g.
>> because of an upgrade). The workaround for me is to not run QEMU as
>> root. (I don't have time to look into the details)
> 
> Does your machine actually have any sound card in it ?  ie does
> /dev/snd/ report any pcm*  devices ?

Well, I can listen to audio, so I assume yes ;) Let's check

t460s: ~  $ ls -la /dev/snd/
insgesamt 0
drwxr-xr-x   4 root root  360 19. Feb 08:39 .
drwxr-xr-x  22 root root 4400 19. Feb 08:40 ..
drwxr-xr-x   2 root root   60 19. Feb 08:39 by-id
drwxr-xr-x   2 root root   80 19. Feb 08:39 by-path
crw-rw+  1 root audio 116,  3 19. Feb 08:39 controlC0
crw-rw+  1 root audio 116, 13 19. Feb 08:39 controlC1
crw-rw+  1 root audio 116, 11 19. Feb 08:39 hwC1D0
crw-rw+  1 root audio 116, 12 19. Feb 08:39 hwC1D2
crw-rw+  1 root audio 116,  2 19. Feb 08:40 pcmC0D0c
crw-rw+  1 root audio 116,  5 19. Feb 08:40 pcmC1D0c
crw-rw+  1 root audio 116,  4 19. Feb 11:40 pcmC1D0p
crw-rw+  1 root audio 116, 10 19. Feb 08:40 pcmC1D10p
crw-rw+  1 root audio 116,  6 19. Feb 08:40 pcmC1D3p
crw-rw+  1 root audio 116,  7 19. Feb 08:40 pcmC1D7p
crw-rw+  1 root audio 116,  8 19. Feb 08:40 pcmC1D8p
crw-rw+  1 root audio 116,  9 19. Feb 08:40 pcmC1D9p

> 
> Based on your logs here, I suspect it has no sound card. The reason
> it will work as non-root, is that QEMU will activate the pulseaudio
> backend that works fine [1] even if no sound card is present.

The thing is, I can play audio as normal user, but not as root

t460s: ~  $ LANG=C speaker-test -d default

speaker-test 1.1.6

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 192 to 2097152
Period size range from 64 to 699051
Using max buffer size 2097152
Periods = 4
was set period_size = 524288
was set buffer_size = 2097152
ALSA <-> PulseAudio PCM I/O Plugin

t460s: ~  $ LANG=C sudo speaker-test -d default

speaker-test 1.1.6

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
Connection refused


Again, this might be an issue on my system. But as I never touched any
of the configuration it either is broken on all Fedora 29 installations
or only on mine due to system upgrades. I already tried downgrading
pulse audio without luck.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v4 11/11] virtio: CLI and provide packed ring feature bit by default

[Wei Xu]

On Tue, Feb 19, 2019 at 03:32:19PM +0800, Jason Wang wrote:
> 
> On 2019/2/14 下午12:26, w...@redhat.com wrote:
> >From: Wei Xu 
> >
> >Add userspace and vhost kernel/user support.
> >
> >Add CLI "ring_packed=true/false" to enable/disable packed ring provision.
> >Usage:
> > -device virtio-net-pci,netdev=xx,mac=xx:xx:xx:xx:xx:xx,ring_packed=false
> >
> >By default it is provided.
> 
> 
> Please compat this for old machine types.

It is provided by default, how to make it compatible for old machine types?
Hide or provide it?

Wei

> 
> Thanks
> 
> 
> >
> >Signed-off-by: Wei Xu 
> >---
> >  hw/net/vhost_net.c | 2 ++
> >  include/hw/virtio/virtio.h | 4 +++-
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> >diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
> >index e037db6..f593086 100644
> >--- a/hw/net/vhost_net.c
> >+++ b/hw/net/vhost_net.c
> >@@ -53,6 +53,7 @@ static const int kernel_feature_bits[] = {
> >  VIRTIO_F_VERSION_1,
> >  VIRTIO_NET_F_MTU,
> >  VIRTIO_F_IOMMU_PLATFORM,
> >+VIRTIO_F_RING_PACKED,
> >  VHOST_INVALID_FEATURE_BIT
> >  };
> >@@ -78,6 +79,7 @@ static const int user_feature_bits[] = {
> >  VIRTIO_NET_F_MRG_RXBUF,
> >  VIRTIO_NET_F_MTU,
> >  VIRTIO_F_IOMMU_PLATFORM,
> >+VIRTIO_F_RING_PACKED,
> >  /* This bit implies RARP isn't sent by QEMU out of band */
> >  VIRTIO_NET_F_GUEST_ANNOUNCE,
> >diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> >index 9c1fa07..2eb27d2 100644
> >--- a/include/hw/virtio/virtio.h
> >+++ b/include/hw/virtio/virtio.h
> >@@ -264,7 +264,9 @@ typedef struct VirtIORNGConf VirtIORNGConf;
> >  DEFINE_PROP_BIT64("any_layout", _state, _field, \
> >VIRTIO_F_ANY_LAYOUT, true), \
> >  DEFINE_PROP_BIT64("iommu_platform", _state, _field, \
> >-  VIRTIO_F_IOMMU_PLATFORM, false)
> >+  VIRTIO_F_IOMMU_PLATFORM, false), \
> >+DEFINE_PROP_BIT64("ring_packed", _state, _field, \
> >+  VIRTIO_F_RING_PACKED, true)
> >  hwaddr virtio_queue_get_desc_addr(VirtIODevice *vdev, int n);
> >  hwaddr virtio_queue_get_avail_addr(VirtIODevice *vdev, int n);
> 

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Kevin Wolf]

Am 19.02.2019 um 12:06 hat Daniel P. Berrangé geschrieben:
> On Tue, Feb 19, 2019 at 10:37:16AM +0100, Kevin Wolf wrote:
> > Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> > > 
> > >  https://gitlab.com/huth/qemu/-/jobs/163680780
> > > 
> > > Some of them apparently need encryption to be enabled (as already
> > > mentioned by Cleber in his patch) - thus should they really be in the
> > > quick check, too? Or could they at least check whether QEMU has been
> > > built with encryption?
> > 
> > The correct solution would be that they detect the situation
> > automatically and skip the test by calling _notrun.
> > 
> > I'm not sure how to detect if a given QEMU binary supports encryption,
> > but Dan might know.
> 
> It isn't easy & depends which encryption feature you're trying to use.
> 
> For TLS related features you can do something gross like
> 
> qemu-img info --object tls-creds-anon,id=dummy README 2>&1
> test $? != 0 && exit 0
> 
> This relies on fact that 'tls-creds-anon' object type will report a
> runtime error during initialization if gnutls isn't enabled.
> 
> For more general ciphers you pretty much have to just try the higher level
> feature and see if it fails.

Actually, I think for test cases we should see 'qemu-img create' failing
and could just skip the test if it returns a non-zero exit code.

But then I looked at Thomas' output again:

--- /builds/huth/qemu/tests/qemu-iotests/188.out2019-02-19 
08:23:54.0 +
+++ /builds/huth/qemu/tests/qemu-iotests/188.out.bad2019-02-19 
08:34:54.0 +
@@ -1,4 +1,5 @@
 QA output created by 188
+qemu-img: TEST_DIR/t.IMGFMT: No crypto library supporting PBKDF in this 
build: Function not implemented
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 
encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10

 == reading whole image ==--- /builds/huth/qemu/tests/qemu-iotests/188.out  
2019-02-19 08:23:54.0 +

What is it actually doing there? There's clearly an error message, but
it almost looks like it's creating some kind of image anyway? The
following I/O works fine (i.e. this created image can even be opened
again with the luks driver), except that you can also access the image
with the wrong password.

Is this a real bug in either qcow2 or luks?

Kevin

Re: [Qemu-devel] [PATCH 0/5] QEMU VFIO live migration

[Dr. David Alan Gilbert]

* Yan Zhao (yan.y.z...@intel.com) wrote:
> This patchset enables VFIO devices to have live migration capability.
> Currently it does not support post-copy phase.
> 
> It follows Alex's comments on last version of VFIO live migration patches,
> including device states, VFIO device state region layout, dirty bitmap's
> query.

Hi,
  I've sent minor comments to later patches; but some minor general
comments:

  a) Never trust the incoming migrations stream - it might be corrupt,
so check when you can.
  b) How do we detect if we're migrating from/to the wrong device or
version of device?  Or say to a device with older firmware or perhaps
a device that has less device memory ?
  c) Consider using the trace_ mechanism - it's really useful to
add to loops writing/reading data so that you can see when it fails.

Dave

(P.S. You have a few typo's grep your code for 'devcie', 'devie' and
'migrtion'

> Device Data
> ---
> Device data is divided into three types: device memory, device config,
> and system memory dirty pages produced by device.
> 
> Device config: data like MMIOs, page tables...
> Every device is supposed to possess device config data.
>   Usually device config's size is small (no big than 10M), and it
> needs to be loaded in certain strict order.
> Therefore, device config only needs to be saved/loaded in
> stop-and-copy phase.
> The data of device config is held in device config region.
> Size of device config data is smaller than or equal to that of
> device config region.
> 
> Device Memory: device's internal memory, standalone and outside system
> memory. It is usually very big.
> This kind of data needs to be saved / loaded in pre-copy and
> stop-and-copy phase.
> The data of device memory is held in device memory region.
> Size of devie memory is usually larger than that of device
> memory region. qemu needs to save/load it in chunks of size of
> device memory region.
> Not all device has device memory. Like IGD only uses system memory.
> 
> System memory dirty pages: If a device produces dirty pages in system
> memory, it is able to get dirty bitmap for certain range of system
> memory. This dirty bitmap is queried in pre-copy and stop-and-copy
> phase in .log_sync callback. By setting dirty bitmap in .log_sync
> callback, dirty pages in system memory will be save/loaded by ram's
> live migration code.
> The dirty bitmap of system memory is held in dirty bitmap region.
> If system memory range is larger than that dirty bitmap region can
> hold, qemu will cut it into several chunks and get dirty bitmap in
> succession.
> 
> 
> Device State Regions
> 
> Vendor driver is required to expose two mandatory regions and another two
> optional regions if it plans to support device state management.
> 
> So, there are up to four regions in total.
> One control region: mandatory.
> Get access via read/write system call.
> Its layout is defined in struct vfio_device_state_ctl
> Three data regions: mmaped into qemu.
> device config region: mandatory, holding data of device config
> device memory region: optional, holding data of device memory
> dirty bitmap region: optional, holding bitmap of system memory
> dirty pages
> 
> (The reason why four seperate regions are defined is that the unit of mmap
> system call is PAGE_SIZE, i.e. 4k bytes. So one read/write region for
> control and three mmaped regions for data seems better than one big region
> padded and sparse mmaped).
> 
> 
> kernel device state interface [1]
> --
> #define VFIO_DEVICE_STATE_INTERFACE_VERSION 1
> #define VFIO_DEVICE_DATA_CAP_DEVICE_MEMORY 1
> #define VFIO_DEVICE_DATA_CAP_SYSTEM_MEMORY 2
> 
> #define VFIO_DEVICE_STATE_RUNNING 0 
> #define VFIO_DEVICE_STATE_STOP 1
> #define VFIO_DEVICE_STATE_LOGGING 2
> 
> #define VFIO_DEVICE_DATA_ACTION_GET_BUFFER 1
> #define VFIO_DEVICE_DATA_ACTION_SET_BUFFER 2
> #define VFIO_DEVICE_DATA_ACTION_GET_BITMAP 3
> 
> struct vfio_device_state_ctl {
>   __u32 version;/* ro */
>   __u32 device_state;   /* VFIO device state, wo */
>   __u32 caps;  /* ro */
> struct {
>   __u32 action;  /* wo, GET_BUFFER or SET_BUFFER */ 
>   __u64 size;/*rw*/
>   } device_config;
>   struct {
>   __u32 action;/* wo, GET_BUFFER or SET_BUFFER */ 
>   __u64 size; /* rw */  
> __u64 pos; /*the offset in total buffer of device memory*/
>   } device_memory;
>   struct {
>   __u64 start_addr; /* wo */
>   __u64 page_nr;   /* wo */
>   } system_memory;
> };
> 
> Devcie States
> - 
> After migration is initialzed, it will set device 

Re: [Qemu-devel] [Qemu-ppc] [PATCH 04/10] sam460ex: Don't size flash memory to match backing image

[BALATON Zoltan]

On Tue, 19 Feb 2019, Markus Armbruster wrote:

BALATON Zoltan  writes:

On Mon, 18 Feb 2019, Markus Armbruster wrote:

BALATON Zoltan  writes:

On Mon, 18 Feb 2019, Markus Armbruster wrote:

Machine "sam460ex" maps its flash memory at address 0xFFF0.  When
no image is supplied, its size is 1MiB (0x10).  Else, it's the
size of the image rounded up to the next multiple of 64KiB.

The rounding is actually useless: pflash_cfi01_realize() fails with
"failed to read the initial flash content" unless it's a no-op.

I have no idea what happens when the pflash's size exceeds 1MiB.
Useful outcomes seem unlikely.

I guess memory at the end of the address space remains unmapped when
it's smaller than 1MiB.  Again, useful outcomes seem unlikely.


I'm not sure where this was coming from but it predates my changes so
no idea either.


Set the flash memory size to 1MiB regardless of image size, to match
the physical hardware.


Actually the real hardware seems to have a 512 kB flash chip:
https://eu.mouser.com/datasheet/2/268/atmel_AT49BV040B-1180330.pdf


Fascinating.

 confirms.


so while you're at it you could change FLASH_SIZE to match that.


Leads to more questions, below.

[...]

Let's have a look at the resulting function:

   static int sam460ex_load_uboot(void)
   {
   DriveInfo *dinfo;

   dinfo = drive_get(IF_PFLASH, 0, 0);
   if (!pflash_cfi01_register(FLASH_BASE | ((hwaddr)FLASH_BASE_H << 32),
  "sam460ex.flash", FLASH_SIZE,
  dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,

[...]

  65536,
  1, 0x89, 0x18, 0x, 0x0, 1)) {
   error_report("Error registering flash memory");
   /* XXX: return an error instead? */
   exit(1);
   }

   if (!dinfo) {
   /*error_report("No flash image given with the 'pflash' parameter,"
   " using default u-boot image");*/
   rom_add_file_fixed(UBOOT_FILENAME,
  UBOOT_LOAD_BASE | ((hwaddr)FLASH_BASE_H << 32),
  -1);
   }

   return 0;
   }

This first creates 1MiB of flash memory mapped at the end of the 32-bit
address space (0xFFF0..0x).

If_PFLASH unit 0 is defined, the flash memory is initialized from that
block backend.

Else, it's initialized to zero.  And then 512KiB of ROM gets mapped on
top of its second half (0xFFF8..0x), initialized from
u-boot-sam460-20100605.bin (which we build).

This doesn't smell right.


Unfortunately I don't know much about how this should work. Maybe
François can remember where this comes from, this was already there
when I started working on it, but I suspect maybe he's copied it from
some other board in QEMU as well. The sam460ex was based on
ppc440_bamboo but that does not seem to have flash ROM. Memory SPD
EEPROM came from mips_malta (cleaned up since but it shows that that
was also used as inspiration) but that's also not the same so maybe it
was adapted for sam460ex or came from some other example in QEMU. This
was already there in François's initial commit:

https://github.com/mmuman/qemu/commit/d10cc631645f3893d53e60cc00c618470b4de52c#diff-73d06ebbc1301aab78105d853097fa2fR42

and later was slightly modified (maybe to rebase for changes in QEMU):

https://github.com/mmuman/qemu/commit/768136b08a6b9b69e707af2c478b68a5935bb8f0#diff-73d06ebbc1301aab78105d853097fa2fL1267

The comment says these values come from U-Boot:

https://git.qemu.org/?p=u-boot-sam460ex.git;a=blob;f=include/configs/Sam460ex.h;h=71064a9601c89dd3ce381d07e0def6c9d5294d44;hb=HEAD#l123

and that indeed has flash size of 1 MB but then builds an image that's
exactly 512 kB which should be mapped at end of 4GB because the
initial program counter of the CPU is 0xfffc and board has a 512kB
flash chip as well.


I propose to do the following: if IF_PFLASH unit 0 is defined, create
512KiB of flash memory mapped at the end of the 32-bit address space,
else, create 512KiB of ROM there.

Okay?


AFAIU the above U-Boot could handle up to 1MB of ROM but board has a
512kB chip so probably it makes sense to use 512k here. However since
this is not well understood (at least by me) I'm not asking you to do
that and maybe just leave it as it is now. This can be revisited when
NVRAM is implemented later as this may be related to that (or not)
this would need understanding of some details I don't have yet. But if
you feel confident enough to clean this up feel free to go ahead.


Then let's use my patch as is, plus a FIXME comment explaining the
situation.  Okay?


Yes, that would be fine.

Thank you,
BALATON Zoltan

Re: [Qemu-devel] [PATCH v4 07/11] virtio: fill/flush/pop for packed ring

[Wei Xu]

On Tue, Feb 19, 2019 at 05:33:57PM +0800, Jason Wang wrote:
> 
> On 2019/2/19 下午4:21, Wei Xu wrote:
> >On Tue, Feb 19, 2019 at 02:49:42PM +0800, Jason Wang wrote:
> >>On 2019/2/18 下午10:46, Wei Xu wrote:
> Do we allow chain more descriptors than vq size in the case of indirect?
> According to the spec:
> 
> "
> 
> The device limits the number of descriptors in a list through a
> transport-specific and/or device-specific value. If not limited,
> the maximum number of descriptors in a list is the virt queue
> size.
> "
> 
> This looks possible, so the above is probably wrong if the max number of
> chained descriptors is negotiated through a device specific way.
> 
> >>>OK, I will remove this check, while it is necessary to have a limitation
> >>>for indirect descriptor anyway, otherwise it is possible to hit an overflow
> >>>since presumably u16 is used for most number/size in the spec.
> >>>
> >>Please try to test block and scsi device for you changes as well.
> >Any idea about what kind of test should be covered? AFAICT, currently
> >packed ring is targeted for virtio-net as discussed during voting spec.
> >
> >Wei
> 
> 
> Well it's not only for net for sure, it should support all kinds of device.
> For testing, you should test basic function plus migration.

For sure we will support all the other devices, can we make it for
virtio-net device first and then move on to other devices?

Also, can anybody give me a CLI example for block and scsi devices?
I will give it a quick shot.

Wei

> 
> Thanks
> 
> 
> >
> >>Thanks
> >>
> >>
> 

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Kevin Wolf]

Am 19.02.2019 um 11:11 hat Thomas Huth geschrieben:
> On 19/02/2019 10.37, Kevin Wolf wrote:
> > Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> >> On 19/02/2019 08.53, Kevin Wolf wrote:
> [...]
> >>> Which are the cases that fail for you with '--disable-tcg'?
> >>
> >> These tests are failing: 087 169 188 232 235 238
> > 
> > Hm, 087 and 232 just do something like:
> > 
> > $QEMU_PROG -nodefaults -machine accel=qtest -nographic \
> >-qmp stdio -serial none \
> >...some -drive and -object options...
> > 
> > This should be fine with --disable-tcg, I think?
> > 
> > 169 runs a VM, but I don't see anything that makes it use TCG.
> > 
> > 188 doesn't even run QEMU at all, it's only qemu-io. I don't see how
> > this could be possibly related to --disable-tcg.
> 
> 087 and 188 obviously simply lack a check for the required crypto
> support.

Ah, okay, I thought you meant your whole list fails because of
--disable-tcg. Makes sense then.

> 169 got killed via abort():
> 
> 169[08:34:39] [08:34:46] [failed, exit status 1] - output 
> mismatch (see 169.out.bad)
> --- /builds/huth/qemu/tests/qemu-iotests/169.out  2019-02-19 
> 08:23:54.0 +
> +++ /builds/huth/qemu/tests/qemu-iotests/169.out.bad  2019-02-19 
> 08:34:46.0 +
> @@ -1,5 +1,29 @@
> -
> +WARNING:qemu:qemu received signal 6: 
> /builds/huth/qemu/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64 
> -chardev 
> socket,id=mon,path=/tmp/qemu-iotests-quick-25045/tmpGQOExQ/qemua-13044-monitor.sock
>  -mon chardev=mon,mode=control -display none -vga none -qtest 
> unix:path=/tmp/qemu-iotests-quick-25045/qemua-13044-qtest.sock -machine 
> accel=qtest -nodefaults -machine accel=qtest -drive 
> if=virtio,id=drive0,file=/tmp/qemu-iotests-quick-25045/disk_a,format=qcow2,cache=writeback
> [...]
> 
> No clue why.

In order to debug failures like this, I usually enable core dumps.

> 232 is also strange, no idea what is going on here:
> 
> 232[08:38:53] [08:38:56] - output mismatch (see 232.out.bad)
> --- /builds/huth/qemu/tests/qemu-iotests/232.out  2019-02-19 
> 08:23:54.0 +
> +++ /builds/huth/qemu/tests/qemu-iotests/232.out.bad  2019-02-19 
> 08:38:56.0 +
> @@ -21,13 +21,13 @@
>  NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>  NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>  
> -QEMU_PROG: -drive 
> driver=file,file=TEST_DIR/t.IMGFMT,if=none,read-only=off,auto-read-only=off: 
> Could not open 'TEST_DIR/t.IMGFMT': Permission denied
> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
> -
> -QEMU_PROG: -drive 
> driver=file,file=TEST_DIR/t.IMGFMT,if=none,auto-read-only=off: Could not open 
> 'TEST_DIR/t.IMGFMT': Permission denied
> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> +NODE_NAME: TEST_DIR/t.IMGFMT (file)

Do you run the tests as root? This messes with any tests that try to
test read-only cases because root can write to everything, no matter
what the permissions say.

> >> By the way, 235 and 238 also fail on my normal laptop with RHEL7:
> >> [...]
> >> Any ideas what might be going on here?
> > 
> > I think it's most likely that QEMU just prints an error message on
> > startup and exits.
> Right, I finally found the issue:
> 
> qemu-system-x86_64: -machine accel=kvm: No accelerator found
> 
> I apparently compiled my QEMU with --disable-kvm at one point in time and
> forgot to enable it later again. ==> These tests should really check whether
> KVM is available in QEMU before they blindly use this feature.

Ideally, they shouldn't use it at all.

Kevin

[Qemu-devel] [PATCH] qemu-img: fix error reporting for -object

[Daniel P . Berrangé]

Error reporting for user_creatable_add_opts_foreach was changed so that
it no longer called 'error_report_err' in:

  commit 7e1e0c11127bde81cff260fc6859690435c509d6
  Author: Markus Armbruster 
  Date:   Wed Oct 17 10:26:43 2018 +0200

qom: Clean up error reporting in user_creatable_add_opts_foreach()

Some callers were updated to pass in "&error_fatal" but all the ones in
qemu-img were left passing NULL. As a result all errors went to
/dev/null instead of being reported to the user.

Signed-off-by: Daniel P. Berrangé 
---
 qemu-img.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/qemu-img.c b/qemu-img.c
index 25288c4d18..903c37b706 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -503,7 +503,7 @@ static int img_create(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 goto fail;
 }
 
@@ -753,7 +753,7 @@ static int img_check(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 return 1;
 }
 
@@ -966,7 +966,7 @@ static int img_commit(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 return 1;
 }
 
@@ -1349,7 +1349,7 @@ static int img_compare(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 ret = 2;
 goto out4;
 }
@@ -2159,7 +2159,7 @@ static int img_convert(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 goto fail_getopt;
 }
 
@@ -2713,7 +2713,7 @@ static int img_info(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 return 1;
 }
 
@@ -2932,7 +2932,7 @@ static int img_map(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 return 1;
 }
 
@@ -3081,7 +3081,7 @@ static int img_snapshot(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 return 1;
 }
 
@@ -3241,7 +3241,7 @@ static int img_rebase(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 return 1;
 }
 
@@ -3621,7 +3621,7 @@ static int img_resize(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 return 1;
 }
 
@@ -3865,7 +3865,7 @@ static int img_amend(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 ret = -1;
 goto out_no_progress;
 }
@@ -4509,7 +4509,7 @@ static int img_dd(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 ret = -1;
 goto out;
 }
@@ -4786,7 +4786,7 @@ static int img_measure(int argc, char **argv)
 
 if (qemu_opts_foreach(&qemu_object_opts,
   user_creatable_add_opts_foreach,
-  NULL, NULL)) {
+  NULL, &error_fatal)) {
 goto out;
 }
 
-- 
2.20.1

[Qemu-devel] [PATCH] iotests: drop unnecessary accel=kvm

[Stefan Hajnoczi]

Tests 235 and 238 do not require the kvm accelerator.  TCG works fine.

Use the default accelerator instead of requiring kvm.

Suggested-by: Thomas Huth 
Signed-off-by: Stefan Hajnoczi 
---
 tests/qemu-iotests/235 | 1 -
 tests/qemu-iotests/238 | 1 -
 2 files changed, 2 deletions(-)

diff --git a/tests/qemu-iotests/235 b/tests/qemu-iotests/235
index d6edd97ab4..329da8f0c2 100755
--- a/tests/qemu-iotests/235
+++ b/tests/qemu-iotests/235
@@ -49,7 +49,6 @@ qemu_img_create('-f', iotests.imgfmt, '-o', 
'preallocation=metadata', disk,
 str(size))
 
 vm = QEMUMachine(iotests.qemu_prog)
-vm.add_args('-machine', 'accel=kvm')
 if iotests.qemu_default_machine == 's390-ccw-virtio':
 vm.add_args('-no-shutdown')
 vm.add_args('-drive', 'id=src,file=' + disk)
diff --git a/tests/qemu-iotests/238 b/tests/qemu-iotests/238
index f81ee1112f..e490bb4298 100755
--- a/tests/qemu-iotests/238
+++ b/tests/qemu-iotests/238
@@ -33,7 +33,6 @@ else:
 virtio_scsi_device = 'virtio-scsi-pci'
 
 vm = QEMUMachine(iotests.qemu_prog)
-vm.add_args('-machine', 'accel=kvm')
 vm.launch()
 
 log(vm.qmp('blockdev-add', node_name='hd0', driver='null-co'))
-- 
2.20.1

Re: [Qemu-devel] [PATCH] hw/display: Add basic ATI VGA emulation

[BALATON Zoltan]

On Tue, 19 Feb 2019, Gerd Hoffmann wrote:

On Mon, Feb 11, 2019 at 04:19:14AM +0100, BALATON Zoltan wrote:

At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
guests running on these and the PMON2000 firmware of the fulong2e
expect this to be available. Fortunately these are very similar chips
so they can be mostly emulated in the same device model. This patch
adds basic emulation of these ATI VGA chips.

While this is incomplete and currently only enough to run the MIPS
firmware and get console output with Linux,


Which linux driver is this?


Those in linux/drivers/video/fbdev/aty/. This ati-vga model defaults to 
Rage 128 Pro (what PoweMac3,1 has, device id 0x5046) which is handled by 
the aty128fb driver under Linux. MIPS fulong2e has Mobility Radeon M6 
(RV100, device id 0x5159) that you can also use as -device 
ati-vga,device_id=0x5159 which is driven by radeonfb under Linux.



If linux has a native driver it might make sense to also enable it on
x86.  Makes testing easier.


Yes it could work on all archs under Linux but I've only enabled it on the 
two I've tried. It could be added instead to the same place where vga is 
added in pci.mak if you like.



You can add the driver to default_list[] in vl.c, then you don't need
-vga none to remove the default vga when adding -device ati-vga.


I could do that but since it's a bit unfinished (lacks advanced features 
such as video overlay, 3D accel, command FIFO, etc.) and only a basic 
implementation at the moment to work with Linux framebuffer that doesn't 
use these features I thought it might be a godd idea to make it a bit 
harder to access yet to avoid problem of someone trying it with a Windows 
guest with drivers from ATI which probably will result in bad picture. But 
it's up to you to decide if you want to add it to -vga option from the 
start or have it as optional device and only add to -vga when it's more 
fully implemented and tested.


Regards,
BALATON Zoltan

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Daniel P . Berrangé]

On Tue, Feb 19, 2019 at 12:31:41PM +0100, Kevin Wolf wrote:
> Am 19.02.2019 um 12:06 hat Daniel P. Berrangé geschrieben:
> > On Tue, Feb 19, 2019 at 10:37:16AM +0100, Kevin Wolf wrote:
> > > Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> > > > 
> > > >  https://gitlab.com/huth/qemu/-/jobs/163680780
> > > > 
> > > > Some of them apparently need encryption to be enabled (as already
> > > > mentioned by Cleber in his patch) - thus should they really be in the
> > > > quick check, too? Or could they at least check whether QEMU has been
> > > > built with encryption?
> > > 
> > > The correct solution would be that they detect the situation
> > > automatically and skip the test by calling _notrun.
> > > 
> > > I'm not sure how to detect if a given QEMU binary supports encryption,
> > > but Dan might know.
> > 
> > It isn't easy & depends which encryption feature you're trying to use.
> > 
> > For TLS related features you can do something gross like
> > 
> > qemu-img info --object tls-creds-anon,id=dummy README 2>&1
> > test $? != 0 && exit 0
> > 
> > This relies on fact that 'tls-creds-anon' object type will report a
> > runtime error during initialization if gnutls isn't enabled.
> > 
> > For more general ciphers you pretty much have to just try the higher level
> > feature and see if it fails.
> 
> Actually, I think for test cases we should see 'qemu-img create' failing
> and could just skip the test if it returns a non-zero exit code.
> 
> But then I looked at Thomas' output again:
> 
> --- /builds/huth/qemu/tests/qemu-iotests/188.out  2019-02-19 
> 08:23:54.0 +
> +++ /builds/huth/qemu/tests/qemu-iotests/188.out.bad  2019-02-19 
> 08:34:54.0 +
> @@ -1,4 +1,5 @@
>  QA output created by 188
> +qemu-img: TEST_DIR/t.IMGFMT: No crypto library supporting PBKDF in this 
> build: Function not implemented
>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 
> encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
> 
>  == reading whole image ==--- 
> /builds/huth/qemu/tests/qemu-iotests/188.out2019-02-19 
> 08:23:54.0 +
> 
> What is it actually doing there? There's clearly an error message, but
> it almost looks like it's creating some kind of image anyway? The
> following I/O works fine (i.e. this created image can even be opened
> again with the luks driver), except that you can also access the image
> with the wrong password.
> 
> Is this a real bug in either qcow2 or luks?

It is an artifact of the way qcow2 image creation happens in multiple
phases. qcow2_co_create first creates a minimal qcow2 file, and then
opens it and updates it to add in the various extra features, including
luks encryption. We fail to create the luks encryption, but enough of
the qcow2 file has been created that it is able to still do plain text
I/O.

Essentially the problem is that qcow2_co_create() doesn't unlink() the
partially created image when things fail. This is a generic problem
which can affect any part of qcow2_co_create that might fail, but it
is especially problematic with luks.

The complication in fixing this is that can't just do an unlink() as
we can't assume a local file. We need to have a bdrv_unlink() driver
callback we can use to delegate to the right block driver APIs for
deletion.

This is something I think could be useful in general, to expose as a
"qemu-img delete" command - especially for non-local formats like
rbd, sheepdog, glusterfs the mgmt app can't simply run "rm $img".
QEMU already knows how to talk to the native APis for these network
drivers so can make life easier by exposing a 'delete' op.

For luks it would be desirable to allow options to the 'delete'
operation, for example to request scrubbing of the key material
headers.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH] iotests: drop unnecessary accel=kvm

[Thomas Huth]

On 19/02/2019 12.59, Stefan Hajnoczi wrote:
> Tests 235 and 238 do not require the kvm accelerator.  TCG works fine.
> 
> Use the default accelerator instead of requiring kvm.
> 
> Suggested-by: Thomas Huth 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  tests/qemu-iotests/235 | 1 -
>  tests/qemu-iotests/238 | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/tests/qemu-iotests/235 b/tests/qemu-iotests/235
> index d6edd97ab4..329da8f0c2 100755
> --- a/tests/qemu-iotests/235
> +++ b/tests/qemu-iotests/235
> @@ -49,7 +49,6 @@ qemu_img_create('-f', iotests.imgfmt, '-o', 
> 'preallocation=metadata', disk,
>  str(size))
>  
>  vm = QEMUMachine(iotests.qemu_prog)
> -vm.add_args('-machine', 'accel=kvm')

According to the initial commit log of 235:

 "iotests: simple mirror test with kvm on 1G image"

... so I assume KVM was used on purpose here?

 Thomas

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Daniel P . Berrangé]

On Tue, Feb 19, 2019 at 12:01:28PM +, Daniel P. Berrangé wrote:
> On Tue, Feb 19, 2019 at 12:31:41PM +0100, Kevin Wolf wrote:
> > Am 19.02.2019 um 12:06 hat Daniel P. Berrangé geschrieben:
> > > On Tue, Feb 19, 2019 at 10:37:16AM +0100, Kevin Wolf wrote:
> > > > Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> > > > > 
> > > > >  https://gitlab.com/huth/qemu/-/jobs/163680780
> > > > > 
> > > > > Some of them apparently need encryption to be enabled (as already
> > > > > mentioned by Cleber in his patch) - thus should they really be in the
> > > > > quick check, too? Or could they at least check whether QEMU has been
> > > > > built with encryption?
> > > > 
> > > > The correct solution would be that they detect the situation
> > > > automatically and skip the test by calling _notrun.
> > > > 
> > > > I'm not sure how to detect if a given QEMU binary supports encryption,
> > > > but Dan might know.
> > > 
> > > It isn't easy & depends which encryption feature you're trying to use.
> > > 
> > > For TLS related features you can do something gross like
> > > 
> > > qemu-img info --object tls-creds-anon,id=dummy README 2>&1
> > > test $? != 0 && exit 0
> > > 
> > > This relies on fact that 'tls-creds-anon' object type will report a
> > > runtime error during initialization if gnutls isn't enabled.
> > > 
> > > For more general ciphers you pretty much have to just try the higher level
> > > feature and see if it fails.
> > 
> > Actually, I think for test cases we should see 'qemu-img create' failing
> > and could just skip the test if it returns a non-zero exit code.
> > 
> > But then I looked at Thomas' output again:
> > 
> > --- /builds/huth/qemu/tests/qemu-iotests/188.out2019-02-19 
> > 08:23:54.0 +
> > +++ /builds/huth/qemu/tests/qemu-iotests/188.out.bad2019-02-19 
> > 08:34:54.0 +
> > @@ -1,4 +1,5 @@
> >  QA output created by 188
> > +qemu-img: TEST_DIR/t.IMGFMT: No crypto library supporting PBKDF in 
> > this build: Function not implemented
> >  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 
> > encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
> > 
> >  == reading whole image ==--- 
> > /builds/huth/qemu/tests/qemu-iotests/188.out  2019-02-19 
> > 08:23:54.0 +
> > 
> > What is it actually doing there? There's clearly an error message, but
> > it almost looks like it's creating some kind of image anyway? The
> > following I/O works fine (i.e. this created image can even be opened
> > again with the luks driver), except that you can also access the image
> > with the wrong password.
> > 
> > Is this a real bug in either qcow2 or luks?
> 
> It is an artifact of the way qcow2 image creation happens in multiple
> phases. qcow2_co_create first creates a minimal qcow2 file, and then
> opens it and updates it to add in the various extra features, including
> luks encryption. We fail to create the luks encryption, but enough of
> the qcow2 file has been created that it is able to still do plain text
> I/O.
> 
> Essentially the problem is that qcow2_co_create() doesn't unlink() the
> partially created image when things fail. This is a generic problem
> which can affect any part of qcow2_co_create that might fail, but it
> is especially problematic with luks.
> 
> The complication in fixing this is that can't just do an unlink() as
> we can't assume a local file. We need to have a bdrv_unlink() driver
> callback we can use to delegate to the right block driver APIs for
> deletion.

As a quick hack we could perhaps overwrite the qcow2 header with
garbage or all-zeros on failure to avoid it being mistakenly
interpreted as a valid qcow2 file on failure (could still be
mistakenly probed as raw but we tell people not to allow probing)


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH] hw/rdma: another clang compilation fix

[Marcel Apfelbaum]

Hi Philippe,

On 2/19/19 12:05 AM, Philippe Mathieu-Daudé wrote:

On 2/17/19 8:51 AM, Marcel Apfelbaum wrote:

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

I doubt this is a security issue worth Cc'ing qemu-stable :)



I thought it worth adding a compilation fix to the stable branch.

Thanks,
Marcel


Thanks,
Marcel

On 2/14/19 5:40 PM, Marcel Apfelbaum wrote:

Configuring QEMU with:
     configure --target-list="x86_64-softmmu" --cc=clang --enable-pvrdma
Results in:
     qemu/hw/rdma/rdma_rm_defs.h:108:3: error: redefinition of typedef
'RdmaDeviceResources' is a C11 feature [-Werror,-Wtypedef-redefinition]
     } RdmaDeviceResources;
   ^
     qemu/hw/rdma/rdma_backend_defs.h:24:36: note: previous definition
is here
     typedef struct RdmaDeviceResources RdmaDeviceResources;

Fix by removing one of the 'typedef' definitions.

Signed-off-by: Marcel Apfelbaum 

Reviewed-by: Philippe Mathieu-Daudé 


---
   hw/rdma/rdma_rm_defs.h | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/rdma/rdma_rm_defs.h b/hw/rdma/rdma_rm_defs.h
index 0ba61d1838..5e877c1fd9 100644
--- a/hw/rdma/rdma_rm_defs.h
+++ b/hw/rdma/rdma_rm_defs.h
@@ -96,7 +96,7 @@ typedef struct RdmaRmPort {
   enum ibv_port_state state;
   } RdmaRmPort;
   -typedef struct RdmaDeviceResources {
+struct RdmaDeviceResources {
   RdmaRmPort port;
   RdmaRmResTbl pd_tbl;
   RdmaRmResTbl mr_tbl;
@@ -105,6 +105,6 @@ typedef struct RdmaDeviceResources {
   RdmaRmResTbl cq_tbl;
   RdmaRmResTbl cqe_ctx_tbl;
   GHashTable *qp_hash; /* Keeps mapping between real and emulated */
-} RdmaDeviceResources;
+};
     #endif

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Thomas Huth]

On 19/02/2019 12.38, Kevin Wolf wrote:
> Am 19.02.2019 um 11:11 hat Thomas Huth geschrieben:
>> On 19/02/2019 10.37, Kevin Wolf wrote:
>>> Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
 On 19/02/2019 08.53, Kevin Wolf wrote:
[...]
>> 169 got killed via abort():
>>
>> 169[08:34:39] [08:34:46] [failed, exit status 1] - output 
>> mismatch (see 169.out.bad)
>> --- /builds/huth/qemu/tests/qemu-iotests/169.out 2019-02-19 
>> 08:23:54.0 +
>> +++ /builds/huth/qemu/tests/qemu-iotests/169.out.bad 2019-02-19 
>> 08:34:46.0 +
>> @@ -1,5 +1,29 @@
>> -
>> +WARNING:qemu:qemu received signal 6: 
>> /builds/huth/qemu/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64 
>> -chardev 
>> socket,id=mon,path=/tmp/qemu-iotests-quick-25045/tmpGQOExQ/qemua-13044-monitor.sock
>>  -mon chardev=mon,mode=control -display none -vga none -qtest 
>> unix:path=/tmp/qemu-iotests-quick-25045/qemua-13044-qtest.sock -machine 
>> accel=qtest -nodefaults -machine accel=qtest -drive 
>> if=virtio,id=drive0,file=/tmp/qemu-iotests-quick-25045/disk_a,format=qcow2,cache=writeback
>> [...]
>>
>> No clue why.
> 
> In order to debug failures like this, I usually enable core dumps.

It's only failing for me on the gitlab-CI system. I don't think that
I've got the possibility to grab coredumps there...

>> 232 is also strange, no idea what is going on here:
>>
>> 232[08:38:53] [08:38:56] - output mismatch (see 232.out.bad)
>> --- /builds/huth/qemu/tests/qemu-iotests/232.out 2019-02-19 
>> 08:23:54.0 +
>> +++ /builds/huth/qemu/tests/qemu-iotests/232.out.bad 2019-02-19 
>> 08:38:56.0 +
>> @@ -21,13 +21,13 @@
>>  NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>>  NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>>  
>> -QEMU_PROG: -drive 
>> driver=file,file=TEST_DIR/t.IMGFMT,if=none,read-only=off,auto-read-only=off: 
>> Could not open 'TEST_DIR/t.IMGFMT': Permission denied
>> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>> -
>> -QEMU_PROG: -drive 
>> driver=file,file=TEST_DIR/t.IMGFMT,if=none,auto-read-only=off: Could not 
>> open 'TEST_DIR/t.IMGFMT': Permission denied
>> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> 
> Do you run the tests as root? This messes with any tests that try to
> test read-only cases because root can write to everything, no matter
> what the permissions say.

I don't know whether gitlab runs the CI pipelines as root, but I doubt
it. Looking at the shell "prompts" that they show inbetween ("$") it
looks like they are running the CI tests as a normal user, though.

 By the way, 235 and 238 also fail on my normal laptop with RHEL7:
 [...]
 Any ideas what might be going on here?
>>>
>>> I think it's most likely that QEMU just prints an error message on
>>> startup and exits.
>> Right, I finally found the issue:
>>
>> qemu-system-x86_64: -machine accel=kvm: No accelerator found
>>
>> I apparently compiled my QEMU with --disable-kvm at one point in time and
>> forgot to enable it later again. ==> These tests should really check whether
>> KVM is available in QEMU before they blindly use this feature.
> 
> Ideally, they shouldn't use it at all.

235 seems to use KVM on purpose according to the commit description...?

But maybe we can change it to "-M accel=kvm:qtest" somehow ... though
this currently seems to hang the test, as far as I can see... Maybe
"accel=kvm:tcg", so that it works at least without kvm?

According to Stefan, 238 does not need KVM at all (see his patch that he
just sent).

 Thomas

Re: [Qemu-devel] [PATCH] hw/display: Add basic ATI VGA emulation

[BALATON Zoltan]

On Tue, 19 Feb 2019, Peter Maydell wrote:

On Tue, 12 Feb 2019 at 23:59, BALATON Zoltan  wrote:

On Tue, 12 Feb 2019, Philippe Mathieu-Daudé wrote:

On 2/11/19 4:19 AM, BALATON Zoltan wrote:

[...]

+
+static void ati_reg_write_offs(uint32_t *reg, int offs,
+   uint64_t data, unsigned int size)
+{
+int shift, i;
+uint32_t mask;
+
+for (i = 0; i < size; i++) {
+shift = (offs + i) * 8;
+mask = 0xffUL << shift;
+*reg &= ~mask;
+*reg |= (data & 0xff) << shift;
+data >>= 8;


I'd have use a pair of extract32/deposit32 but this is probably easier
to singlestep.


You've told me that before but I have concerns about the asserts in those
functions which to me seem like unnecessary overhead in such low level
functions so unless these are removed or *_noassert versions introduced
I'll stay away from them.


The code above is IMHO pretty hard to read -- you have to
think through all the shifts and masks to figure out exactly
what is being done. I would definitely recommend extract32/deposit32,
as they convey the intent much better. You're already inside a
register accessor for a device model, there is much more overhead
on this path than a few assert condition checks. (And they do
catch bugs -- they found one in the arm code last month.)

(Alternatively, if you believe the overhead of the asserts matters,
then provide benchmarking demonstrating it, and we could look
at restricting this assert to the case where start and length are
compile-time constant, or to only the --enable-debug build.)


But I'm also not too happy about these *_offs functions but some registers
support 8/16/32 bit access and guest code seems to actually do this to
update bits in the middle of the register at an odd address. Best would be
if I could just set .impl.min = 4, .impl.max = 4 and .valid.min = 1
.valid.max = 4 for the mem region ops but I'm not sure that would work or
would it? If that's working maybe I should just go with that instead.


This will work, but only if all the registers in the memory region
are happy with "read 32 bits, write back 32 bits", ie they have
no "write-1-to-clear", "special behaviour on read", etc. (The
memory system will implement byte reads as "read 32 bits, modify,
write back".) If it does work then that's a nice way to do it.


OK, I'll try this and if it works that should be the best until a w1tc reg 
is found.



I won't and here's why: This is not a finished device model and I expect
to need to add debug logs and change them frequently during further
development and for such ad-hoc debugging DPRINF is still easier to use
because I don't have to define the format string at one file and use them
somewhere else.


If you want to use local debug printfs for your convenience that's fine.
You don't have to submit them in the patches you send. (I use them
quite a bit in development, and my stack of patches usually has a
patch at the end called "debug junk" with that kind of thing in it.)
But new code we take into upstream should be preferring trace events
over ad-hoc DPRINTF.


I could do that but that wouldn't help anyone but me. Since the device 
model is far from finished at the moment I expect anyone who tries it with 
anything more complex than Linux framebuffer and maybe X driver will need 
to debug and fix it to add more features their drivers need and I'd like 
to make their job easier because I'd like to encourage people to help 
finishing this. (It would probably take me alone about 2 years 
otherwise with the current rate of effort I can put in this.) So not 
having any debug facilities to help this is counterproductive at this 
stage. Once the model is more finished these can be removed or turned into 
trace points but not yet I think. This wouldn't be the only device with 
DPRINTFs in QEMU so as a special case I think this makes sense to allow it 
to use DPRINTF as well for development.



Anything that
distracts from actual values and makes it harder to read (such as
timestamps and pids added by trace)


-d trace:your_trace_event doesn't add timestamps or PIDs, FWIW.


Thanks, I was looking for that option but couldn't find yet.

Regards,
BALATON Zoltan

Re: [Qemu-devel] [PATCH] iotests: drop unnecessary accel=kvm

[Vladimir Sementsov-Ogievskiy]

19.02.2019 15:02, Thomas Huth wrote:
> On 19/02/2019 12.59, Stefan Hajnoczi wrote:
>> Tests 235 and 238 do not require the kvm accelerator.  TCG works fine.
>>
>> Use the default accelerator instead of requiring kvm.
>>
>> Suggested-by: Thomas Huth 
>> Signed-off-by: Stefan Hajnoczi 
>> ---
>>   tests/qemu-iotests/235 | 1 -
>>   tests/qemu-iotests/238 | 1 -
>>   2 files changed, 2 deletions(-)
>>
>> diff --git a/tests/qemu-iotests/235 b/tests/qemu-iotests/235
>> index d6edd97ab4..329da8f0c2 100755
>> --- a/tests/qemu-iotests/235
>> +++ b/tests/qemu-iotests/235
>> @@ -49,7 +49,6 @@ qemu_img_create('-f', iotests.imgfmt, '-o', 
>> 'preallocation=metadata', disk,
>>   str(size))
>>   
>>   vm = QEMUMachine(iotests.qemu_prog)
>> -vm.add_args('-machine', 'accel=kvm')
> 
> According to the initial commit log of 235:
> 
>   "iotests: simple mirror test with kvm on 1G image"
> 
> ... so I assume KVM was used on purpose here?
> 
>   Thomas
> 

As I remember kvm is not really necessary, and test have a comment about it:
# And it didn't reproduce if at least one of the following:
...
# 3. drop kvm and use iotests.VM() (maybe, because of qtest) (however, it still
#reproduces, if just drop kvm, but gdb failed to produce full backtraces
#for me)

But the comment should be updated with this patch.

-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH] audio: don't use alsa by default

[Gerd Hoffmann]

On Tue, Feb 19, 2019 at 11:39:49AM +0100, David Hildenbrand wrote:
> On 19.02.19 11:15, Gerd Hoffmann wrote:
> > ardware is present the driver initializes
> > successfully and throws errors later on, i.e. effectively the
> > automatic probing doesn't work.  So the driver should not be
> > used by default (until that is fixed).  Drop the can_be_default
> > flag.
> > 
> > Explicitly picking the alsa driver (using QEMU_AUDIO_DRV=alsa
> > environment variable) will continue to work.
> 
> Just pointing out that with this patch, audio initialization still
> hinders me from starting guests on my Fedora 29 when running under root
> (I don't think this patch was also intended to fix that, just pointing
> out for me the problem still exists).
> 
> 
> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
> Connection refused
> 
> sdl: SDL_OpenAudio failed
> sdl: Reason: ALSA: Couldn't open audio device: Connection refused
> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
> Connection refused
> 
> sdl: SDL_OpenAudio failed
> sdl: Reason: ALSA: Couldn't open audio device: Connection refused
> audio: Failed to create voice `pcspk'
> qemu-system-x86_64: Initialization of device isa-pcspk failed:
> Initializing audio voice failed

So SDL has the same problem (possibly only when using alsa).

Hmm.  Dropping can_be_default here will too break sound on BSD ...

Re: [Qemu-devel] [PATCH] qemu-img: fix error reporting for -object

[Philippe Mathieu-Daudé]

On 2/19/19 12:46 PM, Daniel P. Berrangé wrote:
> Error reporting for user_creatable_add_opts_foreach was changed so that
> it no longer called 'error_report_err' in:
> 
>   commit 7e1e0c11127bde81cff260fc6859690435c509d6
>   Author: Markus Armbruster 
>   Date:   Wed Oct 17 10:26:43 2018 +0200
> 
> qom: Clean up error reporting in user_creatable_add_opts_foreach()
> 
> Some callers were updated to pass in "&error_fatal" but all the ones in
> qemu-img were left passing NULL. As a result all errors went to
> /dev/null instead of being reported to the user.
> 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  qemu-img.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/qemu-img.c b/qemu-img.c
> index 25288c4d18..903c37b706 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -503,7 +503,7 @@ static int img_create(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  goto fail;
>  }
>  
> @@ -753,7 +753,7 @@ static int img_check(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  return 1;
>  }
>  
> @@ -966,7 +966,7 @@ static int img_commit(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  return 1;
>  }
>  
> @@ -1349,7 +1349,7 @@ static int img_compare(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  ret = 2;
>  goto out4;
>  }
> @@ -2159,7 +2159,7 @@ static int img_convert(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  goto fail_getopt;
>  }
>  
> @@ -2713,7 +2713,7 @@ static int img_info(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  return 1;
>  }
>  
> @@ -2932,7 +2932,7 @@ static int img_map(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  return 1;
>  }
>  
> @@ -3081,7 +3081,7 @@ static int img_snapshot(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  return 1;
>  }
>  
> @@ -3241,7 +3241,7 @@ static int img_rebase(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  return 1;
>  }
>  
> @@ -3621,7 +3621,7 @@ static int img_resize(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  return 1;
>  }
>  
> @@ -3865,7 +3865,7 @@ static int img_amend(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  ret = -1;
>  goto out_no_progress;
>  }
> @@ -4509,7 +4509,7 @@ static int img_dd(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  ret = -1;
>  goto out;
>  }
> @@ -4786,7 +4786,7 @@ static int img_measure(int argc, char **argv)
>  
>  if (qemu_opts_foreach(&qemu_object_opts,
>user_creatable_add_opts_foreach,
> -  NULL, NULL)) {
> +  NULL, &error_fatal)) {
>  goto out;
>  }
>  
> 

Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Kevin Wolf]

Am 19.02.2019 um 13:01 hat Daniel P. Berrangé geschrieben:
> On Tue, Feb 19, 2019 at 12:31:41PM +0100, Kevin Wolf wrote:
> > Am 19.02.2019 um 12:06 hat Daniel P. Berrangé geschrieben:
> > > On Tue, Feb 19, 2019 at 10:37:16AM +0100, Kevin Wolf wrote:
> > > > Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> > > > > 
> > > > >  https://gitlab.com/huth/qemu/-/jobs/163680780
> > > > > 
> > > > > Some of them apparently need encryption to be enabled (as already
> > > > > mentioned by Cleber in his patch) - thus should they really be in the
> > > > > quick check, too? Or could they at least check whether QEMU has been
> > > > > built with encryption?
> > > > 
> > > > The correct solution would be that they detect the situation
> > > > automatically and skip the test by calling _notrun.
> > > > 
> > > > I'm not sure how to detect if a given QEMU binary supports encryption,
> > > > but Dan might know.
> > > 
> > > It isn't easy & depends which encryption feature you're trying to use.
> > > 
> > > For TLS related features you can do something gross like
> > > 
> > > qemu-img info --object tls-creds-anon,id=dummy README 2>&1
> > > test $? != 0 && exit 0
> > > 
> > > This relies on fact that 'tls-creds-anon' object type will report a
> > > runtime error during initialization if gnutls isn't enabled.
> > > 
> > > For more general ciphers you pretty much have to just try the higher level
> > > feature and see if it fails.
> > 
> > Actually, I think for test cases we should see 'qemu-img create' failing
> > and could just skip the test if it returns a non-zero exit code.
> > 
> > But then I looked at Thomas' output again:
> > 
> > --- /builds/huth/qemu/tests/qemu-iotests/188.out2019-02-19 
> > 08:23:54.0 +
> > +++ /builds/huth/qemu/tests/qemu-iotests/188.out.bad2019-02-19 
> > 08:34:54.0 +
> > @@ -1,4 +1,5 @@
> >  QA output created by 188
> > +qemu-img: TEST_DIR/t.IMGFMT: No crypto library supporting PBKDF in 
> > this build: Function not implemented
> >  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 
> > encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
> > 
> >  == reading whole image ==--- 
> > /builds/huth/qemu/tests/qemu-iotests/188.out  2019-02-19 
> > 08:23:54.0 +
> > 
> > What is it actually doing there? There's clearly an error message, but
> > it almost looks like it's creating some kind of image anyway? The
> > following I/O works fine (i.e. this created image can even be opened
> > again with the luks driver), except that you can also access the image
> > with the wrong password.
> > 
> > Is this a real bug in either qcow2 or luks?
> 
> It is an artifact of the way qcow2 image creation happens in multiple
> phases. qcow2_co_create first creates a minimal qcow2 file, and then
> opens it and updates it to add in the various extra features, including
> luks encryption. We fail to create the luks encryption, but enough of
> the qcow2 file has been created that it is able to still do plain text
> I/O.

But why doesn't qcow2_update_options_prepare() fail then? If you pass
encryption options like 188 does, but the image isn't encrypted, then
the function at least attempts to error out. Where is this failing?

> Essentially the problem is that qcow2_co_create() doesn't unlink() the
> partially created image when things fail. This is a generic problem
> which can affect any part of qcow2_co_create that might fail, but it
> is especially problematic with luks.
> 
> The complication in fixing this is that can't just do an unlink() as
> we can't assume a local file. We need to have a bdrv_unlink() driver
> callback we can use to delegate to the right block driver APIs for
> deletion.

.bdrv_co_create can't unlink at all, because that would be undoing
something that it didn't even do itself. If I created a file (local or
on a remote server that is accessed over a network protocol) and my
blockdev-create command to create the qcow2 layer fails, I certainly
don't expect the resource that I manually created to go away.

What .bdrv_co_create could and probably should do is make the header
invalid so that it's still recognised as qcow2 (to avoid probing it as
raw), but opening it fails.

> This is something I think could be useful in general, to expose as a
> "qemu-img delete" command - especially for non-local formats like
> rbd, sheepdog, glusterfs the mgmt app can't simply run "rm $img".
> QEMU already knows how to talk to the native APis for these network
> drivers so can make life easier by exposing a 'delete' op.
> 
> For luks it would be desirable to allow options to the 'delete'
> operation, for example to request scrubbing of the key material
> headers.

This could still be useful, just not necessarily in the context of
blockdev-create. It could actually be used in 'qemu-img create', which
creates both the protocol layer and the format layer.

Kevin

Re: [Qemu-devel] [PATCH 01/14] MAINTAINERS: Add some missing entries for the sun4m machine

[Philippe Mathieu-Daudé]

On 2/19/19 9:36 AM, Thomas Huth wrote:
> These files / devices are only used by SPARC machines, so we can sort
> them into the corresponding categories in the MAINTAINERS file.
> 
> Cc: Mark Cave-Ayland 
> Signed-off-by: Thomas Huth 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  MAINTAINERS | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b1d786c..7e4f70a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1082,12 +1082,15 @@ M: Mark Cave-Ayland 
>  S: Maintained
>  F: hw/sparc/sun4m.c
>  F: hw/sparc/sun4m_iommu.c
> +F: hw/display/cg3.c
> +F: hw/display/tcx.c
>  F: hw/dma/sparc32_dma.c
>  F: hw/misc/eccmemctl.c
> -F: hw/misc/slavio_misc.c
> +F: hw/*/slavio_*.c
> +F: include/hw/nvram/sun_nvram.h
>  F: include/hw/sparc/sparc32_dma.h
> -F: pc-bios/openbios-sparc32
>  F: include/hw/sparc/sun4m_iommu.h
> +F: pc-bios/openbios-sparc32
>  
>  Sun4u
>  M: Mark Cave-Ayland 
> 

Re: [Qemu-devel] [PATCH] audio: don't use alsa by default

[Daniel P . Berrangé]

On Tue, Feb 19, 2019 at 01:12:58PM +0100, Gerd Hoffmann wrote:
> On Tue, Feb 19, 2019 at 11:39:49AM +0100, David Hildenbrand wrote:
> > On 19.02.19 11:15, Gerd Hoffmann wrote:
> > > ardware is present the driver initializes
> > > successfully and throws errors later on, i.e. effectively the
> > > automatic probing doesn't work.  So the driver should not be
> > > used by default (until that is fixed).  Drop the can_be_default
> > > flag.
> > > 
> > > Explicitly picking the alsa driver (using QEMU_AUDIO_DRV=alsa
> > > environment variable) will continue to work.
> > 
> > Just pointing out that with this patch, audio initialization still
> > hinders me from starting guests on my Fedora 29 when running under root
> > (I don't think this patch was also intended to fix that, just pointing
> > out for me the problem still exists).
> > 
> > 
> > ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
> > Connection refused
> > 
> > sdl: SDL_OpenAudio failed
> > sdl: Reason: ALSA: Couldn't open audio device: Connection refused
> > ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect:
> > Connection refused
> > 
> > sdl: SDL_OpenAudio failed
> > sdl: Reason: ALSA: Couldn't open audio device: Connection refused
> > audio: Failed to create voice `pcspk'
> > qemu-system-x86_64: Initialization of device isa-pcspk failed:
> > Initializing audio voice failed
> 
> So SDL has the same problem (possibly only when using alsa).
> 
> Hmm.  Dropping can_be_default here will too break sound on BSD ...

We could temporarily put the Linux default ordering back to have "oss"
before sdl/alsa until the initialization code in sdl/alsa can be fixed to
correctly detect working audio.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 09/14] MAINTAINERS: Add maintainers to the Linux subsystem

[Philippe Mathieu-Daudé]

On 2/19/19 9:36 AM, Thomas Huth wrote:
> From: Philippe Mathieu-Daudé 
> 
> Add Michael, Cornelia and Paolo as maintainers of the Linux subsystem.
> 
> Remove the qemu-devel@nongnu.org entry because the list is always
> selected by the 'All patches CC here' section.
> 
> Suggested-by: Paolo Bonzini 
> Signed-off-by: Philippe Mathieu-Daudé 
> Acked-by: Cornelia Huck 
> [thuth: Add update-linux-headers.sh, too]

Good idea.

> Signed-off-by: Thomas Huth 
> ---
>  MAINTAINERS | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 258ba5a..e6e08c2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -425,10 +425,12 @@ Hosts:
>  --
>  
>  LINUX
> -L: qemu-devel@nongnu.org
> +M: Michael S. Tsirkin 
> +M: Cornelia Huck 
> +M: Paolo Bonzini 
>  S: Maintained
> -F: linux-*
>  F: linux-headers/
> +F: scripts/update-linux-headers.sh
>  
>  POSIX
>  M: Paolo Bonzini 
> 

Re: [Qemu-devel] [PATCH 1/2] pc-dimm: remove check on pc-dimm hotpluggable

[Philippe Mathieu-Daudé]

On 2/19/19 7:07 AM, Wei Yang wrote:
> Function acpi_memory_plug_cb() is only invoked when dev is a PCDIMM,
> which is hotpluggable. This means it is not necessary to check this
> property again.
> 
> This patch removes this check.
> 
> Signed-off-by: Wei Yang 
> ---
>  hw/acpi/memory_hotplug.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
> index 8c7c1013f3..b19673d337 100644
> --- a/hw/acpi/memory_hotplug.c
> +++ b/hw/acpi/memory_hotplug.c
> @@ -266,10 +266,6 @@ void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, 
> MemHotplugState *mem_st,

This is also obvious because it takes a HotplugHandler argument.

Reviewed-by: Philippe Mathieu-Daudé 

>  MemStatus *mdev;
>  DeviceClass *dc = DEVICE_GET_CLASS(dev);
>  
> -if (!dc->hotpluggable) {
> -return;
> -}
> -
>  mdev = acpi_memory_slot_status(mem_st, dev, errp);
>  if (!mdev) {
>  return;
> 

Re: [Qemu-devel] [PATCH 12/14] hw/arm/musca: Add MPCs

[Peter Maydell]

On Thu, 14 Feb 2019 at 12:51, Peter Maydell  wrote:
>
> The Musca board puts its SRAM and flash behind TrustZone
> Memory Protection Controllers (MPCs). Each MPC sits between
> the CPU and the RAM/flash, and also has a set of memory mapped
> control registers. Wire up the MPCs, and the memory behind them.
> For the moment we implement the flash as simple ROM, which
> cannot be reprogrammed by the guest.
>
> Signed-off-by: Peter Maydell 
> ---
>  hw/arm/musca.c | 155 ++---
>  1 file changed, 147 insertions(+), 8 deletions(-)
>
> diff --git a/hw/arm/musca.c b/hw/arm/musca.c
> index 8774e0b87b7..5fadac8c09b 100644
> --- a/hw/arm/musca.c
> +++ b/hw/arm/musca.c
> @@ -27,11 +27,15 @@
>  #include "hw/arm/armsse.h"
>  #include "hw/boards.h"
>  #include "hw/core/split-irq.h"
> +#include "hw/misc/tz-mpc.h"
>  #include "hw/misc/tz-ppc.h"
>  #include "hw/misc/unimp.h"
>
>  #define MUSCA_NUMIRQ_MAX 96
>  #define MUSCA_PPC_MAX 3
> +#define MUSCA_MPC_MAX 5
> +
> +typedef struct MPCInfo MPCInfo;

[...]

> +typedef struct MPCInfo {
> +const char *name;
> +hwaddr addr;
> +hwaddr size;
> +MPCInfoType type;
> +} MPCInfo;

This should just be "struct MPCInfo { ... };" to avoid clang
complaining:

hw/arm/musca.c:165:3: error: redefinition of typedef 'MPCInfo' is a C11
  feature [-Werror,-Wtypedef-redefinition]

Since it's a minor thing I'll just squash it in when I
apply this series, assuming I don't need to respin for
anything else.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 1/2] pc-dimm: remove check on pc-dimm hotpluggable

[Philippe Mathieu-Daudé]

On 2/19/19 7:07 AM, Wei Yang wrote:
> Function acpi_memory_plug_cb() is only invoked when dev is a PCDIMM,
> which is hotpluggable. This means it is not necessary to check this
> property again.
> 
> This patch removes this check.
> 
> Signed-off-by: Wei Yang 
> ---
>  hw/acpi/memory_hotplug.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
> index 8c7c1013f3..b19673d337 100644
> --- a/hw/acpi/memory_hotplug.c
> +++ b/hw/acpi/memory_hotplug.c
> @@ -266,10 +266,6 @@ void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, 
> MemHotplugState *mem_st,
>  MemStatus *mdev;
>  DeviceClass *dc = DEVICE_GET_CLASS(dev);

You have to remove the 'dc' variable now:

  CC  hw/acpi/memory_hotplug.o
hw/acpi/memory_hotplug.c: In function ‘acpi_memory_plug_cb’:
hw/acpi/memory_hotplug.c:267:18: error: unused variable ‘dc’
[-Werror=unused-variable]
 DeviceClass *dc = DEVICE_GET_CLASS(dev);
  ^~

Once removed:
Tested-by: Philippe Mathieu-Daudé 

>  
> -if (!dc->hotpluggable) {
> -return;
> -}
> -
>  mdev = acpi_memory_slot_status(mem_st, dev, errp);
>  if (!mdev) {
>  return;
> 

Re: [Qemu-devel] [PATCH] hw/display: Add basic ATI VGA emulation

[Gerd Hoffmann]

  Hi,

> > Which linux driver is this?
> 
> Those in linux/drivers/video/fbdev/aty/. This ati-vga model defaults to Rage
> 128 Pro (what PoweMac3,1 has, device id 0x5046) which is handled by the
> aty128fb driver under Linux. MIPS fulong2e has Mobility Radeon M6 (RV100,
> device id 0x5159) that you can also use as -device ati-vga,device_id=0x5159
> which is driven by radeonfb under Linux.

So it could be tested with linux guests on x86 too I guess?
Can the radeon drm driver handle the devices too?

I'd also use model= instead of device_id=... to switch between
different devices.

> > If linux has a native driver it might make sense to also enable it on
> > x86.  Makes testing easier.
> 
> Yes it could work on all archs under Linux but I've only enabled it on the
> two I've tried. It could be added instead to the same place where vga is
> added in pci.mak if you like.

Makes sense IMHO.

> > You can add the driver to default_list[] in vl.c, then you don't need
> > -vga none to remove the default vga when adding -device ati-vga.
> 
> I could do that but since it's a bit unfinished (lacks advanced features
> such as video overlay, 3D accel, command FIFO, etc.) and only a basic
> implementation at the moment to work with Linux framebuffer that doesn't use
> these features I thought it might be a godd idea to make it a bit harder to
> access yet to avoid problem of someone trying it with a Windows guest with
> drivers from ATI which probably will result in bad picture. But it's up to
> you to decide if you want to add it to -vga option from the start or have it
> as optional device and only add to -vga when it's more fully implemented and
> tested.

It's not about "-vga ati".  This is about adding ati-vga to the list of
display devices, so qemu will not try to add a vga automatically in case
it finds "-device ati-vga" on the command line.  That way "qemu -device
ati-vga" will work fine, without "-vga none".

Adding -vga ati indeed only makes sense once the implementation is more
complete.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] audio: don't use alsa by default

[Gerd Hoffmann]

> > So SDL has the same problem (possibly only when using alsa).
> > 
> > Hmm.  Dropping can_be_default here will too break sound on BSD ...
> 
> We could temporarily put the Linux default ordering back to have "oss"
> before sdl/alsa until the initialization code in sdl/alsa can be fixed to
> correctly detect working audio.

Reordering doesn't help, they would still probe successfully and fail
later, only after oss probe failed ...

pa is ok, when the daemon isn't running init() fails properly.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 2/2] pc-dimm: remove realize callback

[Philippe Mathieu-Daudé]

On 2/19/19 7:07 AM, Wei Yang wrote:
> PCDIMM's realize callback is introduced to do proper setup for NVDIMM.
> 
> Currently the NVDIMM setup task is nvdimm_prepare_memory_region(), which
> is done in pre_plug stage. This means related task has already been done
> at realize point.
> 
> This patch remove PCDIMM realize callback.
> 
> Signed-off-by: Wei Yang 
> ---
>  hw/acpi/memory_hotplug.c |  1 -
>  hw/mem/nvdimm.c  | 11 ---
>  hw/mem/pc-dimm.c |  5 -
>  include/hw/mem/pc-dimm.h |  3 ---
>  4 files changed, 20 deletions(-)
> 
> diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
> index b19673d337..cb5284d36f 100644
> --- a/hw/acpi/memory_hotplug.c
> +++ b/hw/acpi/memory_hotplug.c
> @@ -264,7 +264,6 @@ void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, 
> MemHotplugState *mem_st,
>   DeviceState *dev, Error **errp)
>  {
>  MemStatus *mdev;
> -DeviceClass *dc = DEVICE_GET_CLASS(dev);

OK now I see the leftover of patch #1.

>  
>  mdev = acpi_memory_slot_status(mem_st, dev, errp);
>  if (!mdev) {
> diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
> index bf2adf5e16..8f69576926 100644
> --- a/hw/mem/nvdimm.c
> +++ b/hw/mem/nvdimm.c
> @@ -136,15 +136,6 @@ static MemoryRegion 
> *nvdimm_md_get_memory_region(MemoryDeviceState *md,
>  return nvdimm->nvdimm_mr;
>  }
>  
> -static void nvdimm_realize(PCDIMMDevice *dimm, Error **errp)
> -{
> -NVDIMMDevice *nvdimm = NVDIMM(dimm);
> -
> -if (!nvdimm->nvdimm_mr) {
> -nvdimm_prepare_memory_region(nvdimm, errp);
> -}
> -}
> -
>  /*
>   * the caller should check the input parameters before calling
>   * label read/write functions.
> @@ -192,12 +183,10 @@ static Property nvdimm_properties[] = {
>  
>  static void nvdimm_class_init(ObjectClass *oc, void *data)
>  {
> -PCDIMMDeviceClass *ddc = PC_DIMM_CLASS(oc);
>  MemoryDeviceClass *mdc = MEMORY_DEVICE_CLASS(oc);
>  NVDIMMClass *nvc = NVDIMM_CLASS(oc);
>  DeviceClass *dc = DEVICE_CLASS(oc);
>  
> -ddc->realize = nvdimm_realize;
>  mdc->get_memory_region = nvdimm_md_get_memory_region;
>  dc->props = nvdimm_properties;
>  

I'd split your patch in 2:
- the previous part, cleaning NVDIMM,
- the part below, doing "git revert 9f318f8f7e6" and improving the
commit description.

> diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
> index 152400b1fc..5832c0ba92 100644
> --- a/hw/mem/pc-dimm.c
> +++ b/hw/mem/pc-dimm.c
> @@ -159,7 +159,6 @@ static void pc_dimm_init(Object *obj)
>  static void pc_dimm_realize(DeviceState *dev, Error **errp)
>  {
>  PCDIMMDevice *dimm = PC_DIMM(dev);
> -PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
>  
>  if (!dimm->hostmem) {
>  error_setg(errp, "'" PC_DIMM_MEMDEV_PROP "' property is not set");
> @@ -178,10 +177,6 @@ static void pc_dimm_realize(DeviceState *dev, Error 
> **errp)
>  return;
>  }
>  
> -if (ddc->realize) {
> -ddc->realize(dimm, errp);
> -}
> -
>  host_memory_backend_set_mapped(dimm->hostmem, true);
>  }
>  
> diff --git a/include/hw/mem/pc-dimm.h b/include/hw/mem/pc-dimm.h
> index 01436b9f50..d18f8246b7 100644
> --- a/include/hw/mem/pc-dimm.h
> +++ b/include/hw/mem/pc-dimm.h
> @@ -59,8 +59,6 @@ typedef struct PCDIMMDevice {
>  
>  /**
>   * PCDIMMDeviceClass:
> - * @realize: called after common dimm is realized so that the dimm based
> - * devices get the chance to do specified operations.
>   * @get_vmstate_memory_region: returns #MemoryRegion which indicates the
>   * memory of @dimm should be kept during live migration. Will not fail
>   * after the device was realized.
> @@ -70,7 +68,6 @@ typedef struct PCDIMMDeviceClass {
>  DeviceClass parent_class;
>  
>  /* public */
> -void (*realize)(PCDIMMDevice *dimm, Error **errp);
>  MemoryRegion *(*get_vmstate_memory_region)(PCDIMMDevice *dimm,
> Error **errp);
>  } PCDIMMDeviceClass;
> 

Re: [Qemu-devel] [PATCH 02/10] pflash: Macro PFLASH_BUG() is used just once, expand

[Philippe Mathieu-Daudé]

On 2/18/19 1:56 PM, Markus Armbruster wrote:
> PFLASH_BUG()'s lone use has a suspicious smell: it prints "Possible
> BUG", which sounds like a warning, then calls exit(1), followed by
> unreachable goto reset_flash.  All this commit does is expanding the
> macro, so the smell becomes more poignant, and the macro can be
> deleted.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  hw/block/pflash_cfi01.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
> index 9efa7aa9af..f73c30a3ee 100644
> --- a/hw/block/pflash_cfi01.c
> +++ b/hw/block/pflash_cfi01.c
> @@ -49,12 +49,6 @@
>  #include "sysemu/sysemu.h"
>  #include "trace.h"
>  
> -#define PFLASH_BUG(fmt, ...) \
> -do { \
> -fprintf(stderr, "PFLASH: Possible BUG - " fmt, ## __VA_ARGS__); \
> -exit(1); \
> -} while(0)
> -
>  /* #define PFLASH_DEBUG */
>  #ifdef PFLASH_DEBUG
>  #define DPRINTF(fmt, ...)   \
> @@ -624,8 +618,8 @@ static void pflash_write(PFlashCFI01 *pfl, hwaddr offset,
>  pfl->status |= 0x80;
>  } else {
>  DPRINTF("%s: unknown command for \"write block\"\n", 
> __func__);
> -PFLASH_BUG("Write block confirm");
> -goto reset_flash;
> +fprintf(stderr, "PFLASH: Possible BUG - Write block 
> confirm");
> +exit(1);

Don't you want to use hw_error here?

  hw_error("PFLASH: Possible BUG - Write block confirm");

>  }
>  break;
>  default:
> 

Re: [Qemu-devel] [PATCH 03/10] hw: Use CFI_PFLASH0{1, 2} and TYPE_CFI_PFLASH0{1, 2}

[Philippe Mathieu-Daudé]

On 2/18/19 1:56 PM, Markus Armbruster wrote:
> We have two open-coded copies of macro CFI_PFLASH01().  Move the macro
> to the header, so we can ditch the copies.  Move CFI_PFLASH02() to the
> header for symmetry.
> 
> We define macros TYPE_CFI_PFLASH01 and TYPE_CFI_PFLASH02 for type name
> strings, then mostly use the strings.  If the macros are worth
> defining, they are worth using.  Replace the strings by the macros.
> 
> Signed-off-by: Markus Armbruster 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  hw/arm/vexpress.c| 4 ++--
>  hw/arm/virt.c| 3 ++-
>  hw/block/pflash_cfi01.c  | 3 ---
>  hw/block/pflash_cfi02.c  | 3 ---
>  hw/xtensa/xtfpga.c   | 4 ++--
>  include/hw/block/flash.h | 4 
>  6 files changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
> index ed46d2e730..00913f2655 100644
> --- a/hw/arm/vexpress.c
> +++ b/hw/arm/vexpress.c
> @@ -515,7 +515,7 @@ static void vexpress_modify_dtb(const struct 
> arm_boot_info *info, void *fdt)
>  static PFlashCFI01 *ve_pflash_cfi01_register(hwaddr base, const char *name,
>   DriveInfo *di)
>  {
> -DeviceState *dev = qdev_create(NULL, "cfi.pflash01");
> +DeviceState *dev = qdev_create(NULL, TYPE_CFI_PFLASH01);
>  
>  if (di) {
>  qdev_prop_set_drive(dev, "drive", blk_by_legacy_dinfo(di),
> @@ -536,7 +536,7 @@ static PFlashCFI01 *ve_pflash_cfi01_register(hwaddr base, 
> const char *name,
>  qdev_init_nofail(dev);
>  
>  sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
> -return OBJECT_CHECK(PFlashCFI01, (dev), "cfi.pflash01");
> +return CFI_PFLASH01(dev);
>  }
>  
>  static void vexpress_common_init(MachineState *machine)
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 99c2b6e60d..b7d53b2b87 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -34,6 +34,7 @@
>  #include "hw/arm/arm.h"
>  #include "hw/arm/primecell.h"
>  #include "hw/arm/virt.h"
> +#include "hw/block/flash.h"
>  #include "hw/vfio/vfio-calxeda-xgmac.h"
>  #include "hw/vfio/vfio-amd-xgbe.h"
>  #include "hw/display/ramfb.h"
> @@ -874,7 +875,7 @@ static void create_one_flash(const char *name, hwaddr 
> flashbase,
>   * parameters as the flash devices on the Versatile Express board.
>   */
>  DriveInfo *dinfo = drive_get_next(IF_PFLASH);
> -DeviceState *dev = qdev_create(NULL, "cfi.pflash01");
> +DeviceState *dev = qdev_create(NULL, TYPE_CFI_PFLASH01);
>  SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
>  const uint64_t sectorlength = 256 * 1024;
>  
> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
> index f73c30a3ee..43dbb7db26 100644
> --- a/hw/block/pflash_cfi01.c
> +++ b/hw/block/pflash_cfi01.c
> @@ -59,9 +59,6 @@ do {
> \
>  #define DPRINTF(fmt, ...) do { } while (0)
>  #endif
>  
> -#define CFI_PFLASH01(obj) \
> -OBJECT_CHECK(PFlashCFI01, (obj), TYPE_CFI_PFLASH01)
> -
>  #define PFLASH_BE  0
>  #define PFLASH_SECURE  1
>  
> diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
> index 424cc106d6..e9c76d6cfb 100644
> --- a/hw/block/pflash_cfi02.c
> +++ b/hw/block/pflash_cfi02.c
> @@ -57,9 +57,6 @@ do {   \
>  
>  #define PFLASH_LAZY_ROMD_THRESHOLD 42
>  
> -#define CFI_PFLASH02(obj) \
> -OBJECT_CHECK(PFlashCFI02, (obj), TYPE_CFI_PFLASH02)
> -
>  struct PFlashCFI02 {
>  /*< private >*/
>  SysBusDevice parent_obj;
> diff --git a/hw/xtensa/xtfpga.c b/hw/xtensa/xtfpga.c
> index 3d59a7a356..a726d5632a 100644
> --- a/hw/xtensa/xtfpga.c
> +++ b/hw/xtensa/xtfpga.c
> @@ -167,7 +167,7 @@ static PFlashCFI01 *xtfpga_flash_init(MemoryRegion 
> *address_space,
>DriveInfo *dinfo, int be)
>  {
>  SysBusDevice *s;
> -DeviceState *dev = qdev_create(NULL, "cfi.pflash01");
> +DeviceState *dev = qdev_create(NULL, TYPE_CFI_PFLASH01);
>  
>  qdev_prop_set_drive(dev, "drive", blk_by_legacy_dinfo(dinfo),
>  &error_abort);
> @@ -181,7 +181,7 @@ static PFlashCFI01 *xtfpga_flash_init(MemoryRegion 
> *address_space,
>  s = SYS_BUS_DEVICE(dev);
>  memory_region_add_subregion(address_space, board->flash->base,
>  sysbus_mmio_get_region(s, 0));
> -return OBJECT_CHECK(PFlashCFI01, (dev), "cfi.pflash01");
> +return CFI_PFLASH01(dev);
>  }
>  
>  static uint64_t translate_phys_addr(void *opaque, uint64_t addr)
> diff --git a/include/hw/block/flash.h b/include/hw/block/flash.h
> index 51d8f60c65..1078dc7238 100644
> --- a/include/hw/block/flash.h
> +++ b/include/hw/block/flash.h
> @@ -8,6 +8,8 @@
>  /* pflash_cfi01.c */
>  
>  #define TYPE_CFI_PFLASH01 "cfi.pflash01"
> +#define CFI_PFLASH01(obj) \
> +OBJECT_CHECK(PFlashCFI01, (obj), TYPE_CFI_PFLASH01)
>  
>  typedef struct PFlashCFI01 PFlashCFI01;
>  
> @@ -25,6 +27,8 @@ MemoryRegion *pflash_cfi01_get_memory(PFlas

[Qemu-devel] [PATCH v2] audio: don't build alsa and sdl by default on linux

[Gerd Hoffmann]

In case no sound hardware is present both alsa and sdl drivers
initialize successfully and throw errors later on, i.e. effectively
the automatic probing doesn't work.  Drop them from the list of
default audio drivers for linux because of that.

Fixes: 6a48541873 audio: probe audio drivers by default
Buglink: https://bugs.launchpad.net/qemu/+bug/1816052
Signed-off-by: Gerd Hoffmann 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index fbd0825488..651b4f7514 100755
--- a/configure
+++ b/configure
@@ -877,7 +877,7 @@ Haiku)
   LIBS="-lposix_error_mapper -lnetwork $LIBS"
 ;;
 Linux)
-  audio_drv_list="try-pa try-alsa try-sdl oss"
+  audio_drv_list="try-pa oss"
   audio_possible_drivers="oss alsa sdl pa"
   linux="yes"
   linux_user="yes"
-- 
2.9.3

Re: [Qemu-devel] [PATCH 1/4] io/channel: add qio_channel_get_attached_aio_context()

[Vladimir Sementsov-Ogievskiy]

12.02.2019 13:33, Daniel P. Berrangé wrote:
> On Mon, Feb 11, 2019 at 03:55:58PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> Expose attached aio context. It will be used in nbd code, to
>> understand, in which aio context negotiation should be done.
> 
> I'm not especially objecting to the idea of adding the API to the
> QIOChannel class, but I'm surprised that NBD needs this. Surely it
> already knows what AIO context it assigned to the channel in the
> first place.

Actually not, nbd/client.c don't know it, it gets @ioc as a paramter of 
nbd_receive_negotiate
and nbd_receive_export_list, which may be called from block/nbd-client.c and 
qemu-nbd.c..

for example, nbd-client.c do

nbd_client_attach_aio_context(bs, bdrv_get_aio_context(bs));

where nbd_client_attach_aio_context is

void nbd_client_attach_aio_context(BlockDriverState *bs,
AioContext *new_context)
{
 NBDClientSession *client = nbd_get_client_session(bs);
 qio_channel_attach_aio_context(QIO_CHANNEL(client->ioc), new_context);
 aio_co_schedule(new_context, client->connection_co);
}

It does it after nbd_receive_negotiate(), but I think, it should be split in 
these series in nbd_client_connect(),
so that we attach aio context before negotiation and schedule connection_co 
after it.

and NBDClientSession is block/* related object. So, nbd/client.c sees only 
resulting ioc.
And it seems better to get aio context from ioc, than pass additional parameter 
to nbd_receive_negotiate()
together with ioc.

  IOW, it feels like this is papering over a limitation
> in NBD not keeping track of what AIO context it should be using.
> 
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>   include/io/channel.h | 9 +
>>   io/channel.c | 5 +
>>   2 files changed, 14 insertions(+)
>>
>> diff --git a/include/io/channel.h b/include/io/channel.h
>> index da2f138200..1a1e4a01b0 100644
>> --- a/include/io/channel.h
>> +++ b/include/io/channel.h
>> @@ -718,6 +718,15 @@ GSource *qio_channel_add_watch_source(QIOChannel *ioc,
>>   void qio_channel_attach_aio_context(QIOChannel *ioc,
>>   AioContext *ctx);
>>   
>> +/*
>> + * qio_channel_get_aio_context
>> + * @ioc: the channel object
>> + *
>> + * Returns channel AioContext if any attached by
>> + * qio_channel_attach_aio_context(), otherwise NULL.
>> + */
>> +AioContext *qio_channel_get_attached_aio_context(QIOChannel *ioc);
>> +
>>   /**
>>* qio_channel_detach_aio_context:
>>* @ioc: the channel object
>> diff --git a/io/channel.c b/io/channel.c
>> index 8dd0684f5d..a1b937bb6b 100644
>> --- a/io/channel.c
>> +++ b/io/channel.c
>> @@ -454,6 +454,11 @@ void qio_channel_detach_aio_context(QIOChannel *ioc)
>>   ioc->ctx = NULL;
>>   }
>>   
>> +AioContext *qio_channel_get_attached_aio_context(QIOChannel *ioc)
>> +{
>> +return ioc->ctx;
>> +}
>> +
>>   void coroutine_fn qio_channel_yield(QIOChannel *ioc,
>>   GIOCondition condition)
>>   {
>> -- 
>> 2.18.0
>>
> 
> Regards,
> Daniel
> 


-- 
Best regards,
Vladimir