[Qemu-devel] [PATCH qemu v7 1/4] linux-headers: update to f1517df8701c

[Alexey Kardashevskiy]

Update headers against f1517df8701c.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f1517df8701c

Signed-off-by: Alexey Kardashevskiy 
--

Pulled because of new VFIO_REGION_INFO_CAP_MSIX_MAPPABLE
---
 include/standard-headers/linux/input-event-codes.h |   1 +
 include/standard-headers/linux/input.h |  11 +
 include/standard-headers/linux/pci_regs.h  |  30 +-
 include/standard-headers/linux/virtio_balloon.h|   3 +-
 include/standard-headers/linux/virtio_net.h|  13 +
 linux-headers/asm-powerpc/unistd.h |   3 +
 linux-headers/asm-s390/unistd.h| 401 +
 linux-headers/linux/psci.h |   3 +
 linux-headers/linux/vfio.h |  72 
 9 files changed, 126 insertions(+), 411 deletions(-)

diff --git a/include/standard-headers/linux/input-event-codes.h 
b/include/standard-headers/linux/input-event-codes.h
index 79841b5..9e6a8ba 100644
--- a/include/standard-headers/linux/input-event-codes.h
+++ b/include/standard-headers/linux/input-event-codes.h
@@ -594,6 +594,7 @@
 #define BTN_DPAD_RIGHT 0x223
 
 #define KEY_ALS_TOGGLE 0x230   /* Ambient light sensor */
+#define KEY_ROTATE_LOCK_TOGGLE 0x231   /* Display rotation lock */
 
 #define KEY_BUTTONCONFIG   0x240   /* AL Button Configuration */
 #define KEY_TASKMANAGER0x241   /* AL Task/Project Manager */
diff --git a/include/standard-headers/linux/input.h 
b/include/standard-headers/linux/input.h
index bc3e6d3..c0bd1ba 100644
--- a/include/standard-headers/linux/input.h
+++ b/include/standard-headers/linux/input.h
@@ -18,10 +18,21 @@
 
 /*
  * The event structure itself
+ * Note that __USE_TIME_BITS64 is defined by libc based on
+ * application's request to use 64 bit time_t.
  */
 
 struct input_event {
+#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && 
!defined(__KERNEL)
struct timeval time;
+#define input_event_sec time.tv_sec
+#define input_event_usec time.tv_usec
+#else
+   __kernel_ulong_t __sec;
+   __kernel_ulong_t __usec;
+#define input_event_sec  __sec
+#define input_event_usec __usec
+#endif
uint16_t type;
uint16_t code;
int32_t value;
diff --git a/include/standard-headers/linux/pci_regs.h 
b/include/standard-headers/linux/pci_regs.h
index 70c2b2a..0c79eac 100644
--- a/include/standard-headers/linux/pci_regs.h
+++ b/include/standard-headers/linux/pci_regs.h
@@ -622,15 +622,19 @@
  * safely.
  */
 #define PCI_EXP_DEVCAP236  /* Device Capabilities 2 */
+#define  PCI_EXP_DEVCAP2_COMP_TMOUT_DIS0x0010 /* Completion 
Timeout Disable supported */
 #define  PCI_EXP_DEVCAP2_ARI   0x0020 /* Alternative Routing-ID */
 #define  PCI_EXP_DEVCAP2_ATOMIC_ROUTE  0x0040 /* Atomic Op routing */
-#define PCI_EXP_DEVCAP2_ATOMIC_COMP64  0x0100 /* Atomic 64-bit compare */
+#define  PCI_EXP_DEVCAP2_ATOMIC_COMP32 0x0080 /* 32b AtomicOp completion */
+#define  PCI_EXP_DEVCAP2_ATOMIC_COMP64 0x0100 /* 64b AtomicOp completion */
+#define  PCI_EXP_DEVCAP2_ATOMIC_COMP1280x0200 /* 128b AtomicOp 
completion */
 #define  PCI_EXP_DEVCAP2_LTR   0x0800 /* Latency tolerance 
reporting */
 #define  PCI_EXP_DEVCAP2_OBFF_MASK 0x000c /* OBFF support mechanism */
 #define  PCI_EXP_DEVCAP2_OBFF_MSG  0x0004 /* New message signaling */
 #define  PCI_EXP_DEVCAP2_OBFF_WAKE 0x0008 /* Re-use WAKE# for OBFF */
 #define PCI_EXP_DEVCTL240  /* Device Control 2 */
 #define  PCI_EXP_DEVCTL2_COMP_TIMEOUT  0x000f  /* Completion Timeout Value */
+#define  PCI_EXP_DEVCTL2_COMP_TMOUT_DIS0x0010  /* Completion Timeout 
Disable */
 #define  PCI_EXP_DEVCTL2_ARI   0x0020  /* Alternative Routing-ID */
 #define PCI_EXP_DEVCTL2_ATOMIC_REQ 0x0040  /* Set Atomic requests */
 #define PCI_EXP_DEVCTL2_ATOMIC_EGRESS_BLOCK 0x0080 /* Block atomic egress */
@@ -966,26 +970,28 @@
 
 /* Downstream Port Containment */
 #define PCI_EXP_DPC_CAP4   /* DPC Capability */
-#define PCI_EXP_DPC_IRQ0x1f/* DPC Interrupt 
Message Number */
-#define  PCI_EXP_DPC_CAP_RP_EXT0x20/* Root Port Extensions 
for DPC */
-#define  PCI_EXP_DPC_CAP_POISONED_TLP  0x40/* Poisoned TLP Egress Blocking 
Supported */
-#define  PCI_EXP_DPC_CAP_SW_TRIGGER0x80/* Software Triggering 
Supported */
-#define  PCI_EXP_DPC_RP_PIO_LOG_SIZE   0xF00   /* RP PIO log size */
+#define PCI_EXP_DPC_IRQ0x001F  /* Interrupt Message 
Number */
+#define  PCI_EXP_DPC_CAP_RP_EXT0x0020  /* Root Port Extensions 
*/
+#define  PCI_EXP_DPC_CAP_POISONED_TLP  0x0040  /* Poisoned TLP Egress Blocking 
Supported */
+#define  PCI_EXP_DPC_CAP_SW_TRIGGER0x0080  /* Software Triggering 
Supported */
+#define  PCI_EXP_DPC_RP_PIO_LOG_SIZE   0x0F00  /* RP PIO Log 

[Qemu-devel] [PATCH qemu v7 2/4] vfio/pci: Relax DMA map errors for MMIO regions

[Alexey Kardashevskiy]

At the moment if vfio_memory_listener is registered in the system memory
address space, it maps/unmaps every RAM memory region for DMA.
It expects system page size aligned memory sections so vfio_dma_map
would not fail and so far this has been the case. A mapping failure
would be fatal. A side effect of such behavior is that some MMIO pages
would not be mapped silently.

However we are going to change MSIX BAR handling so we will end having
non-aligned sections in vfio_memory_listener (more details is in
the next patch) and vfio_dma_map will exit QEMU.

In order to avoid fatal failures on what previously was not a failure and
was just silently ignored, this checks the section alignment to
the smallest supported IOMMU page size and prints an error if not aligned;
it also prints an error if vfio_dma_map failed despite the page size check.
Both errors are not fatal; only MMIO RAM regions are checked
(aka "RAM device" regions).

If the amount of errors printed is overwhelming, the MSIX relocation
could be used to avoid excessive error output.

This is unlikely to cause any behavioral change.

Signed-off-by: Alexey Kardashevskiy 
---
 hw/vfio/common.c | 55 +--
 1 file changed, 49 insertions(+), 6 deletions(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index f895e3c..736f271 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -544,18 +544,40 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
 
 llsize = int128_sub(llend, int128_make64(iova));
 
+if (memory_region_is_ram_device(section->mr)) {
+hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
+
+if ((iova & pgmask) || (llsize & pgmask)) {
+error_report("Region 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx
+ " is not aligned to 0x%"HWADDR_PRIx
+ " and cannot be mapped for DMA",
+ section->offset_within_region,
+ int128_getlo(section->size),
+ pgmask + 1);
+return;
+}
+}
+
 ret = vfio_dma_map(container, iova, int128_get64(llsize),
vaddr, section->readonly);
 if (ret) {
 error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
  "0x%"HWADDR_PRIx", %p) = %d (%m)",
  container, iova, int128_get64(llsize), vaddr, ret);
+if (memory_region_is_ram_device(section->mr)) {
+/* Allow unexpected mappings not to be fatal for RAM devices */
+return;
+}
 goto fail;
 }
 
 return;
 
 fail:
+if (memory_region_is_ram_device(section->mr)) {
+error_report("failed to vfio_dma_map. pci p2p may not work");
+return;
+}
 /*
  * On the initfn path, store the first error in the container so we
  * can gracefully fail.  Runtime, there's not much we can do other
@@ -577,6 +599,7 @@ static void vfio_listener_region_del(MemoryListener 
*listener,
 hwaddr iova, end;
 Int128 llend, llsize;
 int ret;
+bool try_unmap = true;
 
 if (vfio_listener_skipped_section(section)) {
 trace_vfio_listener_region_del_skip(
@@ -629,13 +652,33 @@ static void vfio_listener_region_del(MemoryListener 
*listener,
 
 trace_vfio_listener_region_del(iova, end);
 
-ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
+if (memory_region_is_ram_device(section->mr)) {
+hwaddr pgmask;
+VFIOHostDMAWindow *hostwin;
+bool hostwin_found = false;
+
+QLIST_FOREACH(hostwin, >hostwin_list, hostwin_next) {
+if (hostwin->min_iova <= iova && end <= hostwin->max_iova) {
+hostwin_found = true;
+break;
+}
+}
+assert(hostwin_found); /* or region_add() would have failed */
+
+pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
+try_unmap = !((iova & pgmask) || (llsize & pgmask));
+}
+
+if (try_unmap) {
+ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
+if (ret) {
+error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
+ "0x%"HWADDR_PRIx") = %d (%m)",
+ container, iova, int128_get64(llsize), ret);
+}
+}
+
 memory_region_unref(section->mr);
-if (ret) {
-error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
- "0x%"HWADDR_PRIx") = %d (%m)",
- container, iova, int128_get64(llsize), ret);
-}
 
 if (container->iommu_type == VFIO_SPAPR_TCE_v2_IOMMU) {
 vfio_spapr_remove_window(container,
-- 
2.11.0

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

[Viktor Mihajlovski]

On 08.02.2018 21:33, Eduardo Habkost wrote:
> On Thu, Feb 08, 2018 at 11:17:32AM -0500, Luiz Capitulino wrote:
> [...]
>> The "halted" field is somewhat controversial. On the one hand,
>> it offers a convenient way to know if a guest CPU is idle or
>> running. On the other hand, it's a field that can change many
>> times a second. In fact, the halted state can change even
>> before query-cpus-fast has returned. This makes one wonder if
>> this field should be dropped all together. Having the "halted"
>> field as optional gives a better option for dropping it in
>> the future, since we can just stop returning it.
> 
> I'd just drop it, unless we find a use case where it's really
> useful.
> 
> Also, the code that sets/clears cpu->halted is target-specific,
> so I wouldn't be so sure that simply checking for
> !kvm_irqchip_in_kernel() is enough on all targets.
> 
Right, the present patch effectively disables halted anyway (including
s390). So it may be cleaner to just drop it right now.
Assuming the presence of architecure-specific data, libvirt can derive a
halted state (or an equivalent thereof) from query-cpus-fast returned
information.

-- 
Regards,
 Viktor Mihajlovski

[Qemu-devel] [PATCH qemu v7 3/4] vfio-pci: Allow mmap of MSIX BAR

[Alexey Kardashevskiy]

At the moment we unconditionally avoid mapping MSIX data of a BAR and
emulate MSIX table in QEMU. However it is 1) not always necessary as
a platform may prodive a paravirt interface for MSIX configuration;
2) can affect the speed of MMIO access by emulating them in QEMU when
frequently accessed registers share same system page with MSIX data,
this is particularly a problem for systems with the page size bigger
than 4KB.

A new capability - VFIO_REGION_INFO_CAP_MSIX_MAPPABLE - has been added
to the kernel [1] which tells the userspace that mapping of the MSIX data
is possible now. This makes use of it so from now on QEMU tries mapping
the entire BAR as a whole and emulate MSIX on top of that.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a32295c612c57990d17fb0f41e7134394b2f35f6

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v7:
* test iova/llsize against pgmask in vfio_listener_region_add/del
* s/vfio_is_cap_present/vfio_has_region_cap/
* added comments here and there
* s/vdev->msix->table_bar/region-nr/
---
 include/hw/vfio/vfio-common.h |  1 +
 hw/vfio/common.c  | 15 +++
 hw/vfio/pci.c |  9 +
 3 files changed, 25 insertions(+)

diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index f3a2ac9..42dd2b0 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -171,6 +171,7 @@ int vfio_get_region_info(VFIODevice *vbasedev, int index,
  struct vfio_region_info **info);
 int vfio_get_dev_region_info(VFIODevice *vbasedev, uint32_t type,
  uint32_t subtype, struct vfio_region_info **info);
+bool vfio_has_region_cap(VFIODevice *vbasedev, int region, uint16_t cap_type);
 #endif
 extern const MemoryListener vfio_prereg_listener;
 
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 736f271..b99ae77 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1464,6 +1464,21 @@ int vfio_get_dev_region_info(VFIODevice *vbasedev, 
uint32_t type,
 return -ENODEV;
 }
 
+bool vfio_has_region_cap(VFIODevice *vbasedev, int region, uint16_t cap_type)
+{
+struct vfio_region_info *info = NULL;
+bool ret = false;
+
+if (!vfio_get_region_info(vbasedev, region, )) {
+if (vfio_get_region_info_cap(info, cap_type)) {
+ret = true;
+}
+g_free(info);
+}
+
+return ret;
+}
+
 /*
  * Interfaces for IBM EEH (Enhanced Error Handling)
  */
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 879510c..ae9098d 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1294,6 +1294,15 @@ static void vfio_pci_fixup_msix_region(VFIOPCIDevice 
*vdev)
 VFIORegion *region = >bars[vdev->msix->table_bar].region;
 
 /*
+ * If the host driver allows mapping of a MSIX data, we are going to
+ * do map the entire BAR and emulate MSIX table on top of that.
+ */
+if (vfio_has_region_cap(>vbasedev, region->nr,
+VFIO_REGION_INFO_CAP_MSIX_MAPPABLE)) {
+return;
+}
+
+/*
  * We expect to find a single mmap covering the whole BAR, anything else
  * means it's either unsupported or already setup.
  */
-- 
2.11.0

[Qemu-devel] [PATCH qemu v7 4/4] ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices

[Alexey Kardashevskiy]

This adds a possibility for the platform to tell VFIO not to emulate MSIX
so MMIO memory regions do not get split into chunks in flatview and
the entire page can be registered as a KVM memory slot and make direct
MMIO access possible for the guest.

This enables the entire MSIX BAR mapping to the guest for the pseries
platform in order to achieve the maximum MMIO preformance for certain
devices.

Tested on:
LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)

Signed-off-by: Alexey Kardashevskiy 
---

Need to split this in two?
---
 hw/ppc/spapr.c |  7 +++
 hw/vfio/pci.c  | 13 +
 2 files changed, 20 insertions(+)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index eb3e1a7..14d8ecb 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2855,6 +2855,11 @@ static void spapr_set_modern_hotplug_events(Object *obj, 
bool value,
 spapr->use_hotplug_event_source = value;
 }
 
+static bool spapr_get_msix_emulation(Object *obj, Error **errp)
+{
+return true;
+}
+
 static char *spapr_get_resize_hpt(Object *obj, Error **errp)
 {
 sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
@@ -2936,6 +2941,8 @@ static void spapr_instance_init(Object *obj)
 object_property_set_description(obj, "vsmt",
 "Virtual SMT: KVM behaves as if this were"
 " the host's SMT mode", _abort);
+object_property_add_bool(obj, "vfio-no-msix-emulation",
+ spapr_get_msix_emulation, NULL, NULL);
 }
 
 static void spapr_machine_finalizefn(Object *obj)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index ae9098d..4a03085 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1580,6 +1580,19 @@ static int vfio_msix_setup(VFIOPCIDevice *vdev, int pos, 
Error **errp)
  */
 memory_region_set_enabled(>pdev.msix_pba_mmio, false);
 
+/*
+ * The emulated machine may provide a paravirt interface for MSIX setup
+ * so it is not strictly necessary to emulate MSIX here. This becomes
+ * helpful when frequently accessed MMIO registers are located in
+ * subpages adjacent to the MSIX table but the MSIX data containing page
+ * cannot be mapped because of a host page size bigger than the MSIX table
+ * alignment.
+ */
+if (object_property_get_bool(OBJECT(qdev_get_machine()),
+ "vfio-no-msix-emulation", NULL)) {
+memory_region_set_enabled(>pdev.msix_table_mmio, false);
+}
+
 return 0;
 }
 
-- 
2.11.0

[Qemu-devel] [PATCH qemu v7 0/4] vfio-pci: Allow mmap of MSIX BAR

[Alexey Kardashevskiy]

Here is my latest patchset to allow mapping of MSIX BAR to the guest
in order to accelerate MMIO on certains devices.

This is based on sha1
008a51b Peter Maydell "Merge remote-tracking branch 
'remotes/famz/tags/staging-pull-request' into staging".

Please comment. Thanks.

Changes:
v7:
* split into many patches
* test iova/llsize against pgmask in vfio_listener_region_add/del
* s/vfio_is_cap_present/vfio_has_region_cap/
* added comments here and there
* s/vdev->msix->table_bar/region->nr/


Alexey Kardashevskiy (4):
  linux-headers: update to f1517df8701c
  vfio/pci: Relax DMA map errors for MMIO regions
  vfio-pci: Allow mmap of MSIX BAR
  ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices

 include/hw/vfio/vfio-common.h  |   1 +
 include/standard-headers/linux/input-event-codes.h |   1 +
 include/standard-headers/linux/input.h |  11 +
 include/standard-headers/linux/pci_regs.h  |  30 +-
 include/standard-headers/linux/virtio_balloon.h|   3 +-
 include/standard-headers/linux/virtio_net.h|  13 +
 linux-headers/asm-powerpc/unistd.h |   3 +
 linux-headers/asm-s390/unistd.h| 401 +
 linux-headers/linux/psci.h |   3 +
 linux-headers/linux/vfio.h |  72 
 hw/ppc/spapr.c |   7 +
 hw/vfio/common.c   |  70 +++-
 hw/vfio/pci.c  |  22 ++
 13 files changed, 220 insertions(+), 417 deletions(-)

-- 
2.11.0

Re: [Qemu-devel] [RESEND PATCH] PPC: e500: Fix duplicate kernel load and device tree overlap

[David Engraf]

Hello David,

Am 09.02.2018 um 06:33 schrieb David Gibson:

On Thu, Feb 08, 2018 at 09:36:21AM +0100, David Engraf wrote:

This patch fixes an incorrect behavior when the -kernel argument has been
specified without -bios. In this case the kernel was loaded twice. At address
32M as a raw image and afterwards by load_elf/load_uimage at the
corresponding load address. In this case the region for the device tree and
the raw kernel image may overlap.

The patch fixes the behavior by loading the kernel image once with
load_elf/load_uimage and skips loading the raw image. It also ensures that
the device tree is generated behind bios/kernel/initrd.

Signed-off-by: David Engraf 


Sorry I've taken so long to respond to this.  I've been busy, then
away, then busy, then recovering from surgery, then...

I think this looks good overall, just a couple of details I'd like to
check, see below.


---
  hw/ppc/e500.c | 89 ---
  1 file changed, 48 insertions(+), 41 deletions(-)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index c4fe06ea2a..0321bd66a8 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -776,7 +776,6 @@ void ppce500_init(MachineState *machine, PPCE500Params 
*params)
  MemoryRegion *ram = g_new(MemoryRegion, 1);
  PCIBus *pci_bus;
  CPUPPCState *env = NULL;
-uint64_t loadaddr;
  hwaddr kernel_base = -1LL;
  int kernel_size = 0;
  hwaddr dt_base = 0;
@@ -913,11 +912,6 @@ void ppce500_init(MachineState *machine, PPCE500Params 
*params)
  /* Register spinning region */
  sysbus_create_simple("e500-spin", params->spin_base, NULL);
  
-if (cur_base < (32 * 1024 * 1024)) {

-/* u-boot occupies memory up to 32MB, so load blobs above */
-cur_base = (32 * 1024 * 1024);
-}
-
  if (params->has_mpc8xxx_gpio) {
  qemu_irq poweroff_irq;
  
@@ -952,36 +946,6 @@ void ppce500_init(MachineState *machine, PPCE500Params *params)

  sysbus_mmio_get_region(s, 0));
  }
  
-/* Load kernel. */

-if (machine->kernel_filename) {
-kernel_base = cur_base;
-kernel_size = load_image_targphys(machine->kernel_filename,
-  cur_base,
-  ram_size - cur_base);
-if (kernel_size < 0) {
-fprintf(stderr, "qemu: could not load kernel '%s'\n",
-machine->kernel_filename);
-exit(1);
-}
-
-cur_base += kernel_size;
-}
-
-/* Load initrd. */
-if (machine->initrd_filename) {
-initrd_base = (cur_base + INITRD_LOAD_PAD) & ~INITRD_PAD_MASK;
-initrd_size = load_image_targphys(machine->initrd_filename, 
initrd_base,
-  ram_size - initrd_base);
-
-if (initrd_size < 0) {
-fprintf(stderr, "qemu: could not load initial ram disk '%s'\n",
-machine->initrd_filename);
-exit(1);
-}
-
-cur_base = initrd_base + initrd_size;
-}
-
  /*
   * Smart firmware defaults ahead!
   *
@@ -1006,24 +970,67 @@ void ppce500_init(MachineState *machine, PPCE500Params 
*params)
  }
  filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
  
-bios_size = load_elf(filename, NULL, NULL, _entry, , NULL,

+bios_size = load_elf(filename, NULL, NULL, _entry, _base, NULL,
   1, PPC_ELF_MACHINE, 0, 0);
  if (bios_size < 0) {
  /*
   * Hrm. No ELF image? Try a uImage, maybe someone is giving us an
   * ePAPR compliant kernel
   */
-kernel_size = load_uimage(filename, _entry, , NULL,
-  NULL, NULL);
-if (kernel_size < 0) {
+bios_size = load_uimage(filename, _entry, _base, NULL,
+NULL, NULL);
+if (bios_size < 0) {
  fprintf(stderr, "qemu: could not load firmware '%s'\n", filename);
  exit(1);
  }
  }
+cur_base += bios_size;
  g_free(filename);
  
+/* Load bare kernel only if no bios/u-boot has been provided */

+if (machine->kernel_filename != bios_name) {


This condition seems weird.  Why would the kernel and bios images be
the same.  I guess this because of the logic setting bios_name above,
which also seems kind of weird.  Can you clarify what's going on here,
changing that bios_name setting logic, if necessary?


Basically I didn't change the logic to store the kernel name into 
bios_name when the -bios options was not provided. In this case the 
kernel will be used as payload. Indeed the name is a bit weird. What do 
you think about changing the names from bios to payload?



+kernel_base = cur_base;
+kernel_size = load_image_targphys(machine->kernel_filename,
+  cur_base,
+ 

Re: [Qemu-devel] [PATCH v1] Implement support for IEEE 754-201x minimumNumber/maximumNumber

[no-reply]

Hi,

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

Type: series
Message-id: 1518046997-22714-1-git-send-email-...@sifive.com
Subject: [Qemu-devel] [PATCH v1] Implement support for IEEE 754-201x 
minimumNumber/maximumNumber

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

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

git config --local diff.renamelimit 0
git config --local diff.renames True

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
1dbe78092c Implement support for IEEE 754-201x minimumNumber/maximumNumber

=== OUTPUT BEGIN ===
Checking PATCH 1/1: Implement support for IEEE 754-201x 
minimumNumber/maximumNumber...
ERROR: spaces required around that '*' (ctx:WxV)
#85: FILE: fpu/softfloat.c:7773:
+ float_status *status)  \
   ^

ERROR: spaces required around that '*' (ctx:WxV)
#91: FILE: fpu/softfloat.c:7779:
+ float_status *status)  \
   ^

total: 2 errors, 0 warnings, 94 lines checked

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

=== OUTPUT END ===

Test command exited with code: 1


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

Re: [Qemu-devel] [PATCH v5 12/23] RISC-V HTIF Console

[Michael Clark]

On Fri, Feb 9, 2018 at 5:35 AM, Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 02/07/2018 05:28 PM, Michael Clark wrote:
> > +++ b/hw/riscv/riscv_elf.c
> > @@ -0,0 +1,244 @@
> > +/*
> > + * elf.c - A simple package for manipulating symbol tables in elf
> binaries.
> > + *
> > + * Taken from
> > + * https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f03/www/
> > + * ftrace/elf.c
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "hw/riscv/riscv_elf.h"
> > +
> > +/*
> > + * elf_open - Map a binary into the address space and extract the
> > + * locations of the static and dynamic symbol tables and their string
> > + * tables. Return this information in a Elf object file handle that will
> > + * be passed to all of the other elf functions.
> > + */
> > +Elf_obj64 *elf_open64(const char *filename)
> > +{
> > +int i, fd;
> > +struct stat sbuf;
> > +Elf_obj64 *ep;
> > +Elf64_Shdr *shdr;
> > +
> > +ep = g_new(Elf_obj64, 1);
> > +
> > +/* Do some consistency checks on the binary */
> > +fd = open(filename, O_RDONLY);
> > +if (fd == -1) {
> > +fprintf(stderr, "Can't open \"%s\": %s\n", filename,
> strerror(errno));
> > +exit(1);
> > +}
> > +if (fstat(fd, ) == -1) {
> > +fprintf(stderr, "Can't stat \"%s\": %s\n", filename,
> strerror(errno));
> > +exit(1);
> > +}
> > +if (sbuf.st_size < sizeof(Elf64_Ehdr)) {
> > +fprintf(stderr, "\"%s\" is not an ELF binary object\n",
> filename);
> > +exit(1);
> > +}
> > +
> > +/* It looks OK, so map the Elf binary into our address space */
> > +ep->mlen = sbuf.st_size;
> > +ep->maddr = mmap(NULL, ep->mlen, PROT_READ, MAP_SHARED, fd, 0);
> > +if (ep->maddr == (void *)-1) {
> > +fprintf(stderr, "Can't mmap \"%s\": %s\n", filename,
> strerror(errno));
> > +exit(1);
> > +}
> > +close(fd);
> > +
> > +/* The Elf binary begins with the Elf header */
> > +ep->ehdr = ep->maddr;
> > +
> > +/* check we have a 64-bit little-endian RISC-V ELF object */
> > +if (ep->ehdr->e_ident[EI_MAG0] != ELFMAG0 ||
> > +ep->ehdr->e_ident[EI_MAG1] != ELFMAG1 ||
> > +ep->ehdr->e_ident[EI_MAG2] != ELFMAG2 ||
> > +ep->ehdr->e_ident[EI_MAG3] != ELFMAG3 ||
> > +ep->ehdr->e_ident[EI_CLASS] != ELFCLASS64 ||
> > +ep->ehdr->e_ident[EI_DATA] != ELFDATA2LSB ||
> > +ep->ehdr->e_machine != EM_RISCV)
> > +{
> > +fprintf(stderr, "\"%s\" is not a 64-bit RISC-V ELF object\n",
> filename);
> > +exit(1);
> > +}
> > +
> > +/*
> > + * Find the static and dynamic symbol tables and their string
> > + * tables in the the mapped binary. The sh_link field in symbol
> > + * table section headers gives the section index of the string
> > + * table for that symbol table.
> > + */
> > +shdr = (Elf64_Shdr *)(ep->maddr + ep->ehdr->e_shoff);
>
> This duplicates, badly, existing code within include/hw/elf_ops.h.
>
> In particular, this fails to bswap these fields.  As such, this code will
> only
> work on little-endian hosts.
>

There is enough information in the structures held in the syminfo table
used by the disassembler however elf_ops.h currently throws away all
symbols that are not STT_FUNC, and we are after STT_OBJECT symbols. We
would need to add an option to load_elf to load the entire symbol table.
Also, it runs qsort on the table by address, so we'd need to do a linear
scan for the HTIF symbols by name. There are only two symbols we need:
'fromhost' and 'tohost'.

/* We are only interested in function symbols.
   Throw everything else away.  */
if (syms[i].st_shndx == SHN_UNDEF ||
syms[i].st_shndx >= SHN_LORESERVE ||
ELF_ST_TYPE(syms[i].st_info) != STT_FUNC) {
nsyms--;
if (i < nsyms) {
syms[i] = syms[nsyms];
}
continue;
}

It would be really nice if HTIF just specified registers in device-tree;
alas it doesn't; and there is still quite a bit of code that depend on
using these magic HTIF 'fromhost' and 'tohost' symbols. riscv-tests for one
uses the HTIF mechanism and spike the official ISA simulator uses HTIF for
IO.

Re: [Qemu-devel] [V9fs-developer] [RFC] we should solve create-unlink-getattr idiom

[Veaceslav Falico]

Hi Yiwen, all,

On 2/9/2018 8:10 AM, jiangyiwen wrote:
> Hi Eric and Greg,
> 
> I encountered the similar problem with create-unlink-getattr idiom.
> I use the testcase that create-unlink-setattr idiom, and I see the
> bug is reported at https://bugs.launchpad.net/qemu/+bug/1336794.
> Then I also see you already fix the issue and push the patch to upstream.
> https://github.com/ericvh/linux/commit/eaf70223eac094291169f5a6de580351890162a2
> http://patchwork.ozlabs.org/patch/626194/
> 
> Unfortunately, the two patches are not merged into master, I don't know
> the reason, so I suggest if the patche can be merged into master, and
> it will solve the create-unlink-getattr idiom.

As a follow up - the create-unlink-setattr (mainly ftruncate and anything
else which works on fd instead of path) isn't fixed by these patches, but
I'm currently working on a new patch, obviously on top of those two, to
make the setattr work too.

It's based on the same logic as the above patches though - use FIDs with
open fd's guest side and use open fd's host side if possible with f*
functions, otherwise path with l* functions.

It's bigger than the QEMU getattr patch, as there are no f* functions
available for ftruncate case, for example.

So if those two patches could be merged it'd be a lot easier to then
go forward with the setattr fix.

Thank you!

> 
> Thanks,
> Yiwen
> 
> .
> 

Re: [Qemu-devel] [RFC PATCH 5/5] vfio/quirks: Enable ioeventfd quirks to be handled by vfio directly

[Peter Xu]

On Tue, Feb 06, 2018 at 05:26:46PM -0700, Alex Williamson wrote:
> With vfio ioeventfd support, we can program vfio-pci to perform a
> specified BAR write when an eventfd is triggered.  This allows the
> KVM ioeventfd to be wired directly to vfio-pci, entirely avoiding
> userspace handling for these events.  On the same micro-benchmark
> where the ioeventfd got us to almost 90% of performance versus
> disabling the GeForce quirks, this gets us to within 95%.
> 
> Signed-off-by: Alex Williamson 
> ---
>  hw/vfio/pci-quirks.c |   42 --
>  1 file changed, 36 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
> index e739efe601b1..35a4d5197e2d 100644
> --- a/hw/vfio/pci-quirks.c
> +++ b/hw/vfio/pci-quirks.c
> @@ -16,6 +16,7 @@
>  #include "qemu/range.h"
>  #include "qapi/error.h"
>  #include "qapi/visitor.h"
> +#include 
>  #include "hw/nvram/fw_cfg.h"
>  #include "pci.h"
>  #include "trace.h"
> @@ -287,13 +288,27 @@ static VFIOQuirk *vfio_quirk_alloc(int nr_mem)
>  return quirk;
>  }
>  
> -static void vfio_ioeventfd_exit(VFIOIOEventFD *ioeventfd)
> +static void vfio_ioeventfd_exit(VFIOPCIDevice *vdev, VFIOIOEventFD 
> *ioeventfd)
>  {
> +struct vfio_device_ioeventfd vfio_ioeventfd;
> +
>  QLIST_REMOVE(ioeventfd, next);
> +
>  memory_region_del_eventfd(ioeventfd->mr, ioeventfd->addr, 
> ioeventfd->size,
>ioeventfd->match_data, ioeventfd->data,
>>e);
> +
>  qemu_set_fd_handler(event_notifier_get_fd(>e), NULL, NULL, 
> NULL);
> +
> +vfio_ioeventfd.argsz = sizeof(vfio_ioeventfd);
> +vfio_ioeventfd.flags = ioeventfd->size;
> +vfio_ioeventfd.data = ioeventfd->data;
> +vfio_ioeventfd.offset = ioeventfd->region->fd_offset +
> +ioeventfd->region_addr;
> +vfio_ioeventfd.fd = -1;
> +
> +ioctl(vdev->vbasedev.fd, VFIO_DEVICE_IOEVENTFD, _ioeventfd);
> +
>  event_notifier_cleanup(>e);
>  g_free(ioeventfd);
>  }
> @@ -315,6 +330,8 @@ static VFIOIOEventFD *vfio_ioeventfd_init(VFIOPCIDevice 
> *vdev,
>hwaddr region_addr)
>  {
>  VFIOIOEventFD *ioeventfd = g_malloc0(sizeof(*ioeventfd));
> +struct vfio_device_ioeventfd vfio_ioeventfd;
> +char vfio_enabled = '+';
>  
>  if (event_notifier_init(>e, 0)) {
>  g_free(ioeventfd);
> @@ -329,15 +346,28 @@ static VFIOIOEventFD *vfio_ioeventfd_init(VFIOPCIDevice 
> *vdev,
>  ioeventfd->region = region;
>  ioeventfd->region_addr = region_addr;
>  
> -qemu_set_fd_handler(event_notifier_get_fd(>e),
> -vfio_ioeventfd_handler, NULL, ioeventfd);
> +vfio_ioeventfd.argsz = sizeof(vfio_ioeventfd);
> +vfio_ioeventfd.flags = ioeventfd->size;
> +vfio_ioeventfd.data = ioeventfd->data;
> +vfio_ioeventfd.offset = ioeventfd->region->fd_offset +
> +ioeventfd->region_addr;
> +vfio_ioeventfd.fd = event_notifier_get_fd(>e);
> +
> +if (ioctl(vdev->vbasedev.fd,
> +  VFIO_DEVICE_IOEVENTFD, _ioeventfd) != 0) {
> +qemu_set_fd_handler(event_notifier_get_fd(>e),
> +vfio_ioeventfd_handler, NULL, ioeventfd);
> +vfio_enabled = '-';

Would the performance be even slower if a new QEMU runs on a old
kernel due to these ioeventfds (MMIO -> eventfd -> same MMIO again)?
If so, shall we only enable this ioeventfd enhancement only if we
detected that the kernel supports this new feature (assuming this
feature bit won't change after VM starts)?

Then, could we avoid the slow path at all (qemu_set_fd_handler)?

Thanks,

-- 
Peter Xu

[Qemu-devel] [V9fs-developer] [RFC] we should solve create-unlink-getattr idiom

[jiangyiwen]

Hi Eric and Greg,

I encountered the similar problem with create-unlink-getattr idiom.
I use the testcase that create-unlink-setattr idiom, and I see the
bug is reported at https://bugs.launchpad.net/qemu/+bug/1336794.
Then I also see you already fix the issue and push the patch to upstream.
https://github.com/ericvh/linux/commit/eaf70223eac094291169f5a6de580351890162a2
http://patchwork.ozlabs.org/patch/626194/

Unfortunately, the two patches are not merged into master, I don't know
the reason, so I suggest if the patche can be merged into master, and
it will solve the create-unlink-getattr idiom.

Thanks,
Yiwen

Re: [Qemu-devel] Functional tests (AKA Avocado-based tests)

[Fam Zheng]

On Thu, Jan 18, 2018 at 5:07 PM, Amador Pahim  wrote:
> Expanding on that, the vmimage lib downloads and caches the so called
> "cloud images" from distros own repositories. Here's[1] some
> documentation with usage examples, including one example on how to add
> your own image provider.

Linux distributions are easy anyway, and sometimes even Docker is
simpler and good enough ($QEMU/tests/docker). Other architectures and
OS families, such as non-x86_64, BSD, Windows, macOS are all difficult
topics. $QEMU/tests/vm tried to attack that but is still not complete.
What are your thoughts on that subject?

Re: [Qemu-devel] [RFC PATCH] vfio/pci: Add ioeventfd support

[Peter Xu]

On Tue, Feb 06, 2018 at 05:08:14PM -0700, Alex Williamson wrote:

[...]

> +long vfio_pci_ioeventfd(struct vfio_pci_device *vdev, loff_t offset,
> + uint64_t data, int count, int fd)
> +{
> + struct pci_dev *pdev = vdev->pdev;
> + loff_t pos = offset & VFIO_PCI_OFFSET_MASK;
> + int ret, bar = VFIO_PCI_OFFSET_TO_INDEX(offset);
> + struct vfio_pci_ioeventfd *ioeventfd;
> + int (*handler)(void *, void *);
> + unsigned long val;
> +
> + /* Only support ioeventfds into BARs */
> + if (bar > VFIO_PCI_BAR5_REGION_INDEX)
> + return -EINVAL;
> +
> + if (pos + count > pci_resource_len(pdev, bar))
> + return -EINVAL;
> +
> + /* Disallow ioeventfds working around MSI-X table writes */
> + if (bar == vdev->msix_bar &&
> + !(pos + count <= vdev->msix_offset ||
> +   pos >= vdev->msix_offset + vdev->msix_size))
> + return -EINVAL;
> +
> + switch (count) {
> + case 1:
> + handler = _pci_ioeventfd_handler8;
> + val = data;
> + break;
> + case 2:
> + handler = _pci_ioeventfd_handler16;
> + val = le16_to_cpu(data);
> + break;
> + case 4:
> + handler = _pci_ioeventfd_handler32;
> + val = le32_to_cpu(data);
> + break;
> +#ifdef iowrite64
> + case 8:
> + handler = _pci_ioeventfd_handler64;
> + val = le64_to_cpu(data);
> + break;
> +#endif
> + default:
> + return -EINVAL;
> + }
> +
> + ret = vfio_pci_setup_barmap(vdev, bar);
> + if (ret)
> + return ret;
> +
> + mutex_lock(>ioeventfds_lock);
> +
> + list_for_each_entry(ioeventfd, >ioeventfds_list, next) {
> + if (ioeventfd->pos == pos && ioeventfd->bar == bar &&
> + ioeventfd->data == data && ioeventfd->count == count) {
> + if (fd == -1) {
> + vfio_virqfd_disable(>virqfd);
> + list_del(>next);
> + kfree(ioeventfd);
> + ret = 0;
> + } else
> + ret = -EEXIST;
> +
> + goto out_unlock;
> + }
> + }
> +
> + if (fd < 0) {
> + ret = -ENODEV;
> + goto out_unlock;
> + }
> +
> + ioeventfd = kzalloc(sizeof(*ioeventfd), GFP_KERNEL);
> + if (!ioeventfd) {
> + ret = -ENOMEM;
> + goto out_unlock;
> + }
> +
> + ioeventfd->pos = pos;
> + ioeventfd->bar = bar;
> + ioeventfd->data = data;
> + ioeventfd->count = count;
> +
> + ret = vfio_virqfd_enable(vdev->barmap[ioeventfd->bar] + ioeventfd->pos,
> +  handler, NULL, (void *)val,
> +  >virqfd, fd);
> + if (ret) {
> + kfree(ioeventfd);
> + goto out_unlock;
> + }
> +
> + list_add(>next, >ioeventfds_list);

Is there a limit on how many ioeventfds that can be created?

IIUC we'll create this eventfd "automatically" if a MMIO addr/data
triggered continuously for N=10 times, then would it be safer we have
a limitation on maximum eventfds?  Or not sure whether a malicious
guest can consume the host memory by sending:

- addr1/data1, 10 times
- addr2/data2, 10 times
- ...

To create unlimited ioeventfds?  Thanks,

-- 
Peter Xu

Re: [Qemu-devel] [PATCH v6 00/28] Migration: postcopy failure recovery

[Peter Xu]

On Thu, Feb 08, 2018 at 06:31:04PM +0800, Peter Xu wrote:
> Tree is pushed here for better reference and testing (online tree
> includes monitor OOB series):
> 
>   https://github.com/xzpeter/qemu/tree/postcopy-recovery-support

Hello, Patchew,

Based-on: <20180124053957.29145-1-pet...@redhat.com>

-- 
Peter Xu

Re: [Qemu-devel] [PATCH v6 00/28] Migration: postcopy failure recovery

[Fam Zheng]

On Fri, Feb 9, 2018 at 2:07 PM, Peter Xu  wrote:
> On Thu, Feb 08, 2018 at 03:25:21AM -0800, no-re...@patchew.org wrote:
>> Hi,
>>
>> This series failed docker-mingw@fedora build test. Please find the testing 
>> commands and
>> their output below. If you have Docker installed, you can probably reproduce 
>> it
>> locally.
>
> For all the five patchew reports: I forgot to add based-on tag.  This
> series is based on monitor-oob series.

OK. If you reply with a correct Based-on: tag, patchew will
automatically retry to apply it. (I think it currently doesn't re-run
the tests, but we could probably add such a feature to it, as a note
to myself.)

Fam

>
> --
> Peter Xu

Re: [Qemu-devel] [PATCH v6 00/28] Migration: postcopy failure recovery

[Peter Xu]

On Thu, Feb 08, 2018 at 03:25:21AM -0800, no-re...@patchew.org wrote:
> Hi,
> 
> This series failed docker-mingw@fedora build test. Please find the testing 
> commands and
> their output below. If you have Docker installed, you can probably reproduce 
> it
> locally.

For all the five patchew reports: I forgot to add based-on tag.  This
series is based on monitor-oob series.

-- 
Peter Xu

Re: [Qemu-devel] [RESEND PATCH] PPC: e500: Fix duplicate kernel load and device tree overlap

[David Gibson]

On Thu, Feb 08, 2018 at 09:36:21AM +0100, David Engraf wrote:
> This patch fixes an incorrect behavior when the -kernel argument has been
> specified without -bios. In this case the kernel was loaded twice. At address
> 32M as a raw image and afterwards by load_elf/load_uimage at the
> corresponding load address. In this case the region for the device tree and
> the raw kernel image may overlap.
> 
> The patch fixes the behavior by loading the kernel image once with
> load_elf/load_uimage and skips loading the raw image. It also ensures that
> the device tree is generated behind bios/kernel/initrd.
> 
> Signed-off-by: David Engraf 

Sorry I've taken so long to respond to this.  I've been busy, then
away, then busy, then recovering from surgery, then...

I think this looks good overall, just a couple of details I'd like to
check, see below.

> ---
>  hw/ppc/e500.c | 89 
> ---
>  1 file changed, 48 insertions(+), 41 deletions(-)
> 
> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> index c4fe06ea2a..0321bd66a8 100644
> --- a/hw/ppc/e500.c
> +++ b/hw/ppc/e500.c
> @@ -776,7 +776,6 @@ void ppce500_init(MachineState *machine, PPCE500Params 
> *params)
>  MemoryRegion *ram = g_new(MemoryRegion, 1);
>  PCIBus *pci_bus;
>  CPUPPCState *env = NULL;
> -uint64_t loadaddr;
>  hwaddr kernel_base = -1LL;
>  int kernel_size = 0;
>  hwaddr dt_base = 0;
> @@ -913,11 +912,6 @@ void ppce500_init(MachineState *machine, PPCE500Params 
> *params)
>  /* Register spinning region */
>  sysbus_create_simple("e500-spin", params->spin_base, NULL);
>  
> -if (cur_base < (32 * 1024 * 1024)) {
> -/* u-boot occupies memory up to 32MB, so load blobs above */
> -cur_base = (32 * 1024 * 1024);
> -}
> -
>  if (params->has_mpc8xxx_gpio) {
>  qemu_irq poweroff_irq;
>  
> @@ -952,36 +946,6 @@ void ppce500_init(MachineState *machine, PPCE500Params 
> *params)
>  sysbus_mmio_get_region(s, 0));
>  }
>  
> -/* Load kernel. */
> -if (machine->kernel_filename) {
> -kernel_base = cur_base;
> -kernel_size = load_image_targphys(machine->kernel_filename,
> -  cur_base,
> -  ram_size - cur_base);
> -if (kernel_size < 0) {
> -fprintf(stderr, "qemu: could not load kernel '%s'\n",
> -machine->kernel_filename);
> -exit(1);
> -}
> -
> -cur_base += kernel_size;
> -}
> -
> -/* Load initrd. */
> -if (machine->initrd_filename) {
> -initrd_base = (cur_base + INITRD_LOAD_PAD) & ~INITRD_PAD_MASK;
> -initrd_size = load_image_targphys(machine->initrd_filename, 
> initrd_base,
> -  ram_size - initrd_base);
> -
> -if (initrd_size < 0) {
> -fprintf(stderr, "qemu: could not load initial ram disk '%s'\n",
> -machine->initrd_filename);
> -exit(1);
> -}
> -
> -cur_base = initrd_base + initrd_size;
> -}
> -
>  /*
>   * Smart firmware defaults ahead!
>   *
> @@ -1006,24 +970,67 @@ void ppce500_init(MachineState *machine, PPCE500Params 
> *params)
>  }
>  filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
>  
> -bios_size = load_elf(filename, NULL, NULL, _entry, , NULL,
> +bios_size = load_elf(filename, NULL, NULL, _entry, _base, NULL,
>   1, PPC_ELF_MACHINE, 0, 0);
>  if (bios_size < 0) {
>  /*
>   * Hrm. No ELF image? Try a uImage, maybe someone is giving us an
>   * ePAPR compliant kernel
>   */
> -kernel_size = load_uimage(filename, _entry, , NULL,
> -  NULL, NULL);
> -if (kernel_size < 0) {
> +bios_size = load_uimage(filename, _entry, _base, NULL,
> +NULL, NULL);
> +if (bios_size < 0) {
>  fprintf(stderr, "qemu: could not load firmware '%s'\n", 
> filename);
>  exit(1);
>  }
>  }
> +cur_base += bios_size;
>  g_free(filename);
>  
> +/* Load bare kernel only if no bios/u-boot has been provided */
> +if (machine->kernel_filename != bios_name) {

This condition seems weird.  Why would the kernel and bios images be
the same.  I guess this because of the logic setting bios_name above,
which also seems kind of weird.  Can you clarify what's going on here,
changing that bios_name setting logic, if necessary?

> +kernel_base = cur_base;
> +kernel_size = load_image_targphys(machine->kernel_filename,
> +  cur_base,
> +  ram_size - cur_base);
> +if (kernel_size < 0) {
> +fprintf(stderr, "qemu: could not load kernel '%s'\n",
> +   

[Qemu-devel] [PATCH v7 3/3] docs: Document share-rw property more thoroughly

[Fam Zheng]

Suggested-by: Stefan Hajnoczi 
Signed-off-by: Fam Zheng 
---
 docs/qemu-block-drivers.texi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/docs/qemu-block-drivers.texi b/docs/qemu-block-drivers.texi
index cd74767ed3..f1793692bb 100644
--- a/docs/qemu-block-drivers.texi
+++ b/docs/qemu-block-drivers.texi
@@ -845,6 +845,16 @@ QEMU transparently handles lock handover during shared 
storage migration.  For
 shared virtual disk images between multiple VMs, the "share-rw" device option
 should be used.
 
+By default, the guest has exclusive write access to its disk image. If the
+guest can safely share the disk image with other writers the @code{-device
+...,share-rw=on} parameter can be used.  This is only safe if the guest is
+running software, such as a cluster file system, that coordinates disk accesses
+to avoid corruption.
+
+Note that share-rw=on only declares the guest's ability to share the disk.
+Some QEMU features, such as image file formats, require exclusive write access
+to the disk image and this is unaffected by the share-rw=on option.
+
 Alternatively, locking can be fully disabled by "locking=off" block device
 option. In the command line, the option is usually in the form of
 "file.locking=off" as the protocol driver is normally placed as a "file" child
-- 
2.14.3

[Qemu-devel] [PATCH v7 1/3] qemu-img.texi: Clean up parameter list

[Fam Zheng]

Split options out of the "@table @var" section and create a "@table
@option", then use whitespaces and blank lines consistently.

Suggested-by: Kevin Wolf 
Signed-off-by: Fam Zheng 
---
 qemu-img.texi | 66 +++
 1 file changed, 39 insertions(+), 27 deletions(-)

diff --git a/qemu-img.texi b/qemu-img.texi
index fdcf120f36..60a0e080c6 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -33,38 +33,14 @@ The following commands are supported:
 
 Command parameters:
 @table @var
+
 @item filename
- is a disk image filename
-
-@item --object @var{objectdef}
-
-is a QEMU user creatable object definition. See the @code{qemu(1)} manual
-page for a description of the object properties. The most common object
-type is a @code{secret}, which is used to supply passwords and/or encryption
-keys.
-
-@item --image-opts
-
-Indicates that the source @var{filename} parameter is to be interpreted as a
-full option string, not a plain filename. This parameter is mutually
-exclusive with the @var{-f} parameter.
-
-@item --target-image-opts
-
-Indicates that the @var{output_filename} parameter(s) are to be interpreted as
-a full option string, not a plain filename. This parameter is mutually
-exclusive with the @var{-O} parameters. It is currently required to also use
-the @var{-n} parameter to skip image creation. This restriction may be relaxed
-in a future release.
+is a disk image filename
 
 @item fmt
 is the disk image format. It is guessed automatically in most cases. See below
 for a description of the supported disk formats.
 
-@item --backing-chain
-will enumerate information about backing files in a disk image chain. Refer
-below for further description.
-
 @item size
 is the disk image size in bytes. Optional suffixes @code{k} or @code{K}
 (kilobyte, 1024) @code{M} (megabyte, 1024k) and @code{G} (gigabyte, 1024M)
@@ -74,42 +50,78 @@ and T (terabyte, 1024G) are supported.  @code{b} is ignored.
 is the destination disk image filename
 
 @item output_fmt
- is the destination format
+is the destination format
+
 @item options
 is a comma separated list of format specific options in a
 name=value format. Use @code{-o ?} for an overview of the options supported
 by the used format or see the format descriptions below for details.
+
 @item snapshot_param
 is param used for internal snapshot, format is
 'snapshot.id=[ID],snapshot.name=[NAME]' or '[ID_OR_NAME]'
+
 @item snapshot_id_or_name
 is deprecated, use snapshot_param instead
 
+@end table
+
+@table @option
+
+@item --object @var{objectdef}
+is a QEMU user creatable object definition. See the @code{qemu(1)} manual
+page for a description of the object properties. The most common object
+type is a @code{secret}, which is used to supply passwords and/or encryption
+keys.
+
+@item --image-opts
+Indicates that the source @var{filename} parameter is to be interpreted as a
+full option string, not a plain filename. This parameter is mutually
+exclusive with the @var{-f} parameter.
+
+@item --target-image-opts
+Indicates that the @var{output_filename} parameter(s) are to be interpreted as
+a full option string, not a plain filename. This parameter is mutually
+exclusive with the @var{-O} parameters. It is currently required to also use
+the @var{-n} parameter to skip image creation. This restriction may be relaxed
+in a future release.
+
+@item --backing-chain
+will enumerate information about backing files in a disk image chain. Refer
+below for further description.
+
 @item -c
 indicates that target image must be compressed (qcow format only)
+
 @item -h
 with or without a command shows help and lists the supported formats
+
 @item -p
 display progress bar (compare, convert and rebase commands only).
 If the @var{-p} option is not used for a command that supports it, the
 progress is reported when the process receives a @code{SIGUSR1} or
 @code{SIGINFO} signal.
+
 @item -q
 Quiet mode - do not print any output (except errors). There's no progress bar
 in case both @var{-q} and @var{-p} options are used.
+
 @item -S @var{size}
 indicates the consecutive number of bytes that must contain only zeros
 for qemu-img to create a sparse image during conversion. This value is rounded
 down to the nearest 512 bytes. You may use the common size suffixes like
 @code{k} for kilobytes.
+
 @item -t @var{cache}
 specifies the cache mode that should be used with the (destination) file. See
 the documentation of the emulator's @code{-drive cache=...} option for allowed
 values.
+
 @item -T @var{src_cache}
 specifies the cache mode that should be used with the source file(s). See
 the documentation of the emulator's @code{-drive cache=...} option for allowed
 values.
+
 @end table
 
 Parameters to snapshot subcommand:
-- 
2.14.3

[Qemu-devel] [PATCH v7 0/3] qemu-img: Document --force-share / -U

[Fam Zheng]

v7: Tweak wording again "allowing concurrent writers" -> "allowing other QEMU
processes to open it in write mode". [Eric, Stefan, Kevin]
Add patch to document share-rw. [Stefan]

v6: Tweak wording ("concurrent writers"). [Max]

Fam Zheng (3):
  qemu-img.texi: Clean up parameter list
  qemu-img: Document --force-share / -U
  docs: Document share-rw property more thoroughly

 docs/qemu-block-drivers.texi | 10 ++
 qemu-img.texi| 74 
 2 files changed, 57 insertions(+), 27 deletions(-)

-- 
2.14.3

[Qemu-devel] [PATCH v7 2/3] qemu-img: Document --force-share / -U

[Fam Zheng]

Signed-off-by: Fam Zheng 
Signed-off-by: Kevin Wolf 
---
 qemu-img.texi | 8 
 1 file changed, 8 insertions(+)

diff --git a/qemu-img.texi b/qemu-img.texi
index 60a0e080c6..8a26400adb 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -86,6 +86,14 @@ exclusive with the @var{-O} parameters. It is currently 
required to also use
 the @var{-n} parameter to skip image creation. This restriction may be relaxed
 in a future release.
 
+@item --force-share (-U)
+If specified, @code{qemu-img} will open the image in shared mode, allowing
+other QEMU processes to open it in write mode. For example, this can be used to
+get the image information (with 'info' subcommand) when the image is used by a
+running guest.  Note that this could produce inconsistent results because of
+concurrent metadata changes, etc. This option is only allowed when opening
+images in read-only mode.
+
 @item --backing-chain
 will enumerate information about backing files in a disk image chain. Refer
 below for further description.
-- 
2.14.3

[Qemu-devel] [PULL v3 00/20] Miscellaneous patches for 2018-02-07

[Markus Armbruster]

The following changes since commit 008a51bbb343972dd8cf09126da8c3b87f4e1c96:

  Merge remote-tracking branch 'remotes/famz/tags/staging-pull-request' into 
staging (2018-02-08 14:31:51 +)

are available in the git repository at:

  git://repo.or.cz/qemu/armbru.git tags/pull-misc-2018-02-07-v3

for you to fetch changes up to 59a92828ad355a0194248cab9ce98dddced04363:

  Move include qemu/option.h from qemu-common.h to actual users (2018-02-09 
05:07:33 +0100)


Miscellaneous patches for 2018-02-07


Gerd Hoffmann (1):
  vnc: use stubs for CONFIG_VNC=n dummy functions

Markus Armbruster (19):
  Use #include "..." for our own headers, <...> for others
  Clean up includes
  Drop superfluous includes of qapi-types.h and test-qapi-types.h
  Include qapi/error.h exactly where needed
  Drop superfluous includes of qapi/qmp/qerror.h
  Include qmp-commands.h exactly where needed
  Typedef the subtypes of QObject in qemu/typedefs.h, too
  Eliminate qapi/qmp/types.h
  qdict qlist: Make most helper macros functions
  Include qapi/qmp/qobject.h exactly where needed
  Include qapi/qmp/qlist.h exactly where needed
  Include qapi/qmp/qdict.h exactly where needed
  Include qapi/qmp/qstring.h exactly where needed
  Include qapi/qmp/qbool.h exactly where needed
  Include qapi/qmp/qnum.h exactly where needed
  Include qapi/qmp/qnull.h exactly where needed
  Drop superfluous includes of qapi/qmp/dispatch.h
  Drop superfluous includes of qapi/qmp/qjson.h
  Move include qemu/option.h from qemu-common.h to actual users

 accel/accel.c  |  2 +-
 audio/wavcapture.c |  1 +
 backends/cryptodev.c   |  1 -
 backends/hostmem.c |  1 -
 backends/tpm.c |  1 -
 balloon.c  |  2 +-
 block.c|  7 --
 block/blkdebug.c   |  2 +-
 block/blkverify.c  |  1 +
 block/block-backend.c  |  2 ++
 block/crypto.c |  2 ++
 block/curl.c   |  5 +++--
 block/file-posix.c |  3 +++
 block/file-win32.c |  3 +++
 block/gluster.c|  3 +++
 block/iscsi-opts.c |  1 +
 block/iscsi.c  |  4 +++-
 block/nbd.c|  2 +-
 block/nfs.c|  2 +-
 block/null.c   |  1 +
 block/nvme.c   |  1 +
 block/parallels.c  |  3 ++-
 block/parallels.h  |  1 -
 block/qapi.c   |  7 +-
 block/qcow.c   |  5 +++--
 block/qcow2-cluster.c  |  1 -
 block/qcow2.c  |  6 --
 block/qed.c|  2 +-
 block/quorum.c |  4 ++--
 block/rbd.c|  3 +++
 block/replication.c|  2 +-
 block/sheepdog.c   |  1 +
 block/snapshot.c   |  2 ++
 block/ssh.c|  2 ++
 block/throttle.c   |  1 +
 block/vdi.c|  1 +
 block/vhdx.c   |  2 +-
 block/vmdk.c   |  1 +
 block/vpc.c|  3 ++-
 block/vvfat.c  |  4 +++-
 block/write-threshold.c|  2 +-
 blockdev-nbd.c |  2 +-
 blockdev.c |  6 +-
 blockjob.c |  3 +--
 chardev/char-file.c|  3 ++-
 chardev/char-mux.c |  3 ++-
 chardev/char-parallel.c|  2 ++
 chardev/char-pipe.c|  2 ++
 chardev/char-ringbuf.c |  3 +++
 chardev/char-serial.c  |  2 ++
 chardev/char-socket.c  |  2 ++
 chardev/char-stdio.c   |  3 ++-
 chardev/char-udp.c |  2 ++
 chardev/char.c |  3 +++
 

Re: [Qemu-devel] [PATCH v6 2/2] qemu-img: Document --force-share / -U

[Fam Zheng]

On Thu, 02/01 11:44, Stefan Hajnoczi wrote:
> On Wed, Jan 31, 2018 at 03:22:49PM +0100, Kevin Wolf wrote:
> > Am 31.01.2018 um 15:12 hat Stefan Hajnoczi geschrieben:
> > > There should be a separate paragraph in docs/qemu-block-drivers.texi
> > > explaining that share-rw=on can be used safely with format=raw if the
> > > guests are configured to safely access a shared disk.  It should also
> > > mention that share-rw=on is unsafe for image formats.
> > 
> > share-rw=on is a -device option and only about the guest, not about the
> > backend. It is never unsafe if the guest can cope with external writers.
> > It just doesn't prevent qemu from locking the image file for image
> > formats.
> 
> Thanks for the explanation.  Documentation on share-rw=on|off would be
> nice.
> 
> Maybe something like:
> 
>   By default the guest has exclusive write access to its disk image.
>   This is enforced by QEMU via file locking.  If the guest can safely
>   share the disk image with other writers the -device ...,share-rw=on
>   parameter can be used.  This is only safe if the guest is running
>   software, such as a cluster file system, that coordinates disk
>   accesses to avoid corruption.
> 
>   Note that share-rw=on only declares the guest's ability to share the
>   disk.  Some QEMU features, such as image file formats, require
>   exclusive write access to the disk image and this is unaffected by the
>   share-rw=on option.

I will add these paragraphs to the "image locking" seciton in
docs/qemu-block-drivers.texi.

Fam

Re: [Qemu-devel] [PATCH v6 2/2] qemu-img: Document --force-share / -U

[Fam Zheng]

On Thu, 02/01 11:44, Stefan Hajnoczi wrote:
> On Wed, Jan 31, 2018 at 03:22:49PM +0100, Kevin Wolf wrote:
> > Am 31.01.2018 um 15:12 hat Stefan Hajnoczi geschrieben:
> > > There should be a separate paragraph in docs/qemu-block-drivers.texi
> > > explaining that share-rw=on can be used safely with format=raw if the
> > > guests are configured to safely access a shared disk.  It should also
> > > mention that share-rw=on is unsafe for image formats.
> > 
> > share-rw=on is a -device option and only about the guest, not about the
> > backend. It is never unsafe if the guest can cope with external writers.
> > It just doesn't prevent qemu from locking the image file for image
> > formats.
> 
> Thanks for the explanation.  Documentation on share-rw=on|off would be
> nice.
> 
> Maybe something like:
> 
>   By default the guest has exclusive write access to its disk image.
>   This is enforced by QEMU via file locking.  If the guest can safely
>   share the disk image with other writers the -device ...,share-rw=on
>   parameter can be used.  This is only safe if the guest is running
>   software, such as a cluster file system, that coordinates disk
>   accesses to avoid corruption.
> 
>   Note that share-rw=on only declares the guest's ability to share the
>   disk.  Some QEMU features, such as image file formats, require
>   exclusive write access to the disk image and this is unaffected by the
>   share-rw=on option.

I will add these paragraphs to the "image locking" seciton in
docs/qemu-block-drivers.texi.

Fam

Re: [Qemu-devel] [PATCH] target-i386: adds PV_DEDICATED hint CPUID feature bit

[Wanpeng Li]

2018-02-09 2:12 GMT+08:00 Eduardo Habkost :
> On Thu, Feb 08, 2018 at 05:44:20PM +0800, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> Add PV_DEDICATED hint cpuid feature bit.
>>
> [...]
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index d70954b..cf48931 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -4076,6 +4076,9 @@ static int x86_cpu_filter_features(X86CPU *cpu)
>>  x86_cpu_get_supported_feature_word(w, false);
>>  uint32_t requested_features = env->features[w];
>>  env->features[w] &= host_feat;
>> +if (cpu->pv_dedicated && (w == FEAT_KVM)) {
>> +env->features[w] |= CPUID_PV_DEDICATED;
>> +}
>
> Why do this trick here instead of just adding "pv-dedicated" to
> feature_word_info[FEAT_KVM].feat_names?

Actually this hint doesn't depend on KVM, just qemu command-line gives
a hint and then guest kernel can recognize it. Is there a nicer
proposal in qemu? Paolo?

Regards,
Wanpeng Li

Re: [Qemu-devel] [PATCH v2 0/3] virtio-balloon: free page hint reporting support

[Wei Wang]

On 02/09/2018 04:15 AM, Dr. David Alan Gilbert wrote:

* Wei Wang (wei.w.w...@intel.com) wrote:

This is the deivce part implementation to add a new feature,
VIRTIO_BALLOON_F_FREE_PAGE_HINT to the virtio-balloon device. The device
receives the guest free page hints from the driver and clears the
corresponding bits in the dirty bitmap, so that those free pages are
not transferred by the migration thread to the destination.

Please see the driver patch link for test results:
https://lkml.org/lkml/2018/2/4/60

Hi Wei,
I'll look at the code a bit more - but first some more basic
questions on that lkml post:

 a) The idle guest time thing is a nice result; can you just state
what the host was, speed of connection, and what other options
you were using?

 b) The workload test, the one with the kernel compile; you list
the kernel compile time but don't mention any changes in the
migration times of the ping-pong; can you give those times as
well?

 c) What's your real workload that this is aimed at?
Is it really for people migrating idle VMs - or do you have some
NFV application in mind, if so why not include a figure for
those?



Hi Dave,

Thanks for joining the review. Please see below info.

a) Environment info
- Host:
- Physical CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- kernel: 3.10.0

- Guest:
- kernel: 4.15.0
- QEMU setup: -cpu host -M pc -smp 4,threads=1,sockets=1 -m 8G 
--mem-prealloc -realtime mlock=on -balloon virtio,free-page-hint=true


- Migration setup:
- migrate_set_speed 0
- migrate_set_downtime 0.01  (10ms)

b) Michael asked the same question on the kernel patches, I'll reply 
there with you cc-ed, so that kernel maintainers can also see it. Btw, 
do you have any other workloads you would suggest to have a try?


c) This feature is requested by many customers (e.g. general cloud 
vendors). It's for general use cases. As long as the guest has free 
memory, it will benefit from this optimization when doing migration. 
It's not specific for NFV usages, but for sure NFV will also benefit 
from this feature if we think about service chaining, where multiple VMs 
need to co-work with each other. In that case, migrating one VM will 
just break the working model, which means we will need to migrate all 
the VMs. A shorter migration time will be very helpful.



Best,
Wei

Re: [Qemu-devel] [PATCH 00/10] linux-user: Speed up guest space initialization on 32-bit ARM target

[Luke Shumaker]

Ping.

On Thu, 28 Dec 2017 13:08:03 -0500,
Luke Shumaker wrote:
> 
> From: Luke Shumaker 
> 
> The goal of this patchset is to fix
> https://bugs.launchpad.net/qemu/+bug/1740219
> 
> The gist is that the current linear search for an acceptable address
> range is a bad strategy when the reason we didn't get a good address
> on the first try is that we've having problems mapping the commpage
> for the 32-bit ARM target; especially if ASLR is disabled.
> 
> I think that only the final patch in this patchset is actually
> necessary to fix the issue; but I didn't feel comfortable writing it
> without also makeing the preceding (small) changes.
> 
> Luke Shumaker (10):
>   linux-user: Use #if to only call validate_guest_space for 32-bit ARM
> target
>   linux-user: Rename validate_guest_space => init_guest_commpage
>   linux-user: init_guest_space: Clean up if we can't initialize the
> commpage
>   linux-user: init_guest_space: Correctly handle guest_start in commpage
> initialization
>   linux-user: init_guest_space: Clarify page alignment logic
>   linux-user: init_guest_commpage: Add a comment about size check
>   linux-user: init_guest_space: Clean up control flow a bit
>   linux-user: init_guest_space: Don't try to align if we'll reject it
>   linux-user: init_guest_space: Add a comment about search strategy
>   linux-user: init_guest_space: Try to make ARM space+commpage
> continuous
> 
>  linux-user/elfload.c | 145 
> ---
>  1 file changed, 114 insertions(+), 31 deletions(-)
> 
> -- 
> 2.15.1
> 
> Happy hacking,
> ~ Luke Shumaker
> 

Re: [Qemu-devel] [PATCH 3/3] build-sys: enable sanitizers by default with --enable-debug

[Fam Zheng]

On Thu, 02/08 20:03, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Feb 8, 2018 at 6:46 PM, Paolo Bonzini  wrote:
> > On 08/02/2018 17:23, Marc-André Lureau wrote:
> >> The original commit 247724cb302af5d70c8853154b640dfabf2bbb56 was meant
> >> to enable sanitizers by default when --enable-debug, but failed
> >> because of a gcc static linking bug. Try to enable it back now that
> >> there is a stronger check.
> >>
> >> Signed-off-by: Marc-André Lureau 
> >
> > I'm more afraid that there are quite a few reports from sanitizers.  I
> > wonder if that makes --enable-debug unusable; as a non-user of
> > --enable-debug I'm a bit wary of pushing this patch.
> 
> I understand the concern, but at the same time, people should care
> about fixing those. If they want to keep ignoring them (for bad
> reasons), they can --disable-sanitizers. At least, I would want to
> reach a point where no ASAN regression get introduced in x86 target.
> It would be nice if patchew warn on new ASAN reports for example.

Could you write a docker test for that?

Fam

Re: [Qemu-devel] [PATCH] block: unify blocksize types

[Fam Zheng]

On Thu, 02/08 14:28, Piotr Sarna wrote:
> BlockSizes structure used in block size probing has uint32_t types
> for logical and physical sizes. These fields are wrongfully assigned
> to uint16_t in BlockConf, which results, among other errors,
> in assigning 0 instead of 65536 (which will be the case in at least
> future LizardFS block device driver among other things).
> > This commit makes BlockConf's physical_block_size and logical_block_size > 
> > fields uint32_t to avoid inconsistencies.
> 
> Signed-off-by: Piotr Sarna 
> ---
>  include/hw/block/block.h | 4 ++--
>  include/hw/qdev-properties.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/hw/block/block.h b/include/hw/block/block.h
> index 64b9298..c9e6e27 100644
> --- a/include/hw/block/block.h
> +++ b/include/hw/block/block.h
> @@ -17,8 +17,8 @@
>  
>  typedef struct BlockConf {
>  BlockBackend *blk;
> -uint16_t physical_block_size;
> -uint16_t logical_block_size;
> +uint32_t physical_block_size;
> +uint32_t logical_block_size;
>  uint16_t min_io_size;
>  uint32_t opt_io_size;
>  int32_t bootindex;
> diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
> index 1d61a35..c68d7bf 100644
> --- a/include/hw/qdev-properties.h
> +++ b/include/hw/qdev-properties.h
> @@ -210,7 +210,7 @@ extern const PropertyInfo qdev_prop_off_auto_pcibar;
>  #define DEFINE_PROP_BIOS_CHS_TRANS(_n, _s, _f, _d) \
>  DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_bios_chs_trans, int)
>  #define DEFINE_PROP_BLOCKSIZE(_n, _s, _f) \
> -DEFINE_PROP_UNSIGNED(_n, _s, _f, 0, qdev_prop_blocksize, uint16_t)
> +DEFINE_PROP_UNSIGNED(_n, _s, _f, 0, qdev_prop_blocksize, uint32_t)
>  #define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
>  DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, PCIHostDeviceAddress)
>  #define DEFINE_PROP_MEMORY_REGION(_n, _s, _f) \

Do you need to update qdev_prop_blocksize and set_blocksize as well?

const PropertyInfo qdev_prop_blocksize = {
.name  = "uint16",
.description = "A power of two between 512 and 32768",
.get   = get_uint16,
.set   = set_blocksize,
.set_default_value = set_default_value_uint,
};

Fam

[Qemu-devel] [Resend][PATCH] qga: unset frozen state if no mount points are frozen

[Chen Hanxiao]

From: Chen Hanxiao 

If we set mountpoints to qmp_guest_fsfreeze_freeze_list,
we may got nothing to freeze as all mountpoints are
not valid.
Call ga_unset_frozen in this senario.

Cc: Michael Roth 
Signed-off-by: Chen Hanxiao 
---
Rebase on master

 qga/commands-posix.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index e809e382eb..9fd51f1d7a 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -1273,6 +1273,12 @@ int64_t qmp_guest_fsfreeze_freeze_list(bool 
has_mountpoints,
 }
 
 free_fs_mount_list();
+/* We may not issue any FIFREEZE here when had mountpoints.
+ * Just unset ga_state here and ready for the next call.
+ */
+if (has_mountpoints && i == 0) {
+ga_unset_frozen(ga_state);
+}
 return i;
 
 error:
-- 
2.14.3

[Qemu-devel] [PATCH 10/54] vfio: Fix vfio-kvm group registration

[Michael Roth]

From: Alex Williamson 

Commit 8c37faa475f3 ("vfio-pci, ppc64/spapr: Reorder group-to-container
attaching") moved registration of groups with the vfio-kvm device from
vfio_get_group() to vfio_connect_container(), but it missed the case
where a group is attached to an existing container and takes an early
exit.  Perhaps this is a less common case on ppc64/spapr, but on x86
(without viommu) all groups are connected to the same container and
thus only the first group gets registered with the vfio-kvm device.
This becomes a problem if we then hot-unplug the devices associated
with that first group and we end up with KVM being misinformed about
any vfio connections that might remain.  Fix by including the call to
vfio_kvm_device_add_group() in this early exit path.

Fixes: 8c37faa475f3 ("vfio-pci, ppc64/spapr: Reorder group-to-container 
attaching")
Cc: qemu-sta...@nongnu.org # qemu-2.10+
Reviewed-by: Alexey Kardashevskiy 
Reviewed-by: Peter Xu 
Tested-by: Peter Xu 
Reviewed-by: Eric Auger 
Tested-by: Eric Auger 
Signed-off-by: Alex Williamson 
(cherry picked from commit 2016986aedb6ea2839662eb5f60630f3e231bd1a)
Signed-off-by: Michael Roth 
---
 hw/vfio/common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 7b2924c0ef..7007878e34 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -968,6 +968,7 @@ static int vfio_connect_container(VFIOGroup *group, 
AddressSpace *as,
 if (!ioctl(group->fd, VFIO_GROUP_SET_CONTAINER, >fd)) {
 group->container = container;
 QLIST_INSERT_HEAD(>group_list, group, container_next);
+vfio_kvm_device_add_group(group);
 return 0;
 }
 }
-- 
2.11.0

Re: [Qemu-devel] [PATCH 1/2] hw/arm/aspeed: directly map the serial device to the system address space

[Andrew Jeffery]

On Thu, 2018-02-08 at 14:40 -0300, Philippe Mathieu-Daudé wrote:
> On 02/08/2018 02:30 PM, Peter Maydell wrote:
> > On 8 February 2018 at 17:22, Philippe Mathieu-Daudé  wrote:
> > > Signed-off-by: Philippe Mathieu-Daudé 
> > > ---
> > >  hw/arm/aspeed_soc.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> > > index c83b7e207b..a786750e14 100644
> > > --- a/hw/arm/aspeed_soc.c
> > > +++ b/hw/arm/aspeed_soc.c
> > > @@ -257,7 +257,7 @@ static void aspeed_soc_realize(DeviceState *dev, 
> > > Error **errp)
> > >  /* UART - attach an 8250 to the IO space as our UART5 */
> > >  if (serial_hds[0]) {
> > >  qemu_irq uart5 = qdev_get_gpio_in(DEVICE(>vic), uart_irqs[4]);
> > > -serial_mm_init(>iomem, ASPEED_SOC_UART_5_BASE, 2,
> > > +serial_mm_init(get_system_memory(), ASPEED_SOC_UART_5_BASE, 2,
> > > uart5, 38400, serial_hds[0], 
> > > DEVICE_LITTLE_ENDIAN);
> > >  }
> > 
> > Is this a bug fix? It certainly changes behaviour, which
> > suggests that a fuller commit message would be useful.
> 
> This patch is buggy indeed, using system_memory the serial address
> should be ASPEED_SOC_IOMEM_BASE + ASPEED_SOC_UART_5_BASE.
> 

If you'd like to test, you can grab images from here:

https://openpower.xyz/job/openbmc-build/distro=ubuntu,target=romulus/

For example (without the patch):

$ wget 
https://openpower.xyz/job/openbmc-build/1240/distro=ubuntu,target=romulus/artifact/deploy/images/romulus/image-bmc
...
$ qemu-system-arm -M romulus-bmc -m 512 -drive file=image-bmc,if=mtd,format=raw 
-nographic


U-Boot 2016.07 (Jan 25 2018 - 16:31:27 +)   

   Watchdog enabled 
DRAM:  496 MiB  
Flash: 32 MiB   
*** Warning - bad CRC, using default environment

In:serial   
Out:   serial   
Err:   serial   
Net:   aspeednic#0  
Error: aspeednic#0 address not set. 

Hit any key to stop autoboot:  0
## Loading kernel from FIT Image at 2008 ...
...

And yeah, this patch breaks output.

Thanks for the cleanup though.

Andrew

signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] [PATCH v5 10/14] pci: Add support for Designware IP block

[Michael S. Tsirkin]

On Thu, Feb 08, 2018 at 12:43:03PM -0800, Andrey Smirnov wrote:
> On Thu, Feb 8, 2018 at 12:33 PM, Michael S. Tsirkin  wrote:
> > On Thu, Feb 08, 2018 at 12:22:53PM -0800, Andrey Smirnov wrote:
> >> On Thu, Feb 8, 2018 at 12:11 PM, Michael S. Tsirkin  
> >> wrote:
> >> > On Thu, Feb 08, 2018 at 12:03:04PM -0800, Andrey Smirnov wrote:
> >> >> >> +#define PCIE_PORT_LINK_CONTROL  0x710
> >> >> >> +
> >> >> >> +#define PCIE_PHY_DEBUG_R1   0x72C
> >> >> >> +#define PCIE_PHY_DEBUG_R1_XMLH_LINK_UP  BIT(4)
> >> >> >> +
> >> >> >> +#define PCIE_LINK_WIDTH_SPEED_CONTROL   0x80C
> >> >> >> +#define PORT_LOGIC_SPEED_CHANGE (0x1 << 17)
> >> >> >> +
> >> >> >> +#define PCIE_MSI_ADDR_LO0x820
> >> >> >> +#define PCIE_MSI_ADDR_HI0x824
> >> >> >> +#define PCIE_MSI_INTR0_ENABLE   0x828
> >> >> >> +#define PCIE_MSI_INTR0_MASK 0x82C
> >> >> >> +#define PCIE_MSI_INTR0_STATUS   0x830
> >> >> >> +
> >> >> >> +#define PCIE_ATU_VIEWPORT   0x900
> >> >> >> +#define PCIE_ATU_REGION_INBOUND (0x1 << 31)
> >> >> >> +#define PCIE_ATU_REGION_OUTBOUND(0x0 << 31)
> >> >> >> +#define PCIE_ATU_REGION_INDEX2  (0x2 << 0)
> >> >> >> +#define PCIE_ATU_REGION_INDEX1  (0x1 << 0)
> >> >> >> +#define PCIE_ATU_REGION_INDEX0  (0x0 << 0)
> >> >> >> +#define PCIE_ATU_CR10x904
> >> >> >> +#define PCIE_ATU_TYPE_MEM   (0x0 << 0)
> >> >> >> +#define PCIE_ATU_TYPE_IO(0x2 << 0)
> >> >> >> +#define PCIE_ATU_TYPE_CFG0  (0x4 << 0)
> >> >> >> +#define PCIE_ATU_TYPE_CFG1  (0x5 << 0)
> >> >> >> +#define PCIE_ATU_CR20x908
> >> >> >> +#define PCIE_ATU_ENABLE (0x1 << 31)
> >> >> >> +#define PCIE_ATU_BAR_MODE_ENABLE(0x1 << 30)
> >> >> >> +#define PCIE_ATU_LOWER_BASE 0x90C
> >> >> >> +#define PCIE_ATU_UPPER_BASE 0x910
> >> >> >> +#define PCIE_ATU_LIMIT  0x914
> >> >> >> +#define PCIE_ATU_LOWER_TARGET   0x918
> >> >> >> +#define PCIE_ATU_BUS(x) (((x) >> 24) & 0xff)
> >> >> >> +#define PCIE_ATU_DEVFN(x)   (((x) >> 16) & 0xff)
> >> >> >> +#define PCIE_ATU_UPPER_TARGET   0x91C
> >> >
> >> > Can you avoid a PCIE prefix for this btw?
> >> >
> >>
> >> That's how those constants were named in Linux kernel, but yeah, I'll
> >> add a prefix to them.
> >>
> >> Thanks,
> >> Andrey Smirnov
> >
> > In that case you should not copy it into your file.
> > Stuff from linux kernel should be imported into standard-headers.
> >
> 
> Just to be sure we are on the same page, this is the file I am talking about:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/dwc/pcie-designware.h?h=v4.15
> 
> you want me to put it in standard-headers/linux and get those
> constants from there?
> 
> Thanks,
> Andrey Smirnov

Oh it's from a source file. I see. standard-headers/linux is for
files exported from include/uapi.

I take it back then but pls rename appropriately - and I guess
you should only copy what you actually use.

-- 
MST

Re: [Qemu-devel] [PATCH v3 06/18] sdcard: simplify using the ldst API

[Alistair Francis]

On Mon, Jan 22, 2018 at 7:30 PM, Philippe Mathieu-Daudé  wrote:
> the code is easier to review/refactor.
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/sd/sd.c | 38 +-
>  1 file changed, 9 insertions(+), 29 deletions(-)
>
> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> index 3c66521862..23f5d47782 100644
> --- a/hw/sd/sd.c
> +++ b/hw/sd/sd.c
> @@ -435,57 +435,39 @@ static int sd_req_crc_validate(SDRequest *req)
>  {
>  uint8_t buffer[5];
>  buffer[0] = 0x40 | req->cmd;
> -buffer[1] = (req->arg >> 24) & 0xff;
> -buffer[2] = (req->arg >> 16) & 0xff;
> -buffer[3] = (req->arg >> 8) & 0xff;
> -buffer[4] = (req->arg >> 0) & 0xff;
> +stl_be_p([1], req->arg);
>  return 0;
>  return sd_crc7(buffer, 5) != req->crc; /* TODO */
>  }
>
>  static void sd_response_r1_make(SDState *sd, uint8_t *response)
>  {
> -uint32_t status = sd->card_status;
> +stl_be_p(response, sd->card_status);
> +
>  /* Clear the "clear on read" status bits */
>  sd->card_status &= ~CARD_STATUS_C;
> -
> -response[0] = (status >> 24) & 0xff;
> -response[1] = (status >> 16) & 0xff;
> -response[2] = (status >> 8) & 0xff;
> -response[3] = (status >> 0) & 0xff;
>  }
>
>  static void sd_response_r3_make(SDState *sd, uint8_t *response)
>  {
> -response[0] = (sd->ocr >> 24) & 0xff;
> -response[1] = (sd->ocr >> 16) & 0xff;
> -response[2] = (sd->ocr >> 8) & 0xff;
> -response[3] = (sd->ocr >> 0) & 0xff;
> +stl_be_p(response, sd->ocr);
>  }
>
>  static void sd_response_r6_make(SDState *sd, uint8_t *response)
>  {
> -uint16_t arg;
>  uint16_t status;
>
> -arg = sd->rca;
>  status = ((sd->card_status >> 8) & 0xc000) |
>   ((sd->card_status >> 6) & 0x2000) |
>(sd->card_status & 0x1fff);
>  sd->card_status &= ~(CARD_STATUS_C & 0xc81fff);
> -
> -response[0] = (arg >> 8) & 0xff;
> -response[1] = arg & 0xff;
> -response[2] = (status >> 8) & 0xff;
> -response[3] = status & 0xff;
> +stw_be_p(response + 0, sd->rca);
> +stw_be_p(response + 2, status);
>  }
>
>  static void sd_response_r7_make(SDState *sd, uint8_t *response)
>  {
> -response[0] = (sd->vhs >> 24) & 0xff;
> -response[1] = (sd->vhs >> 16) & 0xff;
> -response[2] = (sd->vhs >>  8) & 0xff;
> -response[3] = (sd->vhs >>  0) & 0xff;
> +stl_be_p(response, sd->vhs);
>  }
>
>  static inline uint64_t sd_addr_to_wpnum(uint64_t addr)
> @@ -731,7 +713,7 @@ static uint32_t sd_wpbits(SDState *sd, uint64_t addr)
>
>  static void sd_function_switch(SDState *sd, uint32_t arg)
>  {
> -int i, mode, new_func, crc;
> +int i, mode, new_func;
>  mode = !!(arg & 0x8000);
>
>  sd->data[0] = 0x00;/* Maximum current consumption */
> @@ -755,9 +737,7 @@ static void sd_function_switch(SDState *sd, uint32_t arg)
>  sd->data[14 + (i >> 1)] = new_func << ((i * 4) & 4);
>  }
>  memset(>data[17], 0, 47);
> -crc = sd_crc16(sd->data, 64);
> -sd->data[65] = crc >> 8;
> -sd->data[66] = crc & 0xff;
> +stw_be_p(sd->data + 65, sd_crc16(sd->data, 64));
>  }
>
>  static inline bool sd_wp_addr(SDState *sd, uint64_t addr)
> --
> 2.15.1
>
>

Re: [Qemu-devel] Functional tests (AKA Avocado-based tests)

[Alistair Francis]

On Thu, Feb 8, 2018 at 3:38 PM, Alistair Francis  wrote:
> On Mon, Feb 5, 2018 at 8:34 AM, Cleber Rosa  wrote:
>>
>>
>> On 02/01/2018 07:10 PM, Alistair Francis wrote:
>>> On Wed, Jan 17, 2018 at 4:47 PM, Cleber Rosa  wrote:


 On 01/17/2018 06:41 PM, Alistair Francis wrote:
> On Wed, Jan 17, 2018 at 12:05 AM, Cleber Rosa  wrote:
>> TL;DR
>> =
>>
>> This is about how QEMU developers can get started with functional
>> tests that are built on top of the Avocado libraries (and meant to be
>> run with the Avocado test runner).
>>
>> The past
>> 
>>
>> The Avocado project[1] has been working, for quite some time now, on a
>> "set of tools and libraries" with the goal of making writing tests
>> easier.  It is supposed to be a framework agnostic to the exact
>> software that will be under test.
>>
>> But, at the same time, the Avocado project cannot deny its inheritance
>> and influences.  Those come from Autotest[2], which had "KVM Autotest"
>> as its largest and most developed "test".  This large Autotest test
>> (KVM Autotest) became virt-test[3] and later got integrated into
>> Avocado and became Avocado-VT[4] which is quite relevant here,
>> together with its QEMU test provider[5].
>>
>> Avocado-VT and the QEMU test provider attempt to provide coverage
>> across platform and QEMU versions, which increases its complexity.
>> Also, it's built on a legacy set of principles and tools that makes
>> some developers stir away from it.
>>
>> What's new?
>> ===
>>
>> A few months ago, the Avocado developers returned to its
>> "virtualization origins", in an attempt to learn from the QEMU
>> project, and try to help with a way to have more functional tests in
>> the upstream QEMU repo.
>>
>> We believe it's possible to expand the test coverage for QEMU by
>> facilitating
>> the creation of more functional tests QEMU.  This is no different than 
>> how
>> other types of tests are already included in the tree itself.
>>
>> How
>> ===
>>
>> How we did it (so far)
>> --
>>
>> We're aware that there's a dilemma here: to be able to easily write
>> more powerful tests, a lot of the complexity has to be moved
>> elsewhere.  Here, it means moving complexity from the test itself to a
>> framework.  The QEMU source tree itself has proofs of this approach,
>> being the "scripts" and "tests/qemu-iotests" some of the examples.
>>
>> Avocado itself[1] provides a lot of the code that should help to
>> absorb some of the complexities in writing tests, but not exactly
>> everything that is needed for QEMU.  The approach we believe will have
>> the best balance is to reuse upstream Avocado libraries whenever they
>> are useful and generic enough, and on top of that, libraries that are
>> part of QEMU itself.
>>
>> How can you get started with it
>> ---
>>
>> First of all, get Avocado installed.  Besides the Avocado test runner
>> itself, this will give you the basic libraries on which the other part
>> of this work was built on.  We want that to be simple and painless, so
>> here's our best bet for a one-liner installation:
>>
>>   pip install --user avocado-framework
>> avocado-framework-plugin-varianter-yaml-to-mux aexpect
>>
>> That will install Avocado within the user's home directory.  If you
>> give up on it, it can be uninstalled with another simple one-liner:
>>
>>   pip uninstall -y avocado-framework
>> avocado-framework-plugin-varianter-yaml-to-mux aexpect
>>
>> Now, suppose you're working on a given feature, and want to try your
>> luck writing a test using this work.  To avoid having you fetching and
>> rebasing from our currently in development fork[6] and branch[7], you
>> can just
>> add one commit to your tree with:
>>
>>   curl
>> https://patch-diff.githubusercontent.com/raw/apahim/qemu/pull/17.patch |
>> git am -
>>
>> This will get a simple patch from a snapshot branch[8].  You can, of 
>> course,
>> do it "the git way", fetching from that repo[6] and using the
>> non-snapshotted branch.
>>
>> After that, we'd love for you to take a look at some of the existing
>> tests[9][10] and then attempt to create test for your own use case.
>> The basic README[11] file, and the Avocado documentation[12] are also
>> important resources not to be missed.
>>
>> What's next?
>> 
>>
>> Initially, feedback is what we're looking for.  It would be greatly
>> appreciated to understand if/how this suits (or not) use cases out
>> there.
>>
>> After 

Re: [Qemu-devel] Functional tests (AKA Avocado-based tests)

[Alistair Francis]

On Mon, Feb 5, 2018 at 8:34 AM, Cleber Rosa  wrote:
>
>
> On 02/01/2018 07:10 PM, Alistair Francis wrote:
>> On Wed, Jan 17, 2018 at 4:47 PM, Cleber Rosa  wrote:
>>>
>>>
>>> On 01/17/2018 06:41 PM, Alistair Francis wrote:
 On Wed, Jan 17, 2018 at 12:05 AM, Cleber Rosa  wrote:
> TL;DR
> =
>
> This is about how QEMU developers can get started with functional
> tests that are built on top of the Avocado libraries (and meant to be
> run with the Avocado test runner).
>
> The past
> 
>
> The Avocado project[1] has been working, for quite some time now, on a
> "set of tools and libraries" with the goal of making writing tests
> easier.  It is supposed to be a framework agnostic to the exact
> software that will be under test.
>
> But, at the same time, the Avocado project cannot deny its inheritance
> and influences.  Those come from Autotest[2], which had "KVM Autotest"
> as its largest and most developed "test".  This large Autotest test
> (KVM Autotest) became virt-test[3] and later got integrated into
> Avocado and became Avocado-VT[4] which is quite relevant here,
> together with its QEMU test provider[5].
>
> Avocado-VT and the QEMU test provider attempt to provide coverage
> across platform and QEMU versions, which increases its complexity.
> Also, it's built on a legacy set of principles and tools that makes
> some developers stir away from it.
>
> What's new?
> ===
>
> A few months ago, the Avocado developers returned to its
> "virtualization origins", in an attempt to learn from the QEMU
> project, and try to help with a way to have more functional tests in
> the upstream QEMU repo.
>
> We believe it's possible to expand the test coverage for QEMU by
> facilitating
> the creation of more functional tests QEMU.  This is no different than how
> other types of tests are already included in the tree itself.
>
> How
> ===
>
> How we did it (so far)
> --
>
> We're aware that there's a dilemma here: to be able to easily write
> more powerful tests, a lot of the complexity has to be moved
> elsewhere.  Here, it means moving complexity from the test itself to a
> framework.  The QEMU source tree itself has proofs of this approach,
> being the "scripts" and "tests/qemu-iotests" some of the examples.
>
> Avocado itself[1] provides a lot of the code that should help to
> absorb some of the complexities in writing tests, but not exactly
> everything that is needed for QEMU.  The approach we believe will have
> the best balance is to reuse upstream Avocado libraries whenever they
> are useful and generic enough, and on top of that, libraries that are
> part of QEMU itself.
>
> How can you get started with it
> ---
>
> First of all, get Avocado installed.  Besides the Avocado test runner
> itself, this will give you the basic libraries on which the other part
> of this work was built on.  We want that to be simple and painless, so
> here's our best bet for a one-liner installation:
>
>   pip install --user avocado-framework
> avocado-framework-plugin-varianter-yaml-to-mux aexpect
>
> That will install Avocado within the user's home directory.  If you
> give up on it, it can be uninstalled with another simple one-liner:
>
>   pip uninstall -y avocado-framework
> avocado-framework-plugin-varianter-yaml-to-mux aexpect
>
> Now, suppose you're working on a given feature, and want to try your
> luck writing a test using this work.  To avoid having you fetching and
> rebasing from our currently in development fork[6] and branch[7], you
> can just
> add one commit to your tree with:
>
>   curl
> https://patch-diff.githubusercontent.com/raw/apahim/qemu/pull/17.patch |
> git am -
>
> This will get a simple patch from a snapshot branch[8].  You can, of 
> course,
> do it "the git way", fetching from that repo[6] and using the
> non-snapshotted branch.
>
> After that, we'd love for you to take a look at some of the existing
> tests[9][10] and then attempt to create test for your own use case.
> The basic README[11] file, and the Avocado documentation[12] are also
> important resources not to be missed.
>
> What's next?
> 
>
> Initially, feedback is what we're looking for.  It would be greatly
> appreciated to understand if/how this suits (or not) use cases out
> there.
>
> After feedback, further refinements, and more tests are written, the
> Avocado developers will follow up with an initial patch series for
> upstream QEMU.  In such a proposal, we intend to have further
> 

Re: [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling

[Alistair Francis]

On Thu, Feb 8, 2018 at 6:58 AM, Peter Maydell  wrote:
> On 4 February 2018 at 20:41, Richard Braun  wrote:
>> Consider that data is always immediately sent. As a result, keep
>> the SR_TXE and SR_TC bits always set. In addition, fix the reset value
>> of the USART status register.
>
> Do you know what the data sheet means when it says that TC
> can be cleared by "a read from the USART_SR register followed
> by a write to the USART_DR register" ?

I'm not sure if they have to be consecutive or as long as they
eventually happen it's fine.

I no longer have HW to test on so it's hard to say.

>
> If we supported interrupts properly (which we don't seem to)
> I suspect we'd need something more than "TXE and TC are always set",
> or the guest would probably never clear the TXE and TC interrupts.
>
> cc'ing Alistair, who wrote the stm32 USART code.
>
>> Signed-off-by: Richard Braun 
>> ---
>>  hw/char/stm32f2xx_usart.c | 4 
>>  include/hw/char/stm32f2xx_usart.h | 7 ++-
>>  2 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
>> index 07b462d4b6..a914f98a2a 100644
>> --- a/hw/char/stm32f2xx_usart.c
>> +++ b/hw/char/stm32f2xx_usart.c
>> @@ -96,12 +96,10 @@ static uint64_t stm32f2xx_usart_read(void *opaque, 
>> hwaddr addr,
>>  switch (addr) {
>>  case USART_SR:
>>  retvalue = s->usart_sr;
>> -s->usart_sr &= ~USART_SR_TC;

This does seem to be the wrong behavior. It should be cleared after
writing to the USART_DR register (and after this read).

>>  qemu_chr_fe_accept_input(>chr);
>>  return retvalue;
>>  case USART_DR:
>>  DB_PRINT("Value: 0x%" PRIx32 ", %c\n", s->usart_dr, (char) 
>> s->usart_dr);
>> -s->usart_sr |= USART_SR_TXE;

Doesn't software expect this to be set? Maybe this was just a nasty
workaround to ensure it was set at some point.

>>  s->usart_sr &= ~USART_SR_RXNE;
>>  qemu_chr_fe_accept_input(>chr);
>>  qemu_set_irq(s->irq, 0);
>> @@ -151,8 +149,6 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr 
>> addr,
>>  /* XXX this blocks entire thread. Rewrite to use
>>   * qemu_chr_fe_write and background I/O callbacks */
>>  qemu_chr_fe_write_all(>chr, , 1);
>> -s->usart_sr |= USART_SR_TC;
>> -s->usart_sr &= ~USART_SR_TXE;
>
> The guest can clear the TC and TXE bits by writing to the USART_SR
> directly, so this code should set both of them, I think ?

Shouldn't this clear both?

TXE: "It is cleared by a write to the USART_DR register."
TC: "a read from the USART_SR register followed by a write to the
USART_DR register"

I guess the TC should only clear after a read though.

>
>>  }
>>  return;
>>  case USART_BRR:
>> diff --git a/include/hw/char/stm32f2xx_usart.h 
>> b/include/hw/char/stm32f2xx_usart.h
>> index 9d03a7527c..bbba3965a1 100644
>> --- a/include/hw/char/stm32f2xx_usart.h
>> +++ b/include/hw/char/stm32f2xx_usart.h
>> @@ -37,7 +37,12 @@
>>  #define USART_CR3  0x14
>>  #define USART_GTPR 0x18
>>
>> -#define USART_SR_RESET 0x00C0
>> +/*
>> + * XXX The reset value mentioned in 24.6.1 Status register seems bogus.
>> + * Looking at Table 98 USART register map and reset values, it seems it
>> + * should be 0xc0, and that's how real hardware behaves.
>> + */
>> +#define USART_SR_RESET (USART_SR_TXE | USART_SR_TC)
>>
>>  #define USART_SR_TXE  (1 << 7)
>>  #define USART_SR_TC   (1 << 6)
>
> Yep, I agree that the previous reset value was wrong.

Ah, that is confusing that it's different in different places. The new
one looks fine though.

Alistair

>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH] sii3112: Change angle brackets to quotes in #include lines

[David Gibson]

On Thu, Feb 01, 2018 at 12:51:04PM +0100, BALATON Zoltan wrote:
> On Wed, 31 Jan 2018, David Gibson wrote:
> > On Tue, Jan 30, 2018 at 02:10:10PM +0100, BALATON Zoltan wrote:
> > > This matches what other files do for qemu includes
> > > 
> > > Signed-off-by: BALATON Zoltan 
> > 
> > Applied, thanks.
> 
> Thanks but Markus instead included this in his cleanup patches here:
> http://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg00075.html
> so you can drop this from your tree now.

Ok, done.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 04/27] qcow2: Pass BlockdevCreateOptions to qcow2_create2()

[Eric Blake]

On 02/08/2018 01:23 PM, Kevin Wolf wrote:

All of the simple options are now passed to qcow2_create2() in a
BlockdevCreateOptions object. Still missing: node-name and the
encryption options.

Signed-off-by: Kevin Wolf 
---
  block/qcow2.c | 190 ++
  1 file changed, 152 insertions(+), 38 deletions(-)




-static size_t qcow2_opt_get_cluster_size_del(QemuOpts *opts, Error **errp)
+static bool validate_cluster_size(size_t cluster_size, Error **errp)
  {
-size_t cluster_size;
-int cluster_bits;
-
-cluster_size = qemu_opt_get_size_del(opts, BLOCK_OPT_CLUSTER_SIZE,
- DEFAULT_CLUSTER_SIZE);
-cluster_bits = ctz32(cluster_size);
+int cluster_bits = ctz32(cluster_size);
  if (cluster_bits < MIN_CLUSTER_BITS || cluster_bits > MAX_CLUSTER_BITS ||
  (1 << cluster_bits) != cluster_size)


Pre-existing, but why are we manually calling ctz32() instead of using 
is_power_of_2()?



@@ -2720,10 +2726,92 @@ static int qcow2_create2(BlockDriverState *bs, int64_t 
total_size,
   */
  BlockBackend *blk;
  QCowHeader *header;
+size_t cluster_size;
+int version;
+int refcount_order;
  uint64_t* refcount_table;
  Error *local_err = NULL;
  int ret;
  
+/* Validate options and set default values */

+assert(create_options->driver == BLOCKDEV_DRIVER_QCOW2);
+qcow2_opts = _options->u.qcow2;
+
+if (!QEMU_IS_ALIGNED(qcow2_opts->size, BDRV_SECTOR_SIZE)) {
+error_setg(errp, "Image size must be a multiple of 512 bytes");
+ret = -EINVAL;
+goto out;
+}


This check looks new.  Does it really belong in this patch?  And it does 
NOT match what qemu-img can currently do, nor the fact that qcow2 
supports byte-based addressing:


$ qemu-img create -f qcow2 tmp 12345
Formatting 'tmp', fmt=qcow2 size=12345 cluster_size=65536 
lazy_refcounts=off refcount_bits=16



+if (!qcow2_opts->has_lazy_refcounts) {
+qcow2_opts->lazy_refcounts = false;
+}
+if (version < 3 && qcow2_opts->lazy_refcounts) {
+error_setg(errp, "Lazy refcounts only supported with compatibility "
+   "level 1.1 and above (use compat=1.1 or greater)");


Do we want to reword this error message at all, now that QMP spells it 
'v3'?  Should qemu-img be taught to accept 'compat=v3' as a synonym to 
'compat=1.1'?



+return -EINVAL;
+}
+
+if (!qcow2_opts->has_refcount_bits) {
+qcow2_opts->refcount_bits = 16;
+}
+if (qcow2_opts->refcount_bits > 64 ||
+!is_power_of_2(qcow2_opts->refcount_bits))
+{
+error_setg(errp, "Refcount width must be a power of two and may not "
+   "exceed 64 bits");
+return -EINVAL;
+}
+if (version < 3 && qcow2_opts->refcount_bits != 16) {
+error_setg(errp, "Different refcount widths than 16 bits require "
+   "compatibility level 1.1 or above (use compat=1.1 or "
+   "greater)");


and again


@@ -2978,9 +3068,33 @@ static int qcow2_create(const char *filename, QemuOpts 
*opts, Error **errp)
  }
  
  /* Create the qcow2 image (format layer) */

-ret = qcow2_create2(bs, size, backing_file, backing_fmt, flags,
-cluster_size, prealloc, opts, version, refcount_order,
-encryptfmt, errp);
+create_options = (BlockdevCreateOptions) {
+.driver = BLOCKDEV_DRIVER_QCOW2,
+.u.qcow2= {
+.file   = &(BlockdevRef) {
+.type   = QTYPE_QSTRING,
+.u.reference= bs->node_name,
+},
+.size   = size,
+.has_version= true,
+.version= version == 2
+  ? BLOCKDEV_QCOW2_VERSION_V2
+  : BLOCKDEV_QCOW2_VERSION_V3,
+.has_backing_file   = (backing_file != NULL),
+.backing_file   = backing_file,
+.has_backing_fmt= (backing_fmt != NULL),


I might have spelled it '= !!backing_fmt', but your way is fine too.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH] spapr: add missing break in h_get_cpu_characteristics()

[David Gibson]

On Thu, Feb 01, 2018 at 08:47:41PM +0100, Greg Kurz wrote:
> Detected by Coverity (CID 1385702). This fixes the recently added hypercall
> to let guests properly apply Spectre and Meltdown workarounds.
> 
> Fixes: c59704b25473 "target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS"
> Signed-off-by: Greg Kurz 

Applied to ppc-for-2.12, thanks.

> ---
>  hw/ppc/spapr_hcall.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 4d0e6eb0cf1d..596f58378a40 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1697,6 +1697,7 @@ static target_ulong 
> h_get_cpu_characteristics(PowerPCCPU *cpu,
>  switch (safe_indirect_branch) {
>  case SPAPR_CAP_FIXED:
>  characteristics |= H_CPU_CHAR_BCCTRL_SERIALISED;
> +break;
>  default: /* broken */
>  assert(safe_indirect_branch == SPAPR_CAP_BROKEN);
>  break;
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v2] spapr: check smp_threads <= vsmt

[David Gibson]

On Thu, Feb 08, 2018 at 10:42:41AM +0100, Laurent Vivier wrote:
> We ignore silently the value of smp_threads when we set
> the default VSMT value, and if smp_threads is greater than VSMT
> kernel is going into trouble later.
> 
> Fixes: 8904e5a750
> ("spapr: Adjust default VSMT value for better migration compatibility")
> 
> Signed-off-by: Laurent Vivier 

I don't think this is quite the rigth appoach.  Instead, I think we
want:

spapr->vsmt = MAX(8, smp_threads);

The real point of 8904e5a750 was to replace the host-derived kvm_smt
with a fixed value (8).  I only removed the MAX, because I mistakenly
thought that checks elsewhere would prevent smp_threads > 8.

> ---
> 
> Notes:
> v2: display a specific error message when the default VSMT is used
> fix subject
> 
>  hw/ppc/spapr.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 32a876be56..11de276cd5 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2311,6 +2311,12 @@ static void spapr_set_vsmt_mode(sPAPRMachineState 
> *spapr, Error **errp)
>   * overwhelmingly common case in production systems.
>   */
>  spapr->vsmt = 8;
> +if (spapr->vsmt < smp_threads) {
> +error_setg(_err, "Cannot support %d threads/core"
> + " because it must be <= to default VSMT mode (%d)",
> + smp_threads, spapr->vsmt);
> +goto out;
> +}
>  }
>  
>  /* KVM: If necessary, set the SMT mode: */

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 02/27] block/qapi: Add qcow2 create options to schema

[Eric Blake]

On 02/08/2018 01:23 PM, Kevin Wolf wrote:

Signed-off-by: Kevin Wolf 
---
  qapi/block-core.json | 45 -
  1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index b59b1430bb..aade602a04 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -3338,6 +3338,49 @@
  { 'command': 'blockdev-del', 'data': { 'node-name': 'str' } }
  
  ##

+# @BlockdevQcow2Version:
+#
+# @v2:  The original QCOW2 format as introduced in qemu 0.10 (version 2)
+# @v3:  The extended QCOW2 format as introduced in qemu 1.1 (version 3)
+#
+# Since: 2.12
+##
+{ 'enum': 'BlockdevQcow2Version',
+  'data': [ 'v2', 'v3' ] }


Yes, I think that turns out nicer.


+
+
+##
+# @BlockdevCreateOptionsQcow2:
+#
+# Driver specific image creation options for qcow2.
+#
+# @file Node to create the image format on
+# @size Size of the virtual disk in bytes
+# @version  Compatibility level (default: v3)
+# @backing-file File name of the backing file if a backing file
+#   should be used


Do we need an explicit comment that the QMP command does NOT open this 
file (so much as this being the string recorded in the metadata header), 
but that the caller is expected to later connect a node visiting the 
backing file to this node after the create has completed?  Or is that 
more for adding later in the QMP command that uses the overall union 
type (as the same rule will apply to multiple formats, not just qcow2 - 
the create operation is NOT creating the backing chain, but just 
formatting one element that will later be hooked into the chain).



+# @backing-fmt  Name of the block driver to use for the backing file
+# @encrypt  Encryption options if the image should be encrypted
+# @cluster-size qcow2 cluster size in bytes (default: 65536)
+# @preallocationPreallocation mode for the new image (default: off)
+# @lazy-refcounts   True if refcounts may be updated lazily (default: off)
+# @refcount-bitsWidth of reference counts in bits (default: 16)
+#
+# Since: 2.12
+##
+{ 'struct': 'BlockdevCreateOptionsQcow2',
+  'data': { 'file': 'BlockdevRef',
+'size': 'size',
+'*version': 'BlockdevQcow2Version',
+'*backing-file':'str',
+'*backing-fmt': 'BlockdevDriver',
+'*encrypt': 'QCryptoBlockCreateOptions',
+'*cluster-size':'size',
+'*preallocation':   'PreallocMode',
+'*lazy-refcounts':  'bool',
+'*refcount-bits':   'int' } }


Looks reasonable, and matches what qemu-img create -f qcow2 can do (the 
obvious differences of '-' in QMP instead of '_' in qemu-img -o spelling 
is fine).


Reviewed-by: Eric Blake 

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH 01/27] block/qapi: Introduce BlockdevCreateOptions

[Eric Blake]

On 02/08/2018 01:23 PM, Kevin Wolf wrote:

This creates a BlockdevCreateOptions union type that will contain all of
the options for image creation. We'll start out with an empty struct
type BlockdevCreateDummy for all drivers.


Name here...



Signed-off-by: Kevin Wolf 
---
  qapi/block-core.json | 61 
  1 file changed, 61 insertions(+)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 8225308904..b59b1430bb 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -3338,6 +3338,67 @@
  { 'command': 'blockdev-del', 'data': { 'node-name': 'str' } }
  
  ##

+# @BlockdevCreateNotSupported:


...should match what you use here.

With that obvious fix,
Reviewed-by: Eric Blake 

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH 14/14] tests/boot-serial-test: Add support for the aarch64 virt machine

[Eric Blake]

On 02/08/2018 02:09 PM, Thomas Huth wrote:

From: Wei Huang 

This patch adds a small binary kernel to test aarch64 virt machine's
UART.

Signed-off-by: Wei Huang 
[thuth: Fixed contextual conflict with the hppa patch]
Signed-off-by: Thomas Huth 
---
  tests/Makefile.include   | 1 +
  tests/boot-serial-test.c | 9 +
  2 files changed, 10 insertions(+)




+++ b/tests/boot-serial-test.c
@@ -55,6 +55,13 @@ static const uint8_t bios_raspi2[] = {
  0x00, 0x10, 0x20, 0x3f, /* 0x3f201000 = UART0 base addr */
  };
  
+static const uint8_t kernel_aarch64[] = {

+0x81, 0x0a, 0x80, 0x52, /* mov w1, #0x54 */
+0x02, 0x20, 0xa1, 0xd2, /* mov x2, #0x900 */
+0x41, 0x00, 0x00, 0x39, /* strbw1, [x2] */
+0xfd, 0xff, 0xff, 0x17, /* b   -12 (loop) */
+};


Code like this reminds me of the 1984 IOCCC winner 
(https://www.ioccc.org/1984/mullender/mullender.c) - there's just 
something strangely satisfying about an array of integers being compiled 
into executable code ;)


Reviewed-by: Eric Blake 

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH 00/14] qtest patches

[Eric Blake]

On 02/08/2018 02:09 PM, Thomas Huth wrote:

Here's a set of qtest patches that have been posted to the list before
and are IMHO ready for inclusion. I've included the patches from Eric's
"Preliminary libqtest cleanups" series that do not need major reworks
(the rest needs some more love later), and some additional entries for
the boot-serial tester. If there are no objections, I'll sent a PULL
request for these patches next week.


Thanks for reviving my patches (and now I have more incentive to give 
that "more love later" to the rest of my series).  I feel odd reviewing 
my work, but the edits you have made to resolve rebase conflicts look 
reasonable on the patches that bear my name.




Eric Blake (10):
   libqtest: Use qemu_strtoul()
   libqos: Track QTestState with QPCIBus
   libqos: Use explicit QTestState for fw_cfg operations
   libqos: Use explicit QTestState for rtas operations
   libqos: Use explicit QTestState for i2c operations
   libqos: Use explicit QTestState for ahci operations
   libqos: Use explicit QTestState for remaining libqos operations
   qmp-test: Drop dependence on global_qtest
   tests/boot-sector: Drop dependence on global_qtest
   wdt_ib700-test: Drop dependence on global_qtest

Markus Armbruster (1):
   tests: Clean up wait for event

Thomas Huth (2):
   tests/boot-serial: Enable the boot-serial test on SPARC machines, too
   tests/boot-serial: Add tests for PowerPC Mac machines

Wei Huang (1):
   tests/boot-serial-test: Add support for the aarch64 virt machine



--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH v2 22/32] arm/translate-a64: add FP16 FNEG/FABS to simd_two_reg_misc_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> +case 0x2f: /* FABS */
> +gen_helper_advsimd_absh(tcg_res, tcg_op);
> +break;
> +case 0x6f: /* FNEG */
> +tcg_gen_xori_i32(tcg_res, tcg_op, 0x8000);
> +break;

Why is ABS a function call while NEG a bit operation?


r~

Re: [Qemu-devel] [PATCH v2 21/32] arm/translate-a64: add FP16 SCVTF/UCVFT to simd_two_reg_misc_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> I've re-factored the handle_simd_intfp_conv helper to properly handle
> half-precision as well as call plain conversion helpers when we are
> not doing fixed point conversion.
> 
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/helper.c|   4 ++
>  target/arm/helper.h|  10 
>  target/arm/translate-a64.c | 121 
> +++--
>  3 files changed, 108 insertions(+), 27 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH 13/14] tests/boot-serial: Add tests for PowerPC Mac machines

[Eric Blake]

On 02/08/2018 02:09 PM, Thomas Huth wrote:

OpenBIOS prints out the CPU type on these machine types, so we can use
this string to test whether the CPU detection is working correctly.

Acked-by: Mark Cave-Ayland 
Signed-off-by: Thomas Huth 
---
  tests/boot-serial-test.c | 3 +++
  1 file changed, 3 insertions(+)


Reviewed-by: Eric Blake 



diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index 996d3d7..72873ee 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -69,8 +69,11 @@ static testdef_t tests[] = {
  { "alpha", "clipper", "", "PCI:" },
  { "ppc", "ppce500", "", "U-Boot" },
  { "ppc", "prep", "", "Open Hack'Ware BIOS" },
+{ "ppc", "g3beige", "", "PowerPC,750" },
+{ "ppc", "mac99", "", "PowerPC,G4" },
  { "ppc64", "ppce500", "", "U-Boot" },
  { "ppc64", "prep", "", "Open Hack'Ware BIOS" },
+{ "ppc64", "mac99", "", "PowerPC,970FX" },


[I wish thunderbird wouldn't corrupt whitespace when quoting patches - 
it seems to be a recent regression on something that used to work]


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH 12/14] tests/boot-serial: Enable the boot-serial test on SPARC machines, too

[Eric Blake]

On 02/08/2018 02:09 PM, Thomas Huth wrote:

OpenBIOS prints out the name of the detected CPU here, so looking for
this string is a nice test to verify that the CPU detection is still
working correctly.

Acked-by: Mark Cave-Ayland 
Signed-off-by: Thomas Huth 
---
  tests/Makefile.include   | 2 ++
  tests/boot-serial-test.c | 4 
  2 files changed, 6 insertions(+)



Reviewed-by: Eric Blake 

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH v2 20/32] arm/translate-a64: add FP16 FCMxx (zero) to simd_two_reg_misc_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> +maxpasses = hp ? (is_q ? 8 : 4) : (is_q ? 4 : 2);

  (8 << is_q) >> size

?


> +read_vec_element_i32(s, tcg_op, rn, pass, hp ? MO_16 : MO_32);

You already have size.

> +return;
> +break;

Unreachable break.


r~

Re: [Qemu-devel] [PATCH v2 19/32] arm/translate-a64: add FCVTxx to simd_two_reg_misc_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> This covers all the floating point convert operations.
> 
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/helper-a64.c| 32 +
>  target/arm/helper-a64.h|  2 ++
>  target/arm/translate-a64.c | 85 
> +-
>  3 files changed, 118 insertions(+), 1 deletion(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 18/32] arm/translate-a64: add FP16 FPRINTx to simd_two_reg_misc_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> @@ -10727,40 +10727,152 @@ static void disas_simd_two_reg_misc(DisasContext 
> *s, uint32_t insn)
>  /* AdvSIMD [scalar] two register miscellaneous (FP16)
>   *
>   *   31  30  29 28  27 24  23 22 21   17 1612 11 10 95 40
> - * +---+---+---+---++---+-++-+--+--+
> + * +---+---+---+---+-+---+-++-+--+--+
>   * | 0 | Q | U | S | 1 1 1 0 | a | 1 1 1 1 0 0 | opcode | 1 0 |  Rn  |  Rd  |
> - * +---+---+---+---++---+-++-+--+--+
> + * +---+---+---+---+-+---+-++-+--+--+
>   *   mask: 1000  0111 1110  1100   0x8f7e 0c00
>   *   val:   1110 0111 1000  1000   0x0e78 0800
>   *
> - * ???While the group is listed with bit 28 always set to 1 this is not
> - * always the case.
> - *
> - * This actually covers two groups,
> + * This actually covers two groups where scalar access is governed by
> + * bit 28. A bunch of the instructions (float to integral) only exist
> + * in the vector form and are un-allocated for the scalar decode. Also
> + * in the scalar decode Q is always 1.
>   */

Fold this hunk back into previous patch.

> 
> +
> +/* Check additional constraints for the scalar encoding */
> +if (is_scalar) {
> +if (!is_q) {
> +unallocated_encoding(s);
> +return;
> +}
> +/* FRINTxx is only in the vector form */
> +if (only_in_vector && is_scalar) {
> +unallocated_encoding(s);
> +return;
> +}
> +}

Testing is_scalar twice.
Otherwise it looks good.


r~

Re: [Qemu-devel] [PATCH v2 17/32] arm/translate-a64: initial decode for simd_two_reg_misc_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> @@ -11472,6 +11512,8 @@ static void disas_data_proc_simd(DisasContext *s, 
> uint32_t insn)
>  if (fn) {
>  fn(s, insn);
>  } else {
> +/* fprintf(stderr, "%s: failed to find %#4x @ %#" PRIx64 "\n", */
> +/* __func__, insn, s->pc); */
>  unallocated_encoding(s);

Prolly wanna drop this.  ;-)  Otherwise,

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 16/32] arm/translate-a64: add FP16 x2 ops for simd_indexed

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> A bunch of the vectorised bitwise operations just operate on larger
> chunks at a time. We can do the same for the new half-precision
> operations by introducing some TWOHALFOP helpers which work on each
> half of a pair of half-precision operations at once.
> 
> Hopefully all this hoop jumping will get simpler once we have
> generically vectorised helpers here.
> 
> Signed-off-by: Alex Bennée 
> 
> ---
> v2
>   - checkpatch fixes
> ---
>  target/arm/helper-a64.c| 46 
> +-
>  target/arm/helper-a64.h| 10 ++
>  target/arm/translate-a64.c | 36 +---
>  3 files changed, 84 insertions(+), 8 deletions(-)

Reviewed-by: Richard Henderson 


r~

[Qemu-devel] [Bug 1748296] Re: TCG throws Invalid Opcode when executing x86 BMI shlx instruction

[Doug Gale]

** Description changed:

  I am unable to use BMI in my project when running under TCG. I narrowed
  the problem down to incorrect instruction decoding for BMI instructions
  (which have a 2 byte VEX prefix). The gen_sse function in translate.c
  reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7,
  or 0x3f7, so the switch takes the default path and raises an invalid
  opcode exception.
  
  The code executes correctly and passes the test under KVM.
  
  I have created a complete repro here: https://github.com/doug65536/qemu-
  bmibug
  
  The makefile has the following utility targets:
  
  debug-kvm: Build and run the VM using KVM and wait for gdbstub attach
  
  run: Run the test case with TCG, make fails if the test fails. (It will
  fail)
  
  run-kvm: Run the test case with KVM, make fails if the test fails. (It
  will succeed)
  
  debug: Build and run the VM with TCG and wait for GDB attach
  
- attach-gdb: Run GDB and attach to KVM gdbstub
+ attach-gdb: Run GDB and attach to QEMU gdbstub
  
  The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM.
  
  You can quickly verify the issue by executing `make run-kvm` to confirm
  that KVM passes, then `make run` to confirm that TCG fails.
  
  I believe the bug affects other BMI, BMI2, and ABM instructions, but I
  have only completely verified incorrect execution of SHLX.

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

Title:
  TCG throws Invalid Opcode when executing x86 BMI shlx instruction

Status in QEMU:
  New

Bug description:
  I am unable to use BMI in my project when running under TCG. I
  narrowed the problem down to incorrect instruction decoding for BMI
  instructions (which have a 2 byte VEX prefix). The gen_sse function in
  translate.c reaches the goto label do_0f_38_fx, but b does not equal
  0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and
  raises an invalid opcode exception.

  The code executes correctly and passes the test under KVM.

  I have created a complete repro here: https://github.com/doug65536
  /qemu-bmibug

  The makefile has the following utility targets:

  debug-kvm: Build and run the VM using KVM and wait for gdbstub attach

  run: Run the test case with TCG, make fails if the test fails. (It
  will fail)

  run-kvm: Run the test case with KVM, make fails if the test fails. (It
  will succeed)

  debug: Build and run the VM with TCG and wait for GDB attach

  attach-gdb: Run GDB and attach to QEMU gdbstub

  The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and
  ABM.

  You can quickly verify the issue by executing `make run-kvm` to
  confirm that KVM passes, then `make run` to confirm that TCG fails.

  I believe the bug affects other BMI, BMI2, and ABM instructions, but I
  have only completely verified incorrect execution of SHLX.

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

Re: [Qemu-devel] "make check -j4" hangs (was: Re: chardev/char-socket: add POLLHUP handler)

[Alistair Francis]

On Thu, Feb 8, 2018 at 1:12 PM, Peter Maydell  wrote:
> On 8 February 2018 at 19:13, Thomas Huth  wrote:
>> I'm currently facing some issues with "make check -j4" (i.e. running the
>> tests in parallel). Git bisect blames this commit - though I'm not sure
>> whether this is really the right one ... Starting with this commit, I
>> saw hangs in test-filter-redirector, but git master rather seems to hang
>> with vhost-user-test instead.
>> Stefan also had issues with "make check -j4" today, so it's apparently
>> not only me ... can somebody else reproduce the problem with the git
>> master branch?
>
> Yeah, I was seeing odd make check hangs with parallelization enabled
> too, on vhost-user-test... (my builds for merge tests are almost
> all non-parallelized I think).

I don't only see hangs I also am seeing this:

qemu-system-i386: -chardev
socket,id=chr-test,path=/tmp/vhost-test-wxuOIX/test.sock: Failed to
connect socket /tmp/vhost-test-wxuOIX/test.sock: No such file or
directory
socket_accept failed: Resource temporarily unavailable
**
ERROR:tests/libqtest.c:218:qtest_init_without_qmp_handshake: assertion
failed: (s->fd >= 0 && s->qmp_fd >= 0)
GTester: last random seed: R02Sa67ba85090274c01deb9c2d15b044c10

It isn't 100% reproducible though.

Alistair

>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH 00/24] re-factor and add fp16 using glibc soft-fp

[no-reply]

Hi,

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

Type: series
Message-id: 20180204041136.17525-1-richard.hender...@linaro.org
Subject: [Qemu-devel] [PATCH 00/24] re-factor and add fp16 using glibc soft-fp

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

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

git config --local diff.renamelimit 0
git config --local diff.renames True

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
error: Could not fetch 3c8cf5a9c21ff8782164d1def7f44bd888713384
Traceback (most recent call last):
  File "/usr/bin/patchew", line 442, in test_one
git_clone_repo(clone, r["repo"], r["head"], logf)
  File "/usr/bin/patchew", line 48, in git_clone_repo
stdout=logf, stderr=logf)
  File "/usr/lib64/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['git', 'remote', 'add', '-f', 
'--mirror=fetch', '3c8cf5a9c21ff8782164d1def7f44bd888713384', 
'https://github.com/patchew-project/qemu']' returned non-zero exit status 1.



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

Re: [Qemu-devel] [PATCH v2 15/32] arm/translate-a64: add FP16 FMULX/MLS/FMLA to simd_indexed

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> The helpers use the new re-factored muladd support in SoftFloat for the 
> float16 work.
> 
> Signed-off-by: Alex Bennée  --- 
> target/arm/translate-a64.c | 69 
> -- 1 file changed, 54 
> insertions(+), 15 deletions(-)
> 
> diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c index 
> 3a2be1e016..83a1fa3116 100644 --- a/target/arm/translate-a64.c +++ 
> b/target/arm/translate-a64.c @@ -10804,7 +10804,7 @@ static void 
> disas_simd_indexed(DisasContext *s, uint32_t insn) } /* fall through */
> case 0x9: /* FMUL, FMULX */ -if (!extract32(size, 1, 1)) { +
> if (size == 1 || (size < 2 && !arm_dc_feature(s, ARM_FEATURE_V8_FP16))) { 
> unallocated_encoding(s); return; } @@ -10816,18 +10816,30 @@ static void 
> disas_simd_indexed(DisasContext *s, uint32_t insn) }
> 
> if (is_fp) { -/* low bit of size indicates single/double */ - size =
> extract32(size, 0, 1) ? 3 : 2; -if (size == 2) { +/* convert
> insn encoded size to TCGMemOp size */ +switch (size) { + case 0: /*
> half-precision */ +size = MO_16; +index = h << 2 | l
> << 1 | m; +break;

FWIW, the size check for the integer insns is done in this block (in the !is_fp
side of course).  I think it makes sense to do the size check for FP insns down
here too.  So, e.g.

if (is_fp) {
switch (size) {
case 2: /* single precision */
...
case 3: /* double precision */
...
case 0: /* half precision */
size = MO_16;
index = ...
is_fp16 = true;
if (arm_dc_feature(s, ARM_FEATURE_V8_FP16)) {
break;
}
/* fallthru */
default: /* unallocated */
unallocated_encoding(s);
return;
}
}

Just below, you have not updated the call to get_fpstatus_ptr.
For the record, for fcmla I needed to introduce an "is_fp16" bool here.
(Since of course a complex fp16 is 32-bits wide.)


r~

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

[Eduardo Habkost]

On Thu, Feb 08, 2018 at 02:59:17PM -0600, Eric Blake wrote:
> On 02/08/2018 01:59 PM, Eduardo Habkost wrote:
> > On Wed, Feb 07, 2018 at 12:50:13PM -0500, Luiz Capitulino wrote:
> > > The query-cpus command has an extremely serious side effect:
> > > it always interrupt all running vCPUs so that they can run
> > > ioctl calls. This can cause a huge performance degradation for
> > > some workloads. And most of the information retrieved by the
> > > ioctl calls are not even used by query-cpus.
> > > 
> > > This commit introduces a replacement for query-cpus called
> > > query-cpus-fast, which has the following features:
> > > 
> 
> > > +# Notes: @halted is a transient state that changes frequently.  By the 
> > > time the
> > > +#data is sent to the client, the guest may no longer be halted.
> > > +##
> > > +{ 'struct': 'CpuInfo2',
> > > +  'data': {'cpu-index': 'int', '*halted': 'bool', 'qom-path': 'str',
> > > +   'thread-id': 'int', '*props': 'CpuInstanceProperties' } }
> > 
> > This will require duplicating struct fields every time we add a
> > new field to query-cpus-fast (e.g. how would VIktor's
> > CpuInfoS390State patch[1] look like if rebased on top of yours?).
> > 
> > One way to avoid that is to use CpuInfo for both, and make all
> > "slow"  fields optional.  Another option is to use QAPI
> > inheritance, but it could be a little complicated if unions are
> > involved?
> 
> Inheritance is better than optional fields for the sake of introspection
> learning which fields to expect.
> 
> Put the common fields to both interfaces in the base class, then have the
> slower (older) CpuInfo class extend the base class to add the additional
> fields.
> 
> Unions should be able to inherit just fine from structs (after all, a flat
> union requires a struct base); but if we need two layers of unions, we'll
> need to enhance QAPI code generation first.

If we can't do union-union inheritance yet, maybe we can work around it this
way:

# fields that are always returned by both query-cpus and query-cpus-fast
{ 'struct': 'BothCpuInfoBase',
  'data': {'cpu': 'int', 'qom_path': 'str', 'thread_id': 'int',
   '*props': 'CpuInstanceProperties' } }

# fields that are always returned by query-cpus
{ 'struct': 'CpuInfoBase',
  'base': 'BothCpuInfoBase',
  'data': {'current': 'bool', 'halted': 'bool', 'arch': 'CpuInfoArch' } }

# query-cpus return value
{ 'union': 'CpuInfo',
  'base': 'CpuInfoBase',
  'discriminator': 'arch',
  'data': { 'x86': 'CpuInfoX86',
's390': 'CpuInfoS390',
'sparc': 'CpuInfoSPARC',
'ppc': 'CpuInfoPPC',
'mips': 'CpuInfoMIPS',
'tricore': 'CpuInfoTricore',
'other': 'CpuInfoOther' } }

# fields that are always returned by query-cpus-fast
{ 'struct': 'FastCpuInfoBase',
  'base': 'BothCpuInfoBase',
  'data': { 'arch': 'CpuInfoArch' } }

# return value of query-cpus-fast
{ 'union': 'FastCpuInfo',
  'base': 'FastCpuInfoBase',
  'discriminator': 'arch',
  'data': { 'x86': 'CpuInfoOther',
's390': 'FastCpuInfoS390',
'sparc': 'CpuInfoOther',
'ppc': 'CpuInfoOther',
'mips': 'CpuInfoOther',
'tricore': 'CpuInfoOther',
'other': 'CpuInfoOther' } }

# fields returned by both query-cpus and query-cpus-fast on s390
{ 'struct': 'FastCpuInfoS390',
  'data': { 'fast_field': 'int' } }

# fields returned by query-cpus on s390
{ 'struct': 'CpuInfoS390',
  'base': 'FastCpuInfoS390',
  'data': { 'slow_field': 'int' } }

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 14/32] arm/translate-a64: add FP16 pairwise ops simd_three_reg_same_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> This includes FMAXNMP, FADDP, FMAXP, FMINNMP, FMINP.
> 
> Signed-off-by: Alex Bennée 
> 
> ---
> v2
>   - checkpatch fixes
> ---
>  target/arm/translate-a64.c | 208 
> +
>  1 file changed, 133 insertions(+), 75 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v5 06/23] Softfloat support for IEEE 754-201x minimumNumber/maximumNumber

[Michael Clark]

On Fri, Feb 9, 2018 at 3:35 AM, Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 02/07/2018 05:28 PM, Michael Clark wrote:
> > QEMU currently implements IEEE 754-2008 minNum/maxNum. This patch adds
> > support for IEEE 754-201x minimumNumber/maximumNumber which is required
> > by the RISC-V port.
> >
> > minNum(x, y) is defined as
> > - min(x, y) if neither is NaN
> > - if one of x and y is a number and one is qNaN, return the number
> > - if both are qNaN, or either is sNaN, return NaN
> >
> > minimumNumber(x, y) is defined as
> > - min(x, y) if neither is NaN
> > - if one of x and y is a number and one is qNaN or sNaN, return the
> number
> > - if both are NaN, return the number
> >
> > Both functions signal the invalid exception on sNaN inputs.
> >
> > Signed-off-by: Michael Clark 
> > ---
>
> Thanks for the description of the function.  We've got a reorg of softfloat
> pending at the moment; I'd want to defer this patch until that set has
> landed.
>

Noted.

We should also add a mention of minimumNumber/maximumNumber to the
preceeding comment, which isn't in the current version of the patch. e.g.

 * minimumnumber() and maximumnumber() functions correspond to
minimumNumber()
 * and maximumNumber() from the IEEE-754 201x specification.

Re: [Qemu-devel] "make check -j4" hangs (was: Re: chardev/char-socket: add POLLHUP handler)

[Peter Maydell]

On 8 February 2018 at 19:13, Thomas Huth  wrote:
> I'm currently facing some issues with "make check -j4" (i.e. running the
> tests in parallel). Git bisect blames this commit - though I'm not sure
> whether this is really the right one ... Starting with this commit, I
> saw hangs in test-filter-redirector, but git master rather seems to hang
> with vhost-user-test instead.
> Stefan also had issues with "make check -j4" today, so it's apparently
> not only me ... can somebody else reproduce the problem with the git
> master branch?

Yeah, I was seeing odd make check hangs with parallelization enabled
too, on vhost-user-test... (my builds for merge tests are almost
all non-parallelized I think).

thanks
-- PMM

[Qemu-devel] [Bug 1748296] [NEW] TCG throws Invalid Opcode when executing x86 BMI shlx instruction

[Doug Gale]

Public bug reported:

I am unable to use BMI in my project when running under TCG. I narrowed
the problem down to incorrect instruction decoding for BMI instructions
(which have a 2 byte VEX prefix). The gen_sse function in translate.c
reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7,
or 0x3f7, so the switch takes the default path and raises an invalid
opcode exception.

The code executes correctly and passes the test under KVM.

I have created a complete repro here: https://github.com/doug65536/qemu-
bmibug

The makefile has the following utility targets:

debug-kvm: Build and run the VM using KVM and wait for gdbstub attach

run: Run the test case with TCG, make fails if the test fails. (It will
fail)

run-kvm: Run the test case with KVM, make fails if the test fails. (It
will succeed)

debug: Build and run the VM with TCG and wait for GDB attach

attach-gdb: Run GDB and attach to KVM gdbstub

The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM.

You can quickly verify the issue by executing `make run-kvm` to confirm
that KVM passes, then `make run` to confirm that TCG fails.

I believe the bug affects other BMI, BMI2, and ABM instructions, but I
have only completely verified incorrect execution of SHLX.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  TCG throws Invalid Opcode when executing x86 BMI shlx instruction

Status in QEMU:
  New

Bug description:
  I am unable to use BMI in my project when running under TCG. I
  narrowed the problem down to incorrect instruction decoding for BMI
  instructions (which have a 2 byte VEX prefix). The gen_sse function in
  translate.c reaches the goto label do_0f_38_fx, but b does not equal
  0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and
  raises an invalid opcode exception.

  The code executes correctly and passes the test under KVM.

  I have created a complete repro here: https://github.com/doug65536
  /qemu-bmibug

  The makefile has the following utility targets:

  debug-kvm: Build and run the VM using KVM and wait for gdbstub attach

  run: Run the test case with TCG, make fails if the test fails. (It
  will fail)

  run-kvm: Run the test case with KVM, make fails if the test fails. (It
  will succeed)

  debug: Build and run the VM with TCG and wait for GDB attach

  attach-gdb: Run GDB and attach to KVM gdbstub

  The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and
  ABM.

  You can quickly verify the issue by executing `make run-kvm` to
  confirm that KVM passes, then `make run` to confirm that TCG fails.

  I believe the bug affects other BMI, BMI2, and ABM instructions, but I
  have only completely verified incorrect execution of SHLX.

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

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

[Eric Blake]

On 02/08/2018 01:59 PM, Eduardo Habkost wrote:

On Wed, Feb 07, 2018 at 12:50:13PM -0500, Luiz Capitulino wrote:

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

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




+# Notes: @halted is a transient state that changes frequently.  By the time the
+#data is sent to the client, the guest may no longer be halted.
+##
+{ 'struct': 'CpuInfo2',
+  'data': {'cpu-index': 'int', '*halted': 'bool', 'qom-path': 'str',
+   'thread-id': 'int', '*props': 'CpuInstanceProperties' } }


This will require duplicating struct fields every time we add a
new field to query-cpus-fast (e.g. how would VIktor's
CpuInfoS390State patch[1] look like if rebased on top of yours?).

One way to avoid that is to use CpuInfo for both, and make all
"slow"  fields optional.  Another option is to use QAPI
inheritance, but it could be a little complicated if unions are
involved?


Inheritance is better than optional fields for the sake of introspection 
learning which fields to expect.


Put the common fields to both interfaces in the base class, then have 
the slower (older) CpuInfo class extend the base class to add the 
additional fields.


Unions should be able to inherit just fine from structs (after all, a 
flat union requires a struct base); but if we need two layers of unions, 
we'll need to enhance QAPI code generation first.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH V9 1/4] mem: add share parameter to memory-backend-ram

[Eduardo Habkost]

On Thu, Feb 01, 2018 at 10:55:08PM +0200, Marcel Apfelbaum wrote:
> Currently only file backed memory backend can
> be created with a "share" flag in order to allow
> sharing guest RAM with other processes in the host.
> 
> Add the "share" flag also to RAM Memory Backend
> in order to allow remapping parts of the guest RAM
> to different host virtual addresses. This is needed
> by the RDMA devices in order to remap non-contiguous
> QEMU virtual addresses to a contiguous virtual address range.
> 
> Moved the "share" flag to the Host Memory base class,
> modified phys_mem_alloc to include the new parameter
> and a new interface memory_region_init_ram_shared_nomigrate.
> 
> There are no functional changes if the new flag is not used.
> 
> Signed-off-by: Marcel Apfelbaum 

Code looks correct, so:

Reviewed-by: Eduardo Habkost 

But later can we please stop the explosion of memory_init_ram*()
functions and replace them with a single function with a flags
parameter?

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 11/32] arm/translate-a64: add FP16 F[A]C[EQ/GE/GT] to simd_three_reg_same_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/helper-a64.c| 49 
> ++
>  target/arm/helper-a64.h|  5 +
>  target/arm/translate-a64.c | 15 ++
>  3 files changed, 69 insertions(+)
> 
> diff --git a/target/arm/helper-a64.c b/target/arm/helper-a64.c
> index 25e45121af..78eeda31d1 100644
> --- a/target/arm/helper-a64.c
> +++ b/target/arm/helper-a64.c
> @@ -599,3 +599,52 @@ ADVSIMD_HALFOP(min)
>  ADVSIMD_HALFOP(max)
>  ADVSIMD_HALFOP(minnum)
>  ADVSIMD_HALFOP(maxnum)
> +
> +/*
> + * Floating point comparisons produce an integer result. Softfloat
> + * routines return float_relation types which we convert to the 0/-1
> + * Neon requires.
> + */
> +
> +#define ADVSIMD_CMPRES(test) (test) ? 0x : 0
> +
> +uint32_t HELPER(advsimd_ceq_f16)(float16 a, float16 b, void *fpstp)
> +{
> +float_status *fpst = fpstp;
> +int compare = float16_compare_quiet(a, b, fpst);
> +return ADVSIMD_CMPRES(compare == float_relation_equal);

Not using float16_eq etc?

> +}
> +
> +uint32_t HELPER(advsimd_cge_f16)(float16 a, float16 b, void *fpstp)
> +{
> +float_status *fpst = fpstp;
> +int compare = float16_compare(a, b, fpst);
> +return ADVSIMD_CMPRES(compare == float_relation_greater ||
> +  compare == float_relation_equal);

Especially float16_le(b, a, fpst).

Otherwise,

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 13/32] arm/translate-a64: add FP16 FR[ECP/SQRT]S to simd_three_reg_same_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/helper-a64.c| 34 ++
>  target/arm/helper-a64.h|  2 ++
>  target/arm/translate-a64.c |  6 ++
>  3 files changed, 42 insertions(+)
> 
> diff --git a/target/arm/helper-a64.c b/target/arm/helper-a64.c
> index bdfcac111f..6358b42472 100644
> --- a/target/arm/helper-a64.c
> +++ b/target/arm/helper-a64.c
> @@ -192,6 +192,10 @@ uint64_t HELPER(neon_cgt_f64)(float64 a, float64 b, void 
> *fpstp)
>   * versions, these do a fully fused multiply-add or
>   * multiply-add-and-halve.
>   */
> +#define float16_two make_float16(0x4000)
> +#define float16_three make_float16(0x4200)
> +#define float16_one_point_five make_float16(0x3e00)
> +
>  #define float32_two make_float32(0x4000)
>  #define float32_three make_float32(0x4040)
>  #define float32_one_point_five make_float32(0x3fc0)

I think we should move these somewhere else, some header
where we don't have to keep re-defining them in various
files within target/arm.

I know, for instance, that I need floatN_two in translate-sve.c.

Just putting them in softfloat.h is probably best.

Otherwise,

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 10/32] arm/translate-a64: add FP16 FADD/FABD/FSUB/FMUL/FDIV to simd_three_reg_same_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> The fprintf is only there for debugging as the skeleton is added to,
> it will be removed once the skeleton is complete.
> 
> Signed-off-by: Alex Bennée 
> 
> ---
> v2
>  - add absh helper
>  - fix checkpatch violation
> ---
>  target/arm/helper-a64.c|  9 +
>  target/arm/helper-a64.h|  5 +
>  target/arm/translate-a64.c | 28 
>  3 files changed, 42 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 09/32] arm/translate-a64: initial decode for simd_three_reg_same_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> This is the initial decode skeleton for the Advanced SIMD three same
> instruction group.
> 
> The fprintf is purely to aid debugging as the additional instructions
> are added. It will be removed once the group is complete.
> 
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/translate-a64.c | 77 
> ++
>  1 file changed, 77 insertions(+)

Reviewed-by: Richard Henderson 


r~

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

[Eric Blake]

On 02/08/2018 10:43 AM, Viktor Mihajlovski wrote:

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

With this change the output of query-cpus will look like this on
s390:

[
  {"arch": "s390", "current": true,
   "props": {"core-id": 0}, "cpu-state": "operating", "CPU": 0,
   "qom_path": "/machine/unattached/device[0]",
   "halted": false, "thread_id": 63115},
  {"arch": "s390", "current": false,
   "props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,



So the addition here is the "cpu-state" member.

QAPI changes are fine; I didn't look at the corresponding code, though, 
so you may add the weaker:


Acked-by: Eric Blake 


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH] g364fb: switch to using DirtyBitmapSnapshot

[Hervé Poussineau]

Le 08/02/2018 à 19:22, Paolo Bonzini a écrit :

This removes the last user of memory_region_test_and_clear_dirty
outside memory.c.

Cc: Hervé Poussineau 
Cc: Aurelien Jarno 
Cc: Yongbok Kim 
Signed-off-by: Paolo Bonzini 


Tested-by: Hervé Poussineau 
Tested with Windows NT 4.0


---
 Untested... not sure where to get mips_bios.bin, or a kernel
 that works with -M magnum.  Can anybody help?  I'd like to
 get rid of memory_region_test_and_clear_dirty.

  hw/display/g364fb.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/display/g364fb.c b/hw/display/g364fb.c
index 86557d14a9..86452de780 100644
--- a/hw/display/g364fb.c
+++ b/hw/display/g364fb.c
@@ -62,15 +62,15 @@ typedef struct G364State {
  
  #define G364_PAGE_SIZE 4096
  
-static inline int check_dirty(G364State *s, ram_addr_t page)

+static inline int check_dirty(G364State *s, DirtyBitmapSnapshot *snap, 
ram_addr_t page)
  {
-return memory_region_test_and_clear_dirty(>mem_vram, page, 
G364_PAGE_SIZE,
-  DIRTY_MEMORY_VGA);
+return memory_region_snapshot_get_dirty(>mem_vram, snap, page, 
G364_PAGE_SIZE);
  }
  
  static void g364fb_draw_graphic8(G364State *s)

  {
  DisplaySurface *surface = qemu_console_surface(s->con);
+DirtyBitmapSnapshot *snap;
  int i, w;
  uint8_t *vram;
  uint8_t *data_display, *dd;
@@ -122,8 +122,10 @@ static void g364fb_draw_graphic8(G364State *s)
  vram = s->vram + s->top_of_screen;
  /* XXX: out of range in vram? */
  data_display = dd = surface_data(surface);
+snap = memory_region_snapshot_and_clear_dirty(>mem_vram, 0, 
s->vram_size,
+  DIRTY_MEMORY_VGA);
  while (y < s->height) {
-if (check_dirty(s, page)) {
+if (check_dirty(s, snap, page)) {
  if (y < ymin)
  ymin = ymax = y;
  if (x < xmin)

Re: [Qemu-devel] [PATCH v5 10/14] pci: Add support for Designware IP block

[Andrey Smirnov]

On Thu, Feb 8, 2018 at 12:33 PM, Michael S. Tsirkin  wrote:
> On Thu, Feb 08, 2018 at 12:22:53PM -0800, Andrey Smirnov wrote:
>> On Thu, Feb 8, 2018 at 12:11 PM, Michael S. Tsirkin  wrote:
>> > On Thu, Feb 08, 2018 at 12:03:04PM -0800, Andrey Smirnov wrote:
>> >> >> +#define PCIE_PORT_LINK_CONTROL  0x710
>> >> >> +
>> >> >> +#define PCIE_PHY_DEBUG_R1   0x72C
>> >> >> +#define PCIE_PHY_DEBUG_R1_XMLH_LINK_UP  BIT(4)
>> >> >> +
>> >> >> +#define PCIE_LINK_WIDTH_SPEED_CONTROL   0x80C
>> >> >> +#define PORT_LOGIC_SPEED_CHANGE (0x1 << 17)
>> >> >> +
>> >> >> +#define PCIE_MSI_ADDR_LO0x820
>> >> >> +#define PCIE_MSI_ADDR_HI0x824
>> >> >> +#define PCIE_MSI_INTR0_ENABLE   0x828
>> >> >> +#define PCIE_MSI_INTR0_MASK 0x82C
>> >> >> +#define PCIE_MSI_INTR0_STATUS   0x830
>> >> >> +
>> >> >> +#define PCIE_ATU_VIEWPORT   0x900
>> >> >> +#define PCIE_ATU_REGION_INBOUND (0x1 << 31)
>> >> >> +#define PCIE_ATU_REGION_OUTBOUND(0x0 << 31)
>> >> >> +#define PCIE_ATU_REGION_INDEX2  (0x2 << 0)
>> >> >> +#define PCIE_ATU_REGION_INDEX1  (0x1 << 0)
>> >> >> +#define PCIE_ATU_REGION_INDEX0  (0x0 << 0)
>> >> >> +#define PCIE_ATU_CR10x904
>> >> >> +#define PCIE_ATU_TYPE_MEM   (0x0 << 0)
>> >> >> +#define PCIE_ATU_TYPE_IO(0x2 << 0)
>> >> >> +#define PCIE_ATU_TYPE_CFG0  (0x4 << 0)
>> >> >> +#define PCIE_ATU_TYPE_CFG1  (0x5 << 0)
>> >> >> +#define PCIE_ATU_CR20x908
>> >> >> +#define PCIE_ATU_ENABLE (0x1 << 31)
>> >> >> +#define PCIE_ATU_BAR_MODE_ENABLE(0x1 << 30)
>> >> >> +#define PCIE_ATU_LOWER_BASE 0x90C
>> >> >> +#define PCIE_ATU_UPPER_BASE 0x910
>> >> >> +#define PCIE_ATU_LIMIT  0x914
>> >> >> +#define PCIE_ATU_LOWER_TARGET   0x918
>> >> >> +#define PCIE_ATU_BUS(x) (((x) >> 24) & 0xff)
>> >> >> +#define PCIE_ATU_DEVFN(x)   (((x) >> 16) & 0xff)
>> >> >> +#define PCIE_ATU_UPPER_TARGET   0x91C
>> >
>> > Can you avoid a PCIE prefix for this btw?
>> >
>>
>> That's how those constants were named in Linux kernel, but yeah, I'll
>> add a prefix to them.
>>
>> Thanks,
>> Andrey Smirnov
>
> In that case you should not copy it into your file.
> Stuff from linux kernel should be imported into standard-headers.
>

Just to be sure we are on the same page, this is the file I am talking about:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/dwc/pcie-designware.h?h=v4.15

you want me to put it in standard-headers/linux and get those
constants from there?

Thanks,
Andrey Smirnov

Re: [Qemu-devel] [PATCH v2 06/32] target/arm/helper: pass explicit fpst to set_rmode

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> As the rounding mode is now split between FP16 and the rest of
> floating point we need to be explicit when tweaking it. Instead of
> passing the CPU env we now pass the appropriate fpst pointer directly.
> 
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/helper.c|  4 ++--
>  target/arm/helper.h|  2 +-
>  target/arm/translate-a64.c | 26 +-
>  target/arm/translate.c | 12 ++--
>  4 files changed, 22 insertions(+), 22 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 12/32] arm/translate-a64: add FP16 FMULA/X/S to simd_three_reg_same_fp16

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/helper-a64.c| 24 
>  target/arm/helper-a64.h|  2 ++
>  target/arm/translate-a64.c | 15 +++
>  3 files changed, 41 insertions(+)
> 
> diff --git a/target/arm/helper-a64.c b/target/arm/helper-a64.c
> index 78eeda31d1..bdfcac111f 100644
> --- a/target/arm/helper-a64.c
> +++ b/target/arm/helper-a64.c
> @@ -600,6 +600,30 @@ ADVSIMD_HALFOP(max)
>  ADVSIMD_HALFOP(minnum)
>  ADVSIMD_HALFOP(maxnum)
>  
> +/* Data processing - scalar floating-point and advanced SIMD */
> +float16 HELPER(advsimd_mulxh)(float16 a, float16 b, void *fpstp)
> +{
> +float_status *fpst = fpstp;
> +
> +a = float16_squash_input_denormal(a, fpst);
> +b = float16_squash_input_denormal(b, fpst);
> +
> +if ((float16_is_zero(a) && float16_is_infinity(b)) ||
> +(float16_is_infinity(a) && float16_is_zero(b))) {
> +/* 2.0 with the sign bit set to sign(A) XOR sign(B) */
> +return make_float16((1U << 14) |
> +((float16_val(a) ^ float16_val(b)) & (1U << 
> 15)));

Since you diced all of the structures, are you going to dice all of the (now
pointless) make/val calls?

Otherwise,

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 07/32] arm/translate-a64: implement half-precision F(MIN|MAX)(V|NMV)

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> +DEF_HELPER_3(advsimd_maxh, f16, f16, f16, ptr)
> +DEF_HELPER_3(advsimd_minh, f16, f16, f16, ptr)
> +DEF_HELPER_3(advsimd_maxnumh, f16, f16, f16, ptr)
> +DEF_HELPER_3(advsimd_minnumh, f16, f16, f16, ptr)

DEF_HELPER_FLAGS_3 with TCG_CALL_NO_RWG.


r~

Re: [Qemu-devel] [PATCH v2 05/32] target/arm/cpu.h: add additional float_status flags

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> @@ -10750,15 +10751,22 @@ void HELPER(vfp_set_fpscr)(CPUARMState *env, 
> uint32_t val)
>  }
>  set_float_rounding_mode(i, >vfp.fp_status);
>  }
> -if (changed & (1 << 24)) {
> +if (changed & (1 << 19)) { /* FPCR:FZ16 */
> +set_flush_to_zero((val & (1 << 19)) != 0, >vfp.fp_status_f16);
> +set_flush_inputs_to_zero((val & (1 << 19)) != 0,
> + >vfp.fp_status_f16);
> +}
> +if (changed & (1 << 24)) { /* FPCR:FZ */
>  set_flush_to_zero((val & (1 << 24)) != 0, >vfp.fp_status);
>  set_flush_inputs_to_zero((val & (1 << 24)) != 0, 
> >vfp.fp_status);
>  }
> -if (changed & (1 << 25))
> +if (changed & (1 << 25)) { /* FPCR:DN */
>  set_default_nan_mode((val & (1 << 25)) != 0, >vfp.fp_status);
> +}

This misses changing rounding mode and default_nan_mode for fp_status_f16.

>  set_float_exception_flags(i, >vfp.fp_status);
> +set_float_exception_flags(i, >vfp.fp_status_f16);
>  set_float_exception_flags(0, >vfp.standard_fp_status);

I think you should store 0 into fp_status_f16 here.  The exception flags are
OR'ed together when reading; there's not too much point in replicating it out.


r~

Re: [Qemu-devel] [RFC PATCH 2/5] vfio/quirks: Add generic support for ioveventfds

[Auger Eric]

Hi Alex,

On 08/02/18 19:33, Alex Williamson wrote:
> On Thu, 8 Feb 2018 12:11:57 +0100
> Auger Eric  wrote:
> 
>> Hi Alex,
>>
>> On 07/02/18 01:26, Alex Williamson wrote:
>>> We might wish to handle some quirks via ioeventfds, add a list of
>>> ioeventfds to the quirk.  
>> The commit title is a bit misleading as we only add the data type and
>> deletion function.
> 
> Unfortunately that's as much as I can add here or else QEMU will fail
> to build because of unused functions :-\  So I pulled as much
> infrastructure as I could here but had to leave some meat for when it
> gets called.  Suggestions welcome for title/commit updates.

Understood. Something like "vfio/quirks: Add a VFIOIOEventFD list in
quirks"?
> 
>>>
>>> Signed-off-by: Alex Williamson 
>>> ---
>>>  hw/vfio/pci-quirks.c |   17 +
>>>  hw/vfio/pci.h|   11 +++
>>>  2 files changed, 28 insertions(+)
>>>
>>> diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
>>> index 10af23217292..e4cf4ea2dd9c 100644
>>> --- a/hw/vfio/pci-quirks.c
>>> +++ b/hw/vfio/pci-quirks.c
>>> @@ -12,6 +12,7 @@
>>>  
>>>  #include "qemu/osdep.h"
>>>  #include "qemu/error-report.h"
>>> +#include "qemu/main-loop.h"
>>>  #include "qemu/range.h"
>>>  #include "qapi/error.h"
>>>  #include "qapi/visitor.h"
>>> @@ -278,12 +279,24 @@ static const MemoryRegionOps vfio_ati_3c3_quirk = {
>>>  static VFIOQuirk *vfio_quirk_alloc(int nr_mem)
>>>  {
>>>  VFIOQuirk *quirk = g_malloc0(sizeof(*quirk));
>>> +QLIST_INIT(>ioeventfds);
>>>  quirk->mem = g_new0(MemoryRegion, nr_mem);
>>>  quirk->nr_mem = nr_mem;
>>>  
>>>  return quirk;
>>>  }
>>>  
>>> +static void vfio_ioeventfd_exit(VFIOIOEventFD *ioeventfd)
>>> +{
>>> +QLIST_REMOVE(ioeventfd, next);
>>> +memory_region_del_eventfd(ioeventfd->mr, ioeventfd->addr, 
>>> ioeventfd->size,
>>> +  ioeventfd->match_data, ioeventfd->data,
>>> +  >e);
>>> +qemu_set_fd_handler(event_notifier_get_fd(>e), NULL, NULL, 
>>> NULL);
>>> +event_notifier_cleanup(>e);
>>> +g_free(ioeventfd);
>>> +}
>>> +
>>>  static void vfio_vga_probe_ati_3c3_quirk(VFIOPCIDevice *vdev)
>>>  {
>>>  VFIOQuirk *quirk;
>>> @@ -1668,6 +1681,10 @@ void vfio_bar_quirk_exit(VFIOPCIDevice *vdev, int nr)
>>>  int i;
>>>  
>>>  QLIST_FOREACH(quirk, >quirks, next) {
>>> +while (!QLIST_EMPTY(>ioeventfds)) {
>>> +vfio_ioeventfd_exit(QLIST_FIRST(>ioeventfds));
>>> +}
>>> +
>>>  for (i = 0; i < quirk->nr_mem; i++) {
>>>  memory_region_del_subregion(bar->region.mem, >mem[i]);
>>>  }
>>> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
>>> index f4aa13e021fa..146065c2f715 100644
>>> --- a/hw/vfio/pci.h
>>> +++ b/hw/vfio/pci.h
>>> @@ -24,9 +24,20 @@
>>>  
>>>  struct VFIOPCIDevice;
>>>  
>>> +typedef struct VFIOIOEventFD {
>>> +QLIST_ENTRY(VFIOIOEventFD) next;
>>> +MemoryRegion *mr;
>>> +hwaddr addr;
>>> +unsigned size;
>>> +bool match_data;  
>> Shouldn't you add the match_data field also in the kernel uapi?
> 
> In the vfio uapi?  vfio isn't matching anything and has no ability to
> match anything, it's just triggering a pre-programmed write via
> eventfd.  Maybe I'm not understanding the comment.  Thanks,

Yes that not sensible. We have a KVM ioeventfd that triggers an fd only
if the address/data matches and this VFIO "ioeventfd" listens to this fd
and writes the fixed address/data. At the beginning I was thinking about
having the VFIO handler taking in charge any value written at this
address but there is no way to retrieve the value besides doing a fixed
assignment from userspace. Sorry for the noise.

Thanks

Eric
> 
> Alex
> 

Re: [Qemu-devel] [RFC PATCH 3/5] vfio/quirks: Automatic ioeventfd enabling for NVIDIA BAR0 quirks

[Auger Eric]

Hi Alex,

On 08/02/18 19:24, Alex Williamson wrote:
> On Thu, 8 Feb 2018 12:10:02 +0100
> Auger Eric  wrote:
> 
>> Hi Alex,
>>
>> On 07/02/18 01:26, Alex Williamson wrote:
>>> Record data writes that come through the NVIDIA BAR0 quirk, if we get
>>> enough in a row that we're only passing through, automatically enable
>>> an ioeventfd for it.  The primary target for this is the MSI-ACK
>>> that NVIDIA uses to allow the MSI interrupt to re-trigger, which is a
>>> 4-byte write, data value 0x0 to offset 0x704 into the quirk, 0x88704
>>> into BAR0 MMIO space.  For an interrupt latency sensitive micro-
>>> benchmark, this takes us from 83% of performance versus disabling the
>>> quirk entirely (which GeForce cannot do), to to almost 90%.
>>>
>>> Signed-off-by: Alex Williamson 
>>> ---
>>>  hw/vfio/pci-quirks.c |   89 
>>> +-
>>>  hw/vfio/pci.h|2 +
>>>  2 files changed, 89 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
>>> index e4cf4ea2dd9c..e739efe601b1 100644lg  
>>
>>> --- a/hw/vfio/pci-quirks.c
>>> +++ b/hw/vfio/pci-quirks.c
>>> @@ -203,6 +203,7 @@ typedef struct VFIOConfigMirrorQuirk {
>>>  uint32_t offset;
>>>  uint8_t bar;
>>>  MemoryRegion *mem;
>>> +uint8_t data[];  
>> Do you foresee other usages of data besides the LastDataSet?
> 
> Sure, LastDataSet is just a very crude tracking mechanism, I could
> imagine some kind of device specific LRU array.  Any quirk wanting to
> add additional analytics on top of this generic quirk could make use of
> it.  I didn't want to pollute the generic quirk with LastDataSet since
> there are other users, but I also didn't want to complicate the shared
> free'ing path we have by simply adding a pointer.  Thus embedding quirk
> specific data is what I went with here.

OK
> 
>>>  } VFIOConfigMirrorQuirk;
>>>  
>>>  static uint64_t vfio_generic_quirk_mirror_read(void *opaque,
>>> @@ -297,6 +298,50 @@ static void vfio_ioeventfd_exit(VFIOIOEventFD 
>>> *ioeventfd)
>>>  g_free(ioeventfd);
>>>  }
>>>
>> add a comment? user handler in case kvm ioeventfd setup failed?
> 
> As you correctly updated later, we're only setting up the kvm-user
> ioeventfd handler in this patch.  This is the handler when that
> succeeds.  Once we add vfio ioeventfd support, this handler will
> hopefully never get used, but we still need to support kernels that
> won't have vfio ioeventfd support and this alone does still provide a
> performance improvement.
> 
>>> +static void vfio_ioeventfd_handler(void *opaque)
>>> +{
>>> +VFIOIOEventFD *ioeventfd = opaque;
>>> +
>>> +if (event_notifier_test_and_clear(>e)) {
>>> +vfio_region_write(ioeventfd->region, ioeventfd->region_addr,
>>> +  ioeventfd->data, ioeventfd->size);
>>> +}
>>> +}
>>> +
>>> +static VFIOIOEventFD *vfio_ioeventfd_init(VFIOPCIDevice *vdev,
>>> +  MemoryRegion *mr, hwaddr addr,
>>> +  unsigned size, uint64_t data,
>>> +  VFIORegion *region,
>>> +  hwaddr region_addr)
>>> +{
>>> +VFIOIOEventFD *ioeventfd = g_malloc0(sizeof(*ioeventfd));
>>> +
>>> +if (event_notifier_init(>e, 0)) {
>>> +g_free(ioeventfd);
>>> +return NULL;
>>> +}
>>> +
>>> +ioeventfd->mr = mr;
>>> +ioeventfd->addr = addr;
>>> +ioeventfd->size = size;
>>> +ioeventfd->match_data = true;
>>> +ioeventfd->data = data;
>>> +ioeventfd->region = region;
>>> +ioeventfd->region_addr = region_addr;  
>> I found difficult to follow the different addr semantic.
>> I understand region_add is the offset % bar and addr is the offset %
>> mirror region. Maybe more explicit names would help (region = bar_region
>> and region_addr = bar_offset)
> 
> I was trying to avoid PCI specific fields for VFIOIOEventFD, but
> basically we're dealing with two different sets of base and offset.
> The first is the MemoryRegion of the quirk and the offset relative to
> that MemoryRegion.  Those are used by memory_region_add_eventfd() for
> establishing the kvm ioeventfd.  The second is the region and
> region_addr, which identify the vfio region and offset relative to the
> region so that we can actually handle it with vfio_region_write().
> 
> I agree though that these are confusing and maybe comments are a
> solution as I can't think of better names:
> 
> /*
>  * MemoryRegion and relative offset, plus additional ioeventfd setup
>  * parameters for configuring and later tearing down KVM ioeventfd.
>  */
> ioeventfd->mr = mr;
> ioeventfd->addr = addr;
> ioeventfd->size = size;
> ioeventfd->match_data = true;
> ioeventfd->data = data;
> /*
>  * VFIORegion and relative offset for implementing the userspace
>  * handler.  data 

Re: [Qemu-devel] [PATCH v2 08/32] arm/translate-a64: handle_3same_64 comment fix

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> We do implement all the opcodes.
> 
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/translate-a64.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 03/32] target/arm/cpu64: allow fp16 to be disabled

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> While for CONFIG_USER_ONLY it is policy for the "cpu" to be the most
> capable is can be this does cause problems. For example legacy RISU
> runs would fail as there are a bunch of implemented instructions which
> would have caused failures that now trigger actual calculations.
> 
> Signed-off-by: Alex Bennée 
> ---
>  target/arm/cpu64.c | 27 +++
>  1 file changed, 27 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 07/32] arm/translate-a64: implement half-precision F(MIN|MAX)(V|NMV)

[Richard Henderson]

On 02/08/2018 09:31 AM, Alex Bennée wrote:
> This implements the half-precision variants of the across vector
> reduction operations. This involves a re-factor of the reduction code
> which more closely matches the ARM ARM order (and handles 8 element
> reductions).
> 
> Signed-off-by: Alex Bennée 
> 
> --
> v1
>   - dropped the advsimd_2a stuff
> v2
>   - fixed up checkpatch
> ---
>  target/arm/helper-a64.c|  18 ++
>  target/arm/helper-a64.h|   4 ++
>  target/arm/translate-a64.c | 144 
> -
>  3 files changed, 111 insertions(+), 55 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v5 10/14] pci: Add support for Designware IP block

[Michael S. Tsirkin]

On Thu, Feb 08, 2018 at 12:22:53PM -0800, Andrey Smirnov wrote:
> On Thu, Feb 8, 2018 at 12:11 PM, Michael S. Tsirkin  wrote:
> > On Thu, Feb 08, 2018 at 12:03:04PM -0800, Andrey Smirnov wrote:
> >> >> +#define PCIE_PORT_LINK_CONTROL  0x710
> >> >> +
> >> >> +#define PCIE_PHY_DEBUG_R1   0x72C
> >> >> +#define PCIE_PHY_DEBUG_R1_XMLH_LINK_UP  BIT(4)
> >> >> +
> >> >> +#define PCIE_LINK_WIDTH_SPEED_CONTROL   0x80C
> >> >> +#define PORT_LOGIC_SPEED_CHANGE (0x1 << 17)
> >> >> +
> >> >> +#define PCIE_MSI_ADDR_LO0x820
> >> >> +#define PCIE_MSI_ADDR_HI0x824
> >> >> +#define PCIE_MSI_INTR0_ENABLE   0x828
> >> >> +#define PCIE_MSI_INTR0_MASK 0x82C
> >> >> +#define PCIE_MSI_INTR0_STATUS   0x830
> >> >> +
> >> >> +#define PCIE_ATU_VIEWPORT   0x900
> >> >> +#define PCIE_ATU_REGION_INBOUND (0x1 << 31)
> >> >> +#define PCIE_ATU_REGION_OUTBOUND(0x0 << 31)
> >> >> +#define PCIE_ATU_REGION_INDEX2  (0x2 << 0)
> >> >> +#define PCIE_ATU_REGION_INDEX1  (0x1 << 0)
> >> >> +#define PCIE_ATU_REGION_INDEX0  (0x0 << 0)
> >> >> +#define PCIE_ATU_CR10x904
> >> >> +#define PCIE_ATU_TYPE_MEM   (0x0 << 0)
> >> >> +#define PCIE_ATU_TYPE_IO(0x2 << 0)
> >> >> +#define PCIE_ATU_TYPE_CFG0  (0x4 << 0)
> >> >> +#define PCIE_ATU_TYPE_CFG1  (0x5 << 0)
> >> >> +#define PCIE_ATU_CR20x908
> >> >> +#define PCIE_ATU_ENABLE (0x1 << 31)
> >> >> +#define PCIE_ATU_BAR_MODE_ENABLE(0x1 << 30)
> >> >> +#define PCIE_ATU_LOWER_BASE 0x90C
> >> >> +#define PCIE_ATU_UPPER_BASE 0x910
> >> >> +#define PCIE_ATU_LIMIT  0x914
> >> >> +#define PCIE_ATU_LOWER_TARGET   0x918
> >> >> +#define PCIE_ATU_BUS(x) (((x) >> 24) & 0xff)
> >> >> +#define PCIE_ATU_DEVFN(x)   (((x) >> 16) & 0xff)
> >> >> +#define PCIE_ATU_UPPER_TARGET   0x91C
> >
> > Can you avoid a PCIE prefix for this btw?
> >
> 
> That's how those constants were named in Linux kernel, but yeah, I'll
> add a prefix to them.
> 
> Thanks,
> Andrey Smirnov

In that case you should not copy it into your file.
Stuff from linux kernel should be imported into standard-headers.


-- 
MST

Re: [Qemu-devel] [PATCH v5 10/14] pci: Add support for Designware IP block

[Michael S. Tsirkin]

On Thu, Feb 08, 2018 at 12:03:04PM -0800, Andrey Smirnov wrote:
> >> +#define PCIE_PORT_LINK_CONTROL  0x710
> >> +
> >> +#define PCIE_PHY_DEBUG_R1   0x72C
> >> +#define PCIE_PHY_DEBUG_R1_XMLH_LINK_UP  BIT(4)
> >> +
> >> +#define PCIE_LINK_WIDTH_SPEED_CONTROL   0x80C
> >> +#define PORT_LOGIC_SPEED_CHANGE (0x1 << 17)
> >> +
> >> +#define PCIE_MSI_ADDR_LO0x820
> >> +#define PCIE_MSI_ADDR_HI0x824
> >> +#define PCIE_MSI_INTR0_ENABLE   0x828
> >> +#define PCIE_MSI_INTR0_MASK 0x82C
> >> +#define PCIE_MSI_INTR0_STATUS   0x830
> >> +
> >> +#define PCIE_ATU_VIEWPORT   0x900
> >> +#define PCIE_ATU_REGION_INBOUND (0x1 << 31)
> >> +#define PCIE_ATU_REGION_OUTBOUND(0x0 << 31)
> >> +#define PCIE_ATU_REGION_INDEX2  (0x2 << 0)
> >> +#define PCIE_ATU_REGION_INDEX1  (0x1 << 0)
> >> +#define PCIE_ATU_REGION_INDEX0  (0x0 << 0)
> >> +#define PCIE_ATU_CR10x904
> >> +#define PCIE_ATU_TYPE_MEM   (0x0 << 0)
> >> +#define PCIE_ATU_TYPE_IO(0x2 << 0)
> >> +#define PCIE_ATU_TYPE_CFG0  (0x4 << 0)
> >> +#define PCIE_ATU_TYPE_CFG1  (0x5 << 0)
> >> +#define PCIE_ATU_CR20x908
> >> +#define PCIE_ATU_ENABLE (0x1 << 31)
> >> +#define PCIE_ATU_BAR_MODE_ENABLE(0x1 << 30)
> >> +#define PCIE_ATU_LOWER_BASE 0x90C
> >> +#define PCIE_ATU_UPPER_BASE 0x910
> >> +#define PCIE_ATU_LIMIT  0x914
> >> +#define PCIE_ATU_LOWER_TARGET   0x918
> >> +#define PCIE_ATU_BUS(x) (((x) >> 24) & 0xff)
> >> +#define PCIE_ATU_DEVFN(x)   (((x) >> 16) & 0xff)
> >> +#define PCIE_ATU_UPPER_TARGET   0x91C

Can you avoid a PCIE prefix for this btw?

Thaks!

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

[Eduardo Habkost]

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

I'd just drop it, unless we find a use case where it's really
useful.

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

-- 
Eduardo

[Qemu-devel] [PATCH 14/14] tests/boot-serial-test: Add support for the aarch64 virt machine

[Thomas Huth]

From: Wei Huang 

This patch adds a small binary kernel to test aarch64 virt machine's
UART.

Signed-off-by: Wei Huang 
[thuth: Fixed contextual conflict with the hppa patch]
Signed-off-by: Thomas Huth 
---
 tests/Makefile.include   | 1 +
 tests/boot-serial-test.c | 9 +
 2 files changed, 10 insertions(+)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 6609276..cc7e7dc 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -371,6 +371,7 @@ gcov-files-arm-y += hw/timer/arm_mptimer.c
 check-qtest-arm-y += tests/boot-serial-test$(EXESUF)
 
 check-qtest-aarch64-y = tests/numa-test$(EXESUF)
+check-qtest-aarch64-y += tests/boot-serial-test$(EXESUF)
 
 check-qtest-microblazeel-y = $(check-qtest-microblaze-y)
 
diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index 72873ee..511bf31 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -55,6 +55,13 @@ static const uint8_t bios_raspi2[] = {
 0x00, 0x10, 0x20, 0x3f, /* 0x3f201000 = UART0 base addr */
 };
 
+static const uint8_t kernel_aarch64[] = {
+0x81, 0x0a, 0x80, 0x52, /* mov w1, #0x54 */
+0x02, 0x20, 0xa1, 0xd2, /* mov x2, #0x900 */
+0x41, 0x00, 0x00, 0x39, /* strbw1, [x2] */
+0xfd, 0xff, 0xff, 0x17, /* b   -12 (loop) */
+};
+
 typedef struct testdef {
 const char *arch;   /* Target architecture */
 const char *machine;/* Name of the machine */
@@ -95,6 +102,8 @@ static testdef_t tests[] = {
 { "moxie", "moxiesim", "", "TT", sizeof(bios_moxiesim), 0, bios_moxiesim },
 { "arm", "raspi2", "", "TT", sizeof(bios_raspi2), 0, bios_raspi2 },
 { "hppa", "hppa", "", "SeaBIOS wants SYSTEM HALT" },
+{ "aarch64", "virt", "-cpu cortex-a57", "TT", sizeof(kernel_aarch64),
+  kernel_aarch64 },
 
 { NULL }
 };
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v5 10/14] pci: Add support for Designware IP block

[Andrey Smirnov]

On Thu, Feb 8, 2018 at 12:11 PM, Michael S. Tsirkin  wrote:
> On Thu, Feb 08, 2018 at 12:03:04PM -0800, Andrey Smirnov wrote:
>> >> +#define PCIE_PORT_LINK_CONTROL  0x710
>> >> +
>> >> +#define PCIE_PHY_DEBUG_R1   0x72C
>> >> +#define PCIE_PHY_DEBUG_R1_XMLH_LINK_UP  BIT(4)
>> >> +
>> >> +#define PCIE_LINK_WIDTH_SPEED_CONTROL   0x80C
>> >> +#define PORT_LOGIC_SPEED_CHANGE (0x1 << 17)
>> >> +
>> >> +#define PCIE_MSI_ADDR_LO0x820
>> >> +#define PCIE_MSI_ADDR_HI0x824
>> >> +#define PCIE_MSI_INTR0_ENABLE   0x828
>> >> +#define PCIE_MSI_INTR0_MASK 0x82C
>> >> +#define PCIE_MSI_INTR0_STATUS   0x830
>> >> +
>> >> +#define PCIE_ATU_VIEWPORT   0x900
>> >> +#define PCIE_ATU_REGION_INBOUND (0x1 << 31)
>> >> +#define PCIE_ATU_REGION_OUTBOUND(0x0 << 31)
>> >> +#define PCIE_ATU_REGION_INDEX2  (0x2 << 0)
>> >> +#define PCIE_ATU_REGION_INDEX1  (0x1 << 0)
>> >> +#define PCIE_ATU_REGION_INDEX0  (0x0 << 0)
>> >> +#define PCIE_ATU_CR10x904
>> >> +#define PCIE_ATU_TYPE_MEM   (0x0 << 0)
>> >> +#define PCIE_ATU_TYPE_IO(0x2 << 0)
>> >> +#define PCIE_ATU_TYPE_CFG0  (0x4 << 0)
>> >> +#define PCIE_ATU_TYPE_CFG1  (0x5 << 0)
>> >> +#define PCIE_ATU_CR20x908
>> >> +#define PCIE_ATU_ENABLE (0x1 << 31)
>> >> +#define PCIE_ATU_BAR_MODE_ENABLE(0x1 << 30)
>> >> +#define PCIE_ATU_LOWER_BASE 0x90C
>> >> +#define PCIE_ATU_UPPER_BASE 0x910
>> >> +#define PCIE_ATU_LIMIT  0x914
>> >> +#define PCIE_ATU_LOWER_TARGET   0x918
>> >> +#define PCIE_ATU_BUS(x) (((x) >> 24) & 0xff)
>> >> +#define PCIE_ATU_DEVFN(x)   (((x) >> 16) & 0xff)
>> >> +#define PCIE_ATU_UPPER_TARGET   0x91C
>
> Can you avoid a PCIE prefix for this btw?
>

That's how those constants were named in Linux kernel, but yeah, I'll
add a prefix to them.

Thanks,
Andrey Smirnov

[Qemu-devel] [PATCH 13/14] tests/boot-serial: Add tests for PowerPC Mac machines

[Thomas Huth]

OpenBIOS prints out the CPU type on these machine types, so we can use
this string to test whether the CPU detection is working correctly.

Acked-by: Mark Cave-Ayland 
Signed-off-by: Thomas Huth 
---
 tests/boot-serial-test.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index 996d3d7..72873ee 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -69,8 +69,11 @@ static testdef_t tests[] = {
 { "alpha", "clipper", "", "PCI:" },
 { "ppc", "ppce500", "", "U-Boot" },
 { "ppc", "prep", "", "Open Hack'Ware BIOS" },
+{ "ppc", "g3beige", "", "PowerPC,750" },
+{ "ppc", "mac99", "", "PowerPC,G4" },
 { "ppc64", "ppce500", "", "U-Boot" },
 { "ppc64", "prep", "", "Open Hack'Ware BIOS" },
+{ "ppc64", "mac99", "", "PowerPC,970FX" },
 { "ppc64", "pseries", "", "Open Firmware" },
 { "ppc64", "powernv", "-cpu POWER8", "OPAL" },
 { "i386", "isapc", "-cpu qemu32 -device sga", "SGABIOS" },
-- 
1.8.3.1

[Qemu-devel] [PATCH 11/14] wdt_ib700-test: Drop dependence on global_qtest

[Thomas Huth]

From: Eric Blake 

As a general rule, we prefer avoiding implicit global state
because it makes code harder to safely copy and paste without
thinking about the global state.  Improve this test to be
explicit about the state.

Signed-off-by: Eric Blake 
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/wdt_ib700-test.c | 63 +++---
 1 file changed, 34 insertions(+), 29 deletions(-)

diff --git a/tests/wdt_ib700-test.c b/tests/wdt_ib700-test.c
index 4fc8eea..4bb8374 100644
--- a/tests/wdt_ib700-test.c
+++ b/tests/wdt_ib700-test.c
@@ -11,9 +11,9 @@
 #include "libqtest.h"
 #include "qemu/timer.h"
 
-static void qmp_check_no_event(void)
+static void qmp_check_no_event(QTestState *s)
 {
-QDict *resp = qmp("{'execute':'query-status'}");
+QDict *resp = qtest_qmp(s, "{'execute':'query-status'}");
 g_assert(qdict_haskey(resp, "return"));
 QDECREF(resp);
 }
@@ -22,30 +22,30 @@ static QDict *ib700_program_and_wait(QTestState *s)
 {
 QDict *event, *data;
 
-clock_step(NANOSECONDS_PER_SECOND * 40);
-qmp_check_no_event();
+qtest_clock_step(s, NANOSECONDS_PER_SECOND * 40);
+qmp_check_no_event(s);
 
 /* 2 second limit */
-outb(0x443, 14);
+qtest_outb(s, 0x443, 14);
 
 /* Ping */
-clock_step(NANOSECONDS_PER_SECOND);
-qmp_check_no_event();
-outb(0x443, 14);
+qtest_clock_step(s, NANOSECONDS_PER_SECOND);
+qmp_check_no_event(s);
+qtest_outb(s, 0x443, 14);
 
 /* Disable */
-clock_step(NANOSECONDS_PER_SECOND);
-qmp_check_no_event();
-outb(0x441, 1);
-clock_step(3 * NANOSECONDS_PER_SECOND);
-qmp_check_no_event();
+qtest_clock_step(s, NANOSECONDS_PER_SECOND);
+qmp_check_no_event(s);
+qtest_outb(s, 0x441, 1);
+qtest_clock_step(s, 3 * NANOSECONDS_PER_SECOND);
+qmp_check_no_event(s);
 
 /* Enable and let it fire */
-outb(0x443, 13);
-clock_step(3 * NANOSECONDS_PER_SECOND);
-qmp_check_no_event();
-clock_step(2 * NANOSECONDS_PER_SECOND);
-event = qmp_eventwait_ref("WATCHDOG");
+qtest_outb(s, 0x443, 13);
+qtest_clock_step(s, 3 * NANOSECONDS_PER_SECOND);
+qmp_check_no_event(s);
+qtest_clock_step(s, 2 * NANOSECONDS_PER_SECOND);
+event = qtest_qmp_eventwait_ref(s, "WATCHDOG");
 data = qdict_get_qdict(event, "data");
 QINCREF(data);
 QDECREF(event);
@@ -56,48 +56,53 @@ static QDict *ib700_program_and_wait(QTestState *s)
 static void ib700_pause(void)
 {
 QDict *d;
-QTestState *s = qtest_start("-watchdog-action pause -device ib700");
+QTestState *s = qtest_init("-watchdog-action pause -device ib700");
+
 qtest_irq_intercept_in(s, "ioapic");
 d = ib700_program_and_wait(s);
 g_assert(!strcmp(qdict_get_str(d, "action"), "pause"));
 QDECREF(d);
-qmp_eventwait("STOP");
-qtest_end();
+qtest_qmp_eventwait(s, "STOP");
+qtest_quit(s);
 }
 
 static void ib700_reset(void)
 {
 QDict *d;
-QTestState *s = qtest_start("-watchdog-action reset -device ib700");
+QTestState *s = qtest_init("-watchdog-action reset -device ib700");
+
 qtest_irq_intercept_in(s, "ioapic");
 d = ib700_program_and_wait(s);
 g_assert(!strcmp(qdict_get_str(d, "action"), "reset"));
 QDECREF(d);
-qmp_eventwait("RESET");
-qtest_end();
+qtest_qmp_eventwait(s, "RESET");
+qtest_quit(s);
 }
 
 static void ib700_shutdown(void)
 {
 QDict *d;
-QTestState *s = qtest_start("-watchdog-action reset -no-reboot -device 
ib700");
+QTestState *s;
+
+s = qtest_init("-watchdog-action reset -no-reboot -device ib700");
 qtest_irq_intercept_in(s, "ioapic");
 d = ib700_program_and_wait(s);
 g_assert(!strcmp(qdict_get_str(d, "action"), "reset"));
 QDECREF(d);
-qmp_eventwait("SHUTDOWN");
-qtest_end();
+qtest_qmp_eventwait(s, "SHUTDOWN");
+qtest_quit(s);
 }
 
 static void ib700_none(void)
 {
 QDict *d;
-QTestState *s = qtest_start("-watchdog-action none -device ib700");
+QTestState *s = qtest_init("-watchdog-action none -device ib700");
+
 qtest_irq_intercept_in(s, "ioapic");
 d = ib700_program_and_wait(s);
 g_assert(!strcmp(qdict_get_str(d, "action"), "none"));
 QDECREF(d);
-qtest_end();
+qtest_quit(s);
 }
 
 int main(int argc, char **argv)
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v2 0/3] virtio-balloon: free page hint reporting support

[Dr. David Alan Gilbert]

* Wei Wang (wei.w.w...@intel.com) wrote:
> This is the deivce part implementation to add a new feature,
> VIRTIO_BALLOON_F_FREE_PAGE_HINT to the virtio-balloon device. The device
> receives the guest free page hints from the driver and clears the
> corresponding bits in the dirty bitmap, so that those free pages are
> not transferred by the migration thread to the destination.
> 
> Please see the driver patch link for test results:
> https://lkml.org/lkml/2018/2/4/60

Hi Wei,
   I'll look at the code a bit more - but first some more basic
questions on that lkml post:

a) The idle guest time thing is a nice result; can you just state
   what the host was, speed of connection, and what other options
   you were using?

b) The workload test, the one with the kernel compile; you list
   the kernel compile time but don't mention any changes in the
   migration times of the ping-pong; can you give those times as
   well?

c) What's your real workload that this is aimed at?
   Is it really for people migrating idle VMs - or do you have some
   NFV application in mind, if so why not include a figure for
   those?

Thanks,

Dave

> ChangeLog:
> v1->v2: 
> 1) virtio-balloon
> - use subsections to save free_page_report_cmd_id;
> - poll the free page vq after sending a cmd id to the driver;
> - change the free page vq size to VIRTQUEUE_MAX_SIZE;
> - virtio_balloon_poll_free_page_hints: handle the corner case
>   that the free page block reported from the driver may cross
>   the RAMBlock boundary.
> 2) migration/ram.c
> - use balloon_free_page_poll to start the optimization
> 
> Wei Wang (3):
>   virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
>   migration: use the free page reporting feature from balloon
>   virtio-balloon: add a timer to limit the free page report waiting time
> 
>  balloon.c   |  39 ++--
>  hw/virtio/virtio-balloon.c  | 227 
> ++--
>  hw/virtio/virtio-pci.c  |   3 +
>  include/hw/virtio/virtio-balloon.h  |  15 +-
>  include/migration/misc.h|   3 +
>  include/standard-headers/linux/virtio_balloon.h |   7 +
>  include/sysemu/balloon.h|  12 +-
>  migration/ram.c |  34 +++-
>  8 files changed, 307 insertions(+), 33 deletions(-)
> 
> -- 
> 1.8.3.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Qemu-devel] [PATCH 09/14] qmp-test: Drop dependence on global_qtest

[Thomas Huth]

From: Eric Blake 

As a general rule, we prefer avoiding implicit global state
because it makes code harder to safely copy and paste without
thinking about the global state.  Although qmp-test does not
maintain parallel qtest connections, it was the last test
assigning to global_qtest.  It's just as easy to be explicit
about the state; once all tests have been cleaned up, a later
patch can then get rid of global_qtest and a layer of wrappers
in libqtest.

Signed-off-by: Eric Blake 
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/qmp-test.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/tests/qmp-test.c b/tests/qmp-test.c
index 36feb22..db34c45 100644
--- a/tests/qmp-test.c
+++ b/tests/qmp-test.c
@@ -41,32 +41,32 @@ static void test_version(QObject *version)
 visit_free(v);
 }
 
-static void test_malformed(void)
+static void test_malformed(QTestState *qts)
 {
 QDict *resp;
 
 /* Not even a dictionary */
-resp = qmp("null");
+resp = qtest_qmp(qts, "null");
 g_assert_cmpstr(get_error_class(resp), ==, "GenericError");
 QDECREF(resp);
 
 /* No "execute" key */
-resp = qmp("{}");
+resp = qtest_qmp(qts, "{}");
 g_assert_cmpstr(get_error_class(resp), ==, "GenericError");
 QDECREF(resp);
 
 /* "execute" isn't a string */
-resp = qmp("{ 'execute': true }");
+resp = qtest_qmp(qts, "{ 'execute': true }");
 g_assert_cmpstr(get_error_class(resp), ==, "GenericError");
 QDECREF(resp);
 
 /* "arguments" isn't a dictionary */
-resp = qmp("{ 'execute': 'no-such-cmd', 'arguments': [] }");
+resp = qtest_qmp(qts, "{ 'execute': 'no-such-cmd', 'arguments': [] }");
 g_assert_cmpstr(get_error_class(resp), ==, "GenericError");
 QDECREF(resp);
 
 /* extra key */
-resp = qmp("{ 'execute': 'no-such-cmd', 'extra': true }");
+resp = qtest_qmp(qts, "{ 'execute': 'no-such-cmd', 'extra': true }");
 g_assert_cmpstr(get_error_class(resp), ==, "GenericError");
 QDECREF(resp);
 }
@@ -75,11 +75,12 @@ static void test_qmp_protocol(void)
 {
 QDict *resp, *q, *ret;
 QList *capabilities;
+QTestState *qts;
 
-global_qtest = qtest_init_without_qmp_handshake(common_args);
+qts = qtest_init_without_qmp_handshake(common_args);
 
 /* Test greeting */
-resp = qmp_receive();
+resp = qtest_qmp_receive(qts);
 q = qdict_get_qdict(resp, "QMP");
 g_assert(q);
 test_version(qdict_get(q, "version"));
@@ -88,46 +89,46 @@ static void test_qmp_protocol(void)
 QDECREF(resp);
 
 /* Test valid command before handshake */
-resp = qmp("{ 'execute': 'query-version' }");
+resp = qtest_qmp(qts, "{ 'execute': 'query-version' }");
 g_assert_cmpstr(get_error_class(resp), ==, "CommandNotFound");
 QDECREF(resp);
 
 /* Test malformed commands before handshake */
-test_malformed();
+test_malformed(qts);
 
 /* Test handshake */
-resp = qmp("{ 'execute': 'qmp_capabilities' }");
+resp = qtest_qmp(qts, "{ 'execute': 'qmp_capabilities' }");
 ret = qdict_get_qdict(resp, "return");
 g_assert(ret && !qdict_size(ret));
 QDECREF(resp);
 
 /* Test repeated handshake */
-resp = qmp("{ 'execute': 'qmp_capabilities' }");
+resp = qtest_qmp(qts, "{ 'execute': 'qmp_capabilities' }");
 g_assert_cmpstr(get_error_class(resp), ==, "CommandNotFound");
 QDECREF(resp);
 
 /* Test valid command */
-resp = qmp("{ 'execute': 'query-version' }");
+resp = qtest_qmp(qts, "{ 'execute': 'query-version' }");
 test_version(qdict_get(resp, "return"));
 QDECREF(resp);
 
 /* Test malformed commands */
-test_malformed();
+test_malformed(qts);
 
 /* Test 'id' */
-resp = qmp("{ 'execute': 'query-name', 'id': 'cookie#1' }");
+resp = qtest_qmp(qts, "{ 'execute': 'query-name', 'id': 'cookie#1' }");
 ret = qdict_get_qdict(resp, "return");
 g_assert(ret);
 g_assert_cmpstr(qdict_get_try_str(resp, "id"), ==, "cookie#1");
 QDECREF(resp);
 
 /* Test command failure with 'id' */
-resp = qmp("{ 'execute': 'human-monitor-command', 'id': 2 }");
+resp = qtest_qmp(qts, "{ 'execute': 'human-monitor-command', 'id': 2 }");
 g_assert_cmpstr(get_error_class(resp), ==, "GenericError");
 g_assert_cmpint(qdict_get_int(resp, "id"), ==, 2);
 QDECREF(resp);
 
-qtest_end();
+qtest_quit(qts);
 }
 
 static int query_error_class(const char *cmd)
-- 
1.8.3.1

[Qemu-devel] [PATCH 03/14] libqos: Track QTestState with QPCIBus

[Thomas Huth]

From: Eric Blake 

When initializing a QPCIBus, track which QTestState the bus is
associated with (so that a later patch can then explicitly use
that test state for all communication on the bus, rather than
blindly relying on global_qtest).  Update the initialization
functions to take another parameter, and update all callers to
pass in state (for now, most callers get away with passing the
current global_qtest as the current state, although this required
fixing the order of initialization to ensure qtest_start() is
called before qpci_init*() in rtl8139-test, and provided an
opportunity to pass in the allocator in e1000e-test).

Touch up some allocations to use g_new0() rather than g_malloc()
while in the area, and simplify some code (all implementations
of QOSOps provide a .init_allocator() that never fails).

Signed-off-by: Eric Blake 
Reviewed-by: John Snow 
Reviewed-by: Thomas Huth 
[thuth: Removed hunk from vhost-user-test.c that is not required anymore,
 and fixed conflict in qtest_vboot()]
Signed-off-by: Thomas Huth 
---
 tests/ahci-test.c |  2 +-
 tests/e1000e-test.c   |  6 +++---
 tests/i440fx-test.c   |  2 +-
 tests/ide-test.c  |  2 +-
 tests/libqos/ahci.c   |  4 ++--
 tests/libqos/ahci.h   |  2 +-
 tests/libqos/libqos.c | 10 +++---
 tests/libqos/libqos.h |  2 +-
 tests/libqos/pci-pc.c |  7 ---
 tests/libqos/pci-pc.h |  2 +-
 tests/libqos/pci-spapr.c  |  7 ---
 tests/libqos/pci-spapr.h  |  2 +-
 tests/libqos/pci.h|  1 +
 tests/q35-test.c  |  4 ++--
 tests/rtl8139-test.c  |  5 +++--
 tests/tco-test.c  |  2 +-
 tests/usb-hcd-ehci-test.c |  2 +-
 tests/vhost-user-test.c   |  2 +-
 18 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/tests/ahci-test.c b/tests/ahci-test.c
index 3934e62..d9c99b7 100644
--- a/tests/ahci-test.c
+++ b/tests/ahci-test.c
@@ -160,7 +160,7 @@ static AHCIQState *ahci_vboot(const char *cli, va_list ap)
 alloc_set_flags(s->parent->alloc, ALLOC_LEAK_ASSERT);
 
 /* Verify that we have an AHCI device present. */
-s->dev = get_ahci_device(>fingerprint);
+s->dev = get_ahci_device(s->parent->qts, >fingerprint);
 
 return s;
 }
diff --git a/tests/e1000e-test.c b/tests/e1000e-test.c
index c612dc6..d8085d9 100644
--- a/tests/e1000e-test.c
+++ b/tests/e1000e-test.c
@@ -392,12 +392,12 @@ static void data_test_init(e1000e_device *d)
 qtest_start(cmdline);
 g_free(cmdline);
 
-test_bus = qpci_init_pc(NULL);
-g_assert_nonnull(test_bus);
-
 test_alloc = pc_alloc_init();
 g_assert_nonnull(test_alloc);
 
+test_bus = qpci_init_pc(global_qtest, test_alloc);
+g_assert_nonnull(test_bus);
+
 e1000e_device_init(test_bus, d);
 }
 
diff --git a/tests/i440fx-test.c b/tests/i440fx-test.c
index e9d05c8..4390e55 100644
--- a/tests/i440fx-test.c
+++ b/tests/i440fx-test.c
@@ -38,7 +38,7 @@ static QPCIBus *test_start_get_bus(const TestData *s)
 cmdline = g_strdup_printf("-smp %d", s->num_cpus);
 qtest_start(cmdline);
 g_free(cmdline);
-return qpci_init_pc(NULL);
+return qpci_init_pc(global_qtest, NULL);
 }
 
 static void test_i440fx_defaults(gconstpointer opaque)
diff --git a/tests/ide-test.c b/tests/ide-test.c
index aa9de06..b2237b6 100644
--- a/tests/ide-test.c
+++ b/tests/ide-test.c
@@ -143,7 +143,7 @@ static QPCIDevice *get_pci_device(QPCIBar *bmdma_bar, 
QPCIBar *ide_bar)
 uint16_t vendor_id, device_id;
 
 if (!pcibus) {
-pcibus = qpci_init_pc(NULL);
+pcibus = qpci_init_pc(global_qtest, NULL);
 }
 
 /* Find PCI device and verify it's the right one */
diff --git a/tests/libqos/ahci.c b/tests/libqos/ahci.c
index 13c0749..40c532e 100644
--- a/tests/libqos/ahci.c
+++ b/tests/libqos/ahci.c
@@ -123,13 +123,13 @@ bool is_atapi(AHCIQState *ahci, uint8_t port)
 /**
  * Locate, verify, and return a handle to the AHCI device.
  */
-QPCIDevice *get_ahci_device(uint32_t *fingerprint)
+QPCIDevice *get_ahci_device(QTestState *qts, uint32_t *fingerprint)
 {
 QPCIDevice *ahci;
 uint32_t ahci_fingerprint;
 QPCIBus *pcibus;
 
-pcibus = qpci_init_pc(NULL);
+pcibus = qpci_init_pc(qts, NULL);
 
 /* Find the AHCI PCI device and verify it's the right one. */
 ahci = qpci_device_find(pcibus, QPCI_DEVFN(0x1F, 0x02));
diff --git a/tests/libqos/ahci.h b/tests/libqos/ahci.h
index 5f9627b..715ca1e 100644
--- a/tests/libqos/ahci.h
+++ b/tests/libqos/ahci.h
@@ -571,7 +571,7 @@ void ahci_free(AHCIQState *ahci, uint64_t addr);
 void ahci_clean_mem(AHCIQState *ahci);
 
 /* Device management */
-QPCIDevice *get_ahci_device(uint32_t *fingerprint);
+QPCIDevice *get_ahci_device(QTestState *qts, uint32_t *fingerprint);
 void free_ahci_device(QPCIDevice *dev);
 void ahci_pci_enable(AHCIQState *ahci);
 void start_ahci_device(AHCIQState *ahci);
diff --git a/tests/libqos/libqos.c b/tests/libqos/libqos.c
index 

[Qemu-devel] [PATCH 05/14] libqos: Use explicit QTestState for rtas operations

[Thomas Huth]

From: Eric Blake 

Drop one more client of global_qtest by teaching all rtas test
functionality to pass in an explicit QTestState, adjusting all
callers.

Signed-off-by: Eric Blake 
Reviewed-by: Thomas Huth 
[thuth: Use nicer indentation in rtas.h]
Signed-off-by: Thomas Huth 
---
 tests/libqos/pci-spapr.c | 18 --
 tests/libqos/rtas.c  | 36 
 tests/libqos/rtas.h  | 12 +++-
 tests/rtas-test.c|  2 +-
 4 files changed, 40 insertions(+), 28 deletions(-)

diff --git a/tests/libqos/pci-spapr.c b/tests/libqos/pci-spapr.c
index ef52fcb..c0f7e6d 100644
--- a/tests/libqos/pci-spapr.c
+++ b/tests/libqos/pci-spapr.c
@@ -108,21 +108,24 @@ static uint8_t qpci_spapr_config_readb(QPCIBus *bus, int 
devfn, uint8_t offset)
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 uint32_t config_addr = (devfn << 8) | offset;
-return qrtas_ibm_read_pci_config(s->alloc, s->buid, config_addr, 1);
+return qrtas_ibm_read_pci_config(bus->qts, s->alloc, s->buid,
+ config_addr, 1);
 }
 
 static uint16_t qpci_spapr_config_readw(QPCIBus *bus, int devfn, uint8_t 
offset)
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 uint32_t config_addr = (devfn << 8) | offset;
-return qrtas_ibm_read_pci_config(s->alloc, s->buid, config_addr, 2);
+return qrtas_ibm_read_pci_config(bus->qts, s->alloc, s->buid,
+ config_addr, 2);
 }
 
 static uint32_t qpci_spapr_config_readl(QPCIBus *bus, int devfn, uint8_t 
offset)
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 uint32_t config_addr = (devfn << 8) | offset;
-return qrtas_ibm_read_pci_config(s->alloc, s->buid, config_addr, 4);
+return qrtas_ibm_read_pci_config(bus->qts, s->alloc, s->buid,
+ config_addr, 4);
 }
 
 static void qpci_spapr_config_writeb(QPCIBus *bus, int devfn, uint8_t offset,
@@ -130,7 +133,8 @@ static void qpci_spapr_config_writeb(QPCIBus *bus, int 
devfn, uint8_t offset,
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 uint32_t config_addr = (devfn << 8) | offset;
-qrtas_ibm_write_pci_config(s->alloc, s->buid, config_addr, 1, value);
+qrtas_ibm_write_pci_config(bus->qts, s->alloc, s->buid,
+   config_addr, 1, value);
 }
 
 static void qpci_spapr_config_writew(QPCIBus *bus, int devfn, uint8_t offset,
@@ -138,7 +142,8 @@ static void qpci_spapr_config_writew(QPCIBus *bus, int 
devfn, uint8_t offset,
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 uint32_t config_addr = (devfn << 8) | offset;
-qrtas_ibm_write_pci_config(s->alloc, s->buid, config_addr, 2, value);
+qrtas_ibm_write_pci_config(bus->qts, s->alloc, s->buid,
+   config_addr, 2, value);
 }
 
 static void qpci_spapr_config_writel(QPCIBus *bus, int devfn, uint8_t offset,
@@ -146,7 +151,8 @@ static void qpci_spapr_config_writel(QPCIBus *bus, int 
devfn, uint8_t offset,
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 uint32_t config_addr = (devfn << 8) | offset;
-qrtas_ibm_write_pci_config(s->alloc, s->buid, config_addr, 4, value);
+qrtas_ibm_write_pci_config(bus->qts, s->alloc, s->buid,
+   config_addr, 4, value);
 }
 
 #define SPAPR_PCI_BASE   (1ULL << 45)
diff --git a/tests/libqos/rtas.c b/tests/libqos/rtas.c
index 0269803..d81ff42 100644
--- a/tests/libqos/rtas.c
+++ b/tests/libqos/rtas.c
@@ -7,26 +7,28 @@
 #include "libqtest.h"
 #include "libqos/rtas.h"
 
-static void qrtas_copy_args(uint64_t target_args, uint32_t nargs,
-uint32_t *args)
+static void qrtas_copy_args(QTestState *qts, uint64_t target_args,
+uint32_t nargs, uint32_t *args)
 {
 int i;
 
 for (i = 0; i < nargs; i++) {
-writel(target_args + i * sizeof(uint32_t), args[i]);
+qtest_writel(qts, target_args + i * sizeof(uint32_t), args[i]);
 }
 }
 
-static void qrtas_copy_ret(uint64_t target_ret, uint32_t nret, uint32_t *ret)
+static void qrtas_copy_ret(QTestState *qts, uint64_t target_ret,
+   uint32_t nret, uint32_t *ret)
 {
 int i;
 
 for (i = 0; i < nret; i++) {
-ret[i] = readl(target_ret + i * sizeof(uint32_t));
+ret[i] = qtest_readl(qts, target_ret + i * sizeof(uint32_t));
 }
 }
 
-static uint64_t qrtas_call(QGuestAllocator *alloc, const char *name,
+static uint64_t qrtas_call(QTestState *qts, QGuestAllocator *alloc,
+   const char *name,
uint32_t nargs, uint32_t *args,
uint32_t nret, uint32_t *ret)
 {
@@ -36,10 +38,9 @@ static uint64_t qrtas_call(QGuestAllocator *alloc, const 
char *name,
 target_args = guest_alloc(alloc, nargs * 

[Qemu-devel] [PATCH 08/14] libqos: Use explicit QTestState for remaining libqos operations

[Thomas Huth]

From: Eric Blake 

Drop one more client of global_qtest by teaching all remaining
libqos stragglers to pass in an explicit QTestState.  Change the
setting of global_qtest from being implicit in libqos' call to
qtest_start() to instead be explicit in all clients that are
still relying on global_qtest.

Note that qmp_execute() can be greatly simplified in the process,
and that we also get rid of interpolation of a JSON string into a
temporary variable when qtest_qmp() can do it more reliably.

Signed-off-by: Eric Blake 
Acked-by: Greg Kurz 
Reviewed-by: John Snow 
Signed-off-by: Thomas Huth 
---
 tests/ahci-test.c |  1 +
 tests/ivshmem-test.c  |  1 +
 tests/libqos/libqos-pc.c  |  2 +-
 tests/libqos/libqos.c | 30 ++
 tests/megasas-test.c  |  5 -
 tests/rtas-test.c |  1 +
 tests/usb-hcd-uhci-test.c |  1 +
 tests/virtio-9p-test.c|  1 +
 tests/virtio-blk-test.c   |  1 +
 tests/virtio-net-test.c   | 15 +--
 tests/virtio-scsi-test.c  | 16 +---
 11 files changed, 39 insertions(+), 35 deletions(-)

diff --git a/tests/ahci-test.c b/tests/ahci-test.c
index d9c99b7..f2a3926 100644
--- a/tests/ahci-test.c
+++ b/tests/ahci-test.c
@@ -157,6 +157,7 @@ static AHCIQState *ahci_vboot(const char *cli, va_list ap)
 
 s = g_new0(AHCIQState, 1);
 s->parent = qtest_pc_vboot(cli, ap);
+global_qtest = s->parent->qts;
 alloc_set_flags(s->parent->alloc, ALLOC_LEAK_ASSERT);
 
 /* Verify that we have an AHCI device present. */
diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
index 3776342..8af16ee 100644
--- a/tests/ivshmem-test.c
+++ b/tests/ivshmem-test.c
@@ -131,6 +131,7 @@ static void setup_vm_cmd(IVState *s, const char *cmd, bool 
msix)
 g_printerr("ivshmem-test tests are only available on x86 or ppc64\n");
 exit(EXIT_FAILURE);
 }
+global_qtest = s->qs->qts;
 s->dev = get_device(s->qs->pcibus);
 
 s->reg_bar = qpci_iomap(s->dev, 0, );
diff --git a/tests/libqos/libqos-pc.c b/tests/libqos/libqos-pc.c
index b554758..a9c1ace 100644
--- a/tests/libqos/libqos-pc.c
+++ b/tests/libqos/libqos-pc.c
@@ -25,7 +25,7 @@ QOSState *qtest_pc_boot(const char *cmdline_fmt, ...)
 qs = qtest_vboot(_ops, cmdline_fmt, ap);
 va_end(ap);
 
-qtest_irq_intercept_in(global_qtest, "ioapic");
+qtest_irq_intercept_in(qs->qts, "ioapic");
 
 return qs;
 }
diff --git a/tests/libqos/libqos.c b/tests/libqos/libqos.c
index 40018b9..9798e1d 100644
--- a/tests/libqos/libqos.c
+++ b/tests/libqos/libqos.c
@@ -20,7 +20,7 @@ QOSState *qtest_vboot(QOSOps *ops, const char *cmdline_fmt, 
va_list ap)
 QOSState *qs = g_new0(QOSState, 1);
 
 cmdline = g_strdup_vprintf(cmdline_fmt, ap);
-qs->qts = qtest_start(cmdline);
+qs->qts = qtest_init(cmdline);
 qs->ops = ops;
 if (ops) {
 qs->alloc = ops->init_allocator(qs->qts, ALLOC_NO_FLAGS);
@@ -80,29 +80,21 @@ void set_context(QOSState *s)
 global_qtest = s->qts;
 }
 
-static QDict *qmp_execute(const char *command)
+static QDict *qmp_execute(QTestState *qts, const char *command)
 {
-char *fmt;
-QDict *rsp;
-
-fmt = g_strdup_printf("{ 'execute': '%s' }", command);
-rsp = qmp(fmt);
-g_free(fmt);
-
-return rsp;
+return qtest_qmp(qts, "{ 'execute': %s }", command);
 }
 
 void migrate(QOSState *from, QOSState *to, const char *uri)
 {
 const char *st;
-char *s;
 QDict *rsp, *sub;
 bool running;
 
 set_context(from);
 
 /* Is the machine currently running? */
-rsp = qmp_execute("query-status");
+rsp = qmp_execute(from->qts, "query-status");
 g_assert(qdict_haskey(rsp, "return"));
 sub = qdict_get_qdict(rsp, "return");
 g_assert(qdict_haskey(sub, "running"));
@@ -110,30 +102,28 @@ void migrate(QOSState *from, QOSState *to, const char 
*uri)
 QDECREF(rsp);
 
 /* Issue the migrate command. */
-s = g_strdup_printf("{ 'execute': 'migrate',"
-"'arguments': { 'uri': '%s' } }",
-uri);
-rsp = qmp(s);
-g_free(s);
+rsp = qtest_qmp(from->qts,
+"{ 'execute': 'migrate', 'arguments': { 'uri': %s }}",
+uri);
 g_assert(qdict_haskey(rsp, "return"));
 QDECREF(rsp);
 
 /* Wait for STOP event, but only if we were running: */
 if (running) {
-qmp_eventwait("STOP");
+qtest_qmp_eventwait(from->qts, "STOP");
 }
 
 /* If we were running, we can wait for an event. */
 if (running) {
 migrate_allocator(from->alloc, to->alloc);
 set_context(to);
-qmp_eventwait("RESUME");
+qtest_qmp_eventwait(to->qts, "RESUME");
 return;
 }
 
 /* Otherwise, we need to wait: poll until migration is completed. */
 while (1) {
-rsp = qmp_execute("query-migrate");
+rsp = qmp_execute(from->qts, "query-migrate");
  

Re: [Qemu-devel] [PATCH v5 10/14] pci: Add support for Designware IP block

[Andrey Smirnov]

On Thu, Feb 8, 2018 at 9:45 AM, Michael S. Tsirkin  wrote:
> On Tue, Feb 06, 2018 at 08:24:34PM -0800, Andrey Smirnov wrote:
>> Add code needed to get a functional PCI subsytem when using in
>> conjunction with upstream Linux guest (4.13+). Tested to work against
>> "e1000e" (network adapter, using MSI interrupts) as well as
>> "usb-ehci" (USB controller, using legacy PCI interrupts).
>>
>> Based on "i.MX6 Applications Processor Reference Manual" (Document
>> Number: IMX6DQRM Rev. 4) as well as corresponding dirver in Linux
>> kernel (circa 4.13 - 4.16 found in drivers/pci/dwc/*)
>>
>> Cc: Peter Maydell 
>> Cc: Jason Wang 
>> Cc: Philippe Mathieu-Daudé 
>> Cc: Marcel Apfelbaum 
>> Cc: Michael S. Tsirkin 
>> Cc: qemu-devel@nongnu.org
>> Cc: qemu-...@nongnu.org
>> Cc: yurov...@gmail.com
>> Signed-off-by: Andrey Smirnov 
>> ---
>>  default-configs/arm-softmmu.mak  |   2 +
>>  hw/pci-host/Makefile.objs|   2 +
>>  hw/pci-host/designware.c | 759 
>> +++
>>  include/hw/pci-host/designware.h |  97 +
>>  include/hw/pci/pci_ids.h |   2 +
>>  5 files changed, 862 insertions(+)
>>  create mode 100644 hw/pci-host/designware.c
>>  create mode 100644 include/hw/pci-host/designware.h
>>
>> diff --git a/default-configs/arm-softmmu.mak 
>> b/default-configs/arm-softmmu.mak
>> index b0d6e65038..0c5ae914ed 100644
>> --- a/default-configs/arm-softmmu.mak
>> +++ b/default-configs/arm-softmmu.mak
>> @@ -132,3 +132,5 @@ CONFIG_GPIO_KEY=y
>>  CONFIG_MSF2=y
>>  CONFIG_FW_CFG_DMA=y
>>  CONFIG_XILINX_AXI=y
>> +CONFIG_PCI_DESIGNWARE=y
>> +
>> diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs
>> index 4b69f737b5..6d6597c065 100644
>> --- a/hw/pci-host/Makefile.objs
>> +++ b/hw/pci-host/Makefile.objs
>> @@ -17,3 +17,5 @@ common-obj-$(CONFIG_PCI_PIIX) += piix.o
>>  common-obj-$(CONFIG_PCI_Q35) += q35.o
>>  common-obj-$(CONFIG_PCI_GENERIC) += gpex.o
>>  common-obj-$(CONFIG_PCI_XILINX) += xilinx-pcie.o
>> +
>> +common-obj-$(CONFIG_PCI_DESIGNWARE) += designware.o
>> diff --git a/hw/pci-host/designware.c b/hw/pci-host/designware.c
>> new file mode 100644
>> index 00..551a881af0
>> --- /dev/null
>> +++ b/hw/pci-host/designware.c
>> @@ -0,0 +1,759 @@
>> +/*
>> + * Copyright (c) 2018, Impinj, Inc.
>> + *
>> + * Designware PCIe IP block emulation
>> + *
>> + * This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2 of the License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with this library; if not, see
>> + * .
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "qapi/error.h"
>> +#include "hw/pci/msi.h"
>> +#include "hw/pci/pci_bridge.h"
>> +#include "hw/pci/pci_host.h"
>> +#include "hw/pci/pcie_port.h"
>> +#include "hw/pci-host/designware.h"
>> +
>> +#define PCIE_PORT_LINK_CONTROL  0x710
>> +
>> +#define PCIE_PHY_DEBUG_R1   0x72C
>> +#define PCIE_PHY_DEBUG_R1_XMLH_LINK_UP  BIT(4)
>> +
>> +#define PCIE_LINK_WIDTH_SPEED_CONTROL   0x80C
>> +#define PORT_LOGIC_SPEED_CHANGE (0x1 << 17)
>> +
>> +#define PCIE_MSI_ADDR_LO0x820
>> +#define PCIE_MSI_ADDR_HI0x824
>> +#define PCIE_MSI_INTR0_ENABLE   0x828
>> +#define PCIE_MSI_INTR0_MASK 0x82C
>> +#define PCIE_MSI_INTR0_STATUS   0x830
>> +
>> +#define PCIE_ATU_VIEWPORT   0x900
>> +#define PCIE_ATU_REGION_INBOUND (0x1 << 31)
>> +#define PCIE_ATU_REGION_OUTBOUND(0x0 << 31)
>> +#define PCIE_ATU_REGION_INDEX2  (0x2 << 0)
>> +#define PCIE_ATU_REGION_INDEX1  (0x1 << 0)
>> +#define PCIE_ATU_REGION_INDEX0  (0x0 << 0)
>> +#define PCIE_ATU_CR10x904
>> +#define PCIE_ATU_TYPE_MEM   (0x0 << 0)
>> +#define PCIE_ATU_TYPE_IO(0x2 << 0)
>> +#define PCIE_ATU_TYPE_CFG0  (0x4 << 0)
>> +#define PCIE_ATU_TYPE_CFG1  (0x5 << 0)
>> +#define PCIE_ATU_CR20x908
>> +#define PCIE_ATU_ENABLE (0x1 << 31)
>> +#define PCIE_ATU_BAR_MODE_ENABLE(0x1 << 30)
>> +#define PCIE_ATU_LOWER_BASE 0x90C
>> +#define PCIE_ATU_UPPER_BASE 0x910
>> +#define PCIE_ATU_LIMIT  0x914
>> +#define PCIE_ATU_LOWER_TARGET   0x918
>> +#define PCIE_ATU_BUS(x) (((x) >> 

[Qemu-devel] [PATCH 01/14] tests: Clean up wait for event

[Thomas Huth]

From: Markus Armbruster 

We still use hacks like qmp("") to wait for an event, even though we
have qmp_eventwait() since commit 8fe941f, and qmp_eventwait_ref()
since commit 7ffe312.  Both commits neglected to convert all the
existing hacks.  Make up what they missed.

Bonus: gets rid of empty format strings.  A step towards compile-time
format string checking without triggering -Wformat-zero-length.

Signed-off-by: Markus Armbruster 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Eric Blake 
[thuth: dropped the hunks from the usb tests - not needed anymore]
Signed-off-by: Thomas Huth 
---
 tests/boot-order-test.c |  2 +-
 tests/libqos/pci-pc.c   |  6 +-
 tests/tco-test.c|  3 +--
 tests/wdt_ib700-test.c  | 35 ++-
 4 files changed, 13 insertions(+), 33 deletions(-)

diff --git a/tests/boot-order-test.c b/tests/boot-order-test.c
index 60c5545..508469a 100644
--- a/tests/boot-order-test.c
+++ b/tests/boot-order-test.c
@@ -41,7 +41,7 @@ static void test_a_boot_order(const char *machine,
  * system_reset only requests reset.  We get a RESET event after
  * the actual reset completes.  Need to wait for that.
  */
-qmp_discard_response("");   /* HACK: wait for event */
+qmp_eventwait("RESET");
 actual = read_boot_order();
 g_assert_cmphex(actual, ==, expected_reboot);
 qtest_quit(global_qtest);
diff --git a/tests/libqos/pci-pc.c b/tests/libqos/pci-pc.c
index ded1c54..02ce499 100644
--- a/tests/libqos/pci-pc.c
+++ b/tests/libqos/pci-pc.c
@@ -173,9 +173,5 @@ void qpci_unplug_acpi_device_test(const char *id, uint8_t 
slot)
 
 outb(ACPI_PCIHP_ADDR + PCI_EJ_BASE, 1 << slot);
 
-response = qmp("");
-g_assert(response);
-g_assert(qdict_haskey(response, "event"));
-g_assert(!strcmp(qdict_get_str(response, "event"), "DEVICE_DELETED"));
-QDECREF(response);
+qmp_eventwait("DEVICE_DELETED");
 }
diff --git a/tests/tco-test.c b/tests/tco-test.c
index 2616d33..bed66a3 100644
--- a/tests/tco-test.c
+++ b/tests/tco-test.c
@@ -235,9 +235,8 @@ static void test_tco_max_timeout(void)
 
 static QDict *get_watchdog_action(void)
 {
-QDict *ev = qmp("");
+QDict *ev = qmp_eventwait_ref("WATCHDOG");
 QDict *data;
-g_assert(!strcmp(qdict_get_str(ev, "event"), "WATCHDOG"));
 
 data = qdict_get_qdict(ev, "data");
 QINCREF(data);
diff --git a/tests/wdt_ib700-test.c b/tests/wdt_ib700-test.c
index 49f4f0c..4fc8eea 100644
--- a/tests/wdt_ib700-test.c
+++ b/tests/wdt_ib700-test.c
@@ -18,26 +18,10 @@ static void qmp_check_no_event(void)
 QDECREF(resp);
 }
 
-static QDict *qmp_get_event(const char *name)
-{
-QDict *event = qmp("");
-QDict *data;
-g_assert(qdict_haskey(event, "event"));
-g_assert(!strcmp(qdict_get_str(event, "event"), name));
-
-if (qdict_haskey(event, "data")) {
-data = qdict_get_qdict(event, "data");
-QINCREF(data);
-} else {
-data = NULL;
-}
-
-QDECREF(event);
-return data;
-}
-
 static QDict *ib700_program_and_wait(QTestState *s)
 {
+QDict *event, *data;
+
 clock_step(NANOSECONDS_PER_SECOND * 40);
 qmp_check_no_event();
 
@@ -61,7 +45,11 @@ static QDict *ib700_program_and_wait(QTestState *s)
 clock_step(3 * NANOSECONDS_PER_SECOND);
 qmp_check_no_event();
 clock_step(2 * NANOSECONDS_PER_SECOND);
-return qmp_get_event("WATCHDOG");
+event = qmp_eventwait_ref("WATCHDOG");
+data = qdict_get_qdict(event, "data");
+QINCREF(data);
+QDECREF(event);
+return data;
 }
 
 
@@ -73,8 +61,7 @@ static void ib700_pause(void)
 d = ib700_program_and_wait(s);
 g_assert(!strcmp(qdict_get_str(d, "action"), "pause"));
 QDECREF(d);
-d = qmp_get_event("STOP");
-QDECREF(d);
+qmp_eventwait("STOP");
 qtest_end();
 }
 
@@ -86,8 +73,7 @@ static void ib700_reset(void)
 d = ib700_program_and_wait(s);
 g_assert(!strcmp(qdict_get_str(d, "action"), "reset"));
 QDECREF(d);
-d = qmp_get_event("RESET");
-QDECREF(d);
+qmp_eventwait("RESET");
 qtest_end();
 }
 
@@ -99,8 +85,7 @@ static void ib700_shutdown(void)
 d = ib700_program_and_wait(s);
 g_assert(!strcmp(qdict_get_str(d, "action"), "reset"));
 QDECREF(d);
-d = qmp_get_event("SHUTDOWN");
-QDECREF(d);
+qmp_eventwait("SHUTDOWN");
 qtest_end();
 }
 
-- 
1.8.3.1

[Qemu-devel] [PATCH 06/14] libqos: Use explicit QTestState for i2c operations

[Thomas Huth]

From: Eric Blake 

Drop one more client of global_qtest by teaching all i2c test
functionality to pass in an explicit QTestState, adjusting all
callers.

Signed-off-by: Eric Blake 
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/ds1338-test.c |  6 ++---
 tests/libqos/i2c-imx.c  | 67 +
 tests/libqos/i2c-omap.c | 45 +
 tests/libqos/i2c.h  |  7 --
 tests/tmp105-test.c |  6 ++---
 5 files changed, 66 insertions(+), 65 deletions(-)

diff --git a/tests/ds1338-test.c b/tests/ds1338-test.c
index 26968bc..742dad9 100644
--- a/tests/ds1338-test.c
+++ b/tests/ds1338-test.c
@@ -61,16 +61,14 @@ int main(int argc, char **argv)
 g_test_init(, , NULL);
 
 s = qtest_start("-display none -machine imx25-pdk");
-i2c = imx_i2c_create(IMX25_I2C_0_BASE);
+i2c = imx_i2c_create(s, IMX25_I2C_0_BASE);
 addr = DS1338_ADDR;
 
 qtest_add_func("/ds1338/tx-rx", send_and_receive);
 
 ret = g_test_run();
 
-if (s) {
-qtest_quit(s);
-}
+qtest_quit(s);
 g_free(i2c);
 
 return ret;
diff --git a/tests/libqos/i2c-imx.c b/tests/libqos/i2c-imx.c
index 1c4b431..0945f2e 100644
--- a/tests/libqos/i2c-imx.c
+++ b/tests/libqos/i2c-imx.c
@@ -40,8 +40,8 @@ typedef struct IMXI2C {
 static void imx_i2c_set_slave_addr(IMXI2C *s, uint8_t addr,
enum IMXI2CDirection direction)
 {
-writeb(s->addr + I2DR_ADDR, (addr << 1) |
-   (direction == IMX_I2C_READ ? 1 : 0));
+qtest_writeb(s->parent.qts, s->addr + I2DR_ADDR,
+ (addr << 1) | (direction == IMX_I2C_READ ? 1 : 0));
 }
 
 static void imx_i2c_send(I2CAdapter *i2c, uint8_t addr,
@@ -63,35 +63,35 @@ static void imx_i2c_send(I2CAdapter *i2c, uint8_t addr,
I2CR_MTX |
I2CR_TXAK;
 
-writeb(s->addr + I2CR_ADDR, data);
-status = readb(s->addr + I2SR_ADDR);
+qtest_writeb(i2c->qts, s->addr + I2CR_ADDR, data);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IBB) != 0);
 
 /* set the slave address */
 imx_i2c_set_slave_addr(s, addr, IMX_I2C_WRITE);
-status = readb(s->addr + I2SR_ADDR);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IIF) != 0);
 g_assert((status & I2SR_RXAK) == 0);
 
 /* ack the interrupt */
-writeb(s->addr + I2SR_ADDR, 0);
-status = readb(s->addr + I2SR_ADDR);
+qtest_writeb(i2c->qts, s->addr + I2SR_ADDR, 0);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IIF) == 0);
 
 while (size < len) {
 /* check we are still busy */
-status = readb(s->addr + I2SR_ADDR);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IBB) != 0);
 
 /* write the data */
-writeb(s->addr + I2DR_ADDR, buf[size]);
-status = readb(s->addr + I2SR_ADDR);
+qtest_writeb(i2c->qts, s->addr + I2DR_ADDR, buf[size]);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IIF) != 0);
 g_assert((status & I2SR_RXAK) == 0);
 
 /* ack the interrupt */
-writeb(s->addr + I2SR_ADDR, 0);
-status = readb(s->addr + I2SR_ADDR);
+qtest_writeb(i2c->qts, s->addr + I2SR_ADDR, 0);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IIF) == 0);
 
 size++;
@@ -99,8 +99,8 @@ static void imx_i2c_send(I2CAdapter *i2c, uint8_t addr,
 
 /* release the bus */
 data &= ~(I2CR_MSTA | I2CR_MTX);
-writeb(s->addr + I2CR_ADDR, data);
-status = readb(s->addr + I2SR_ADDR);
+qtest_writeb(i2c->qts, s->addr + I2CR_ADDR, data);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IBB) == 0);
 }
 
@@ -123,19 +123,19 @@ static void imx_i2c_recv(I2CAdapter *i2c, uint8_t addr,
I2CR_MTX |
I2CR_TXAK;
 
-writeb(s->addr + I2CR_ADDR, data);
-status = readb(s->addr + I2SR_ADDR);
+qtest_writeb(i2c->qts, s->addr + I2CR_ADDR, data);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IBB) != 0);
 
 /* set the slave address */
 imx_i2c_set_slave_addr(s, addr, IMX_I2C_READ);
-status = readb(s->addr + I2SR_ADDR);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IIF) != 0);
 g_assert((status & I2SR_RXAK) == 0);
 
 /* ack the interrupt */
-writeb(s->addr + I2SR_ADDR, 0);
-status = readb(s->addr + I2SR_ADDR);
+qtest_writeb(i2c->qts, s->addr + I2SR_ADDR, 0);
+status = qtest_readb(i2c->qts, s->addr + I2SR_ADDR);
 g_assert((status & I2SR_IIF) == 0);
 
 /* set the bus for read */
@@ -144,23 +144,23 @@ static void imx_i2c_recv(I2CAdapter *i2c, uint8_t addr,
 if (len != 1) {
 data 

[Qemu-devel] [PATCH 07/14] libqos: Use explicit QTestState for ahci operations

[Thomas Huth]

From: Eric Blake 

Drop one more client of global_qtest by teaching all ahci test
functionality to pass in an explicit QTestState.  The state was
already available, so no callers had to be adjusted.

Signed-off-by: Eric Blake 
Reviewed-by: John Snow 
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/libqos/ahci.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/tests/libqos/ahci.c b/tests/libqos/ahci.c
index 40c532e..bc201d7 100644
--- a/tests/libqos/ahci.c
+++ b/tests/libqos/ahci.c
@@ -283,7 +283,8 @@ void ahci_hba_enable(AHCIQState *ahci)
 /* Allocate Memory for the Command List Buffer & FIS Buffer */
 /* PxCLB space ... 0x20 per command, as in 4.2.2 p 36 */
 ahci->port[i].clb = ahci_alloc(ahci, num_cmd_slots * 0x20);
-qmemset(ahci->port[i].clb, 0x00, num_cmd_slots * 0x20);
+qtest_memset(ahci->parent->qts, ahci->port[i].clb, 0x00,
+ num_cmd_slots * 0x20);
 g_test_message("CLB: 0x%08" PRIx64, ahci->port[i].clb);
 ahci_px_wreg(ahci, i, AHCI_PX_CLB, ahci->port[i].clb);
 g_assert_cmphex(ahci->port[i].clb, ==,
@@ -291,7 +292,7 @@ void ahci_hba_enable(AHCIQState *ahci)
 
 /* PxFB space ... 0x100, as in 4.2.1 p 35 */
 ahci->port[i].fb = ahci_alloc(ahci, 0x100);
-qmemset(ahci->port[i].fb, 0x00, 0x100);
+qtest_memset(ahci->parent->qts, ahci->port[i].fb, 0x00, 0x100);
 g_test_message("FB: 0x%08" PRIx64, ahci->port[i].fb);
 ahci_px_wreg(ahci, i, AHCI_PX_FB, ahci->port[i].fb);
 g_assert_cmphex(ahci->port[i].fb, ==,
@@ -397,7 +398,7 @@ void ahci_port_clear(AHCIQState *ahci, uint8_t port)
 g_assert_cmphex(ahci_px_rreg(ahci, port, AHCI_PX_IS), ==, 0);
 
 /* Wipe the FIS-Receive Buffer */
-qmemset(ahci->port[port].fb, 0x00, 0x100);
+qtest_memset(ahci->parent->qts, ahci->port[port].fb, 0x00, 0x100);
 }
 
 /**
@@ -466,7 +467,7 @@ void ahci_port_check_d2h_sanity(AHCIQState *ahci, uint8_t 
port, uint8_t slot)
 RegD2HFIS *d2h = g_malloc0(0x20);
 uint32_t reg;
 
-memread(ahci->port[port].fb + 0x40, d2h, 0x20);
+qtest_memread(ahci->parent->qts, ahci->port[port].fb + 0x40, d2h, 0x20);
 g_assert_cmphex(d2h->fis_type, ==, 0x34);
 
 reg = ahci_px_rreg(ahci, port, AHCI_PX_TFD);
@@ -484,7 +485,7 @@ void ahci_port_check_pio_sanity(AHCIQState *ahci, uint8_t 
port,
 /* We cannot check the Status or E_Status registers, because
  * the status may have again changed between the PIO Setup FIS
  * and the conclusion of the command with the D2H Register FIS. */
-memread(ahci->port[port].fb + 0x20, pio, 0x20);
+qtest_memread(ahci->parent->qts, ahci->port[port].fb + 0x20, pio, 0x20);
 g_assert_cmphex(pio->fis_type, ==, 0x5f);
 
 /* BUG: PIO Setup FIS as utilized by QEMU tries to fit the entire
@@ -516,7 +517,7 @@ void ahci_get_command_header(AHCIQState *ahci, uint8_t port,
 {
 uint64_t ba = ahci->port[port].clb;
 ba += slot * sizeof(AHCICommandHeader);
-memread(ba, cmd, sizeof(AHCICommandHeader));
+qtest_memread(ahci->parent->qts, ba, cmd, sizeof(AHCICommandHeader));
 
 cmd->flags = le16_to_cpu(cmd->flags);
 cmd->prdtl = le16_to_cpu(cmd->prdtl);
@@ -537,7 +538,7 @@ void ahci_set_command_header(AHCIQState *ahci, uint8_t port,
 tmp.prdbc = cpu_to_le32(cmd->prdbc);
 tmp.ctba = cpu_to_le64(cmd->ctba);
 
-memwrite(ba, , sizeof(AHCICommandHeader));
+qtest_memwrite(ahci->parent->qts, ba, , sizeof(AHCICommandHeader));
 }
 
 void ahci_destroy_command(AHCIQState *ahci, uint8_t port, uint8_t slot)
@@ -575,7 +576,7 @@ void ahci_write_fis(AHCIQState *ahci, AHCICommand *cmd)
 tmp.count = cpu_to_le16(tmp.count);
 }
 
-memwrite(addr, , sizeof(tmp));
+qtest_memwrite(ahci->parent->qts, addr, , sizeof(tmp));
 }
 
 unsigned ahci_pick_cmd(AHCIQState *ahci, uint8_t port)
@@ -636,7 +637,7 @@ void ahci_exec(AHCIQState *ahci, uint8_t port,
 if (opts->size && !opts->buffer) {
 opts->buffer = ahci_alloc(ahci, opts->size);
 g_assert(opts->buffer);
-qmemset(opts->buffer, 0x00, opts->size);
+qtest_memset(ahci->parent->qts, opts->buffer, 0x00, opts->size);
 }
 
 /* Command creation */
@@ -661,15 +662,15 @@ void ahci_exec(AHCIQState *ahci, uint8_t port,
 ahci_command_commit(ahci, cmd, port);
 ahci_command_issue_async(ahci, cmd);
 if (opts->error) {
-qmp_eventwait("STOP");
+qtest_qmp_eventwait(ahci->parent->qts, "STOP");
 }
 if (opts->mid_cb) {
 rc = opts->mid_cb(ahci, cmd, opts);
 g_assert_cmpint(rc, ==, 0);
 }
 if (opts->error) {
-qmp_async("{'execute':'cont' }");
-qmp_eventwait("RESUME");
+qtest_async_qmp(ahci->parent->qts, "{'execute':'cont' }");
+qtest_qmp_eventwait(ahci->parent->qts, "RESUME");
 }
 

[Qemu-devel] [Bug 1379688] Re: qemu's monitor and parallel create huge window

[Thomas Huth]

Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  qemu's monitor and parallel create huge window

Status in QEMU:
  Incomplete

Bug description:
  I have qemu 2.1. When I try to switch to monitor or parallel0, I get
  window which is 30 *thousand* pixels in height. It is only gray with
  no content. This did not happen with previous versions of qemu.

  Kwin crashes because it cannot handle such a huge window.

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

Re: [Qemu-devel] [PATCH v2 00/32] Add ARMv8.2 half-precision functions

[no-reply]

Hi,

This series failed docker-quick@centos6 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 20180208173157.24705-1-alex.ben...@linaro.org
Subject: [Qemu-devel] [PATCH v2 00/32] Add ARMv8.2 half-precision functions

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 t [tag update]patchew/20180208172202.9984-1-f4...@amsat.org -> 
patchew/20180208172202.9984-1-f4...@amsat.org
 * [new tag]   
patchew/20180208180019.13683-1-antonios.mota...@huawei.com -> 
patchew/20180208180019.13683-1-antonios.mota...@huawei.com
Switched to a new branch 'test'
828fdf8039 arm/translate-a64: add all single op FP16 to handle_fp_1src_half
bb12347df0 arm/translate-a64: implement simd_scalar_three_reg_same_fp16
9d90e658c5 arm/translate-a64: add all FP16 ops in simd_scalar_pairwise
18e4d6f1d2 arm/translate-a64: add FP16 FMOV to simd_mod_imm
487d21785a arm/translate-a64: add FP16 FRSQRTE to simd_two_reg_misc_fp16
e687eee03d arm/helper.c: re-factor rsqrte and add rsqrte_f16
4078596895 arm/translate-a64: add FP16 FSQRT to simd_two_reg_misc_fp16
14e2473a01 arm/translate-a64: add FP16 FRCPX to simd_two_reg_misc_fp16
0080b9feb1 arm/translate-a64: add FP16 FRECPE
322031a5c9 arm/helper.c: re-factor recpe and add recepe_f16
99396effce arm/translate-a64: add FP16 FNEG/FABS to simd_two_reg_misc_fp16
fc0f9dbd0a arm/translate-a64: add FP16 SCVTF/UCVFT to simd_two_reg_misc_fp16
ed77588f3f arm/translate-a64: add FP16 FCMxx (zero) to simd_two_reg_misc_fp16
28b6a6a772 arm/translate-a64: add FCVTxx to simd_two_reg_misc_fp16
c8ce2f736d arm/translate-a64: add FP16 FPRINTx to simd_two_reg_misc_fp16
900561ae36 arm/translate-a64: initial decode for simd_two_reg_misc_fp16
d55f8fd2d4 arm/translate-a64: add FP16 x2 ops for simd_indexed
79200bf33e arm/translate-a64: add FP16 FMULX/MLS/FMLA to simd_indexed
eebcc3aeb6 arm/translate-a64: add FP16 pairwise ops simd_three_reg_same_fp16
a7d42c109d arm/translate-a64: add FP16 FR[ECP/SQRT]S to simd_three_reg_same_fp16
f4f8f0083b arm/translate-a64: add FP16 FMULA/X/S to simd_three_reg_same_fp16
f9994103ca arm/translate-a64: add FP16 F[A]C[EQ/GE/GT] to 
simd_three_reg_same_fp16
740b571cc7 arm/translate-a64: add FP16 FADD/FABD/FSUB/FMUL/FDIV to 
simd_three_reg_same_fp16
221024b870 arm/translate-a64: initial decode for simd_three_reg_same_fp16
e55cd68b2e arm/translate-a64: handle_3same_64 comment fix
e961c2bee4 arm/translate-a64: implement half-precision F(MIN|MAX)(V|NMV)
c177c95091 target/arm/helper: pass explicit fpst to set_rmode
71fe7953f2 target/arm/cpu.h: add additional float_status flags
c2bbffe04d target/arm/cpu.h: update comment for half-precision values
f5f0e3fa79 target/arm/cpu64: allow fp16 to be disabled
ab954b06bc target/arm/cpu64: introduce ARM_V8_FP16 feature bit
7c3b41efe8 include/exec/helper-head.h: support f16 in helper calls

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-t07l1ntg/src/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
  BUILD   centos6
  GEN 
/var/tmp/patchew-tester-tmp-t07l1ntg/src/docker-src.2018-02-08-14.09.58.21841/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-t07l1ntg/src/docker-src.2018-02-08-14.09.58.21841/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-t07l1ntg/src/docker-src.2018-02-08-14.09.58.21841/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-t07l1ntg/src/docker-src.2018-02-08-14.09.58.21841/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
bison-2.4.1-5.el6.x86_64
bzip2-devel-1.0.5-7.el6_0.x86_64
ccache-3.1.6-2.el6.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el6.x86_64
flex-2.5.35-9.el6.x86_64
gcc-4.4.7-18.el6.x86_64
gettext-0.17-18.el6.x86_64
git-1.7.1-9.el6_9.x86_64
glib2-devel-2.28.8-9.el6.x86_64
libepoxy-devel-1.2-3.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
librdmacm-devel-1.0.21-0.el6.x86_64
lzo-devel-2.03-3.1.el6_5.1.x86_64
make-3.81-23.el6.x86_64
mesa-libEGL-devel-11.0.7-4.el6.x86_64
mesa-libgbm-devel-11.0.7-4.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
spice-glib-devel-0.26-8.el6.x86_64