[Qemu-commits] [qemu/qemu] 44a3dd: tests: minor cleanups in usb-hcd-uhci-test

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 44a3dd9b8718a7f0a94053c57782886748a43d7a
      
https://github.com/qemu/qemu/commit/44a3dd9b8718a7f0a94053c57782886748a43d7a
  Author: Laurent Vivier <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M tests/usb-hcd-uhci-test.c

  Log Message:
  -----------
  tests: minor cleanups in usb-hcd-uhci-test

Two minor cleanups:
- exit gracefully in case on unsupported target,
- put machine command line in a constant to avoid
  to duplicate it.

Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Gerd Hoffmann <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 54ce6f22e86977b6e94692d90e13fce6fc9aa641
      
https://github.com/qemu/qemu/commit/54ce6f22e86977b6e94692d90e13fce6fc9aa641
  Author: Laurent Vivier <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M qtest.c
    M tests/libqos/virtio-pci.c
    M tests/libqtest.c
    M tests/libqtest.h
    M tests/virtio-blk-test.c

  Log Message:
  -----------
  qtest: ask endianness of the target in qtest_init()

The target endianness is not deduced anymore from
the architecture name but asked directly to the guest,
using a new qtest command: "endianness". As it can't
change (this is the value of TARGET_WORDS_BIGENDIAN),
we store it to not have to ask every time we want to
know if we have to byte-swap a value.

Signed-off-by: Laurent Vivier <address@hidden>
CC: Greg Kurz <address@hidden>
CC: David Gibson <address@hidden>
CC: Peter Maydell <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 1ef2ef96296f061c89b60e77c3c50577fd6fe415
      
https://github.com/qemu/qemu/commit/1ef2ef96296f061c89b60e77c3c50577fd6fe415
  Author: Thomas Huth <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M tests/boot-sector.c

  Log Message:
  -----------
  tests/boot-sector: Use minimum length for the Forth boot script

The pxe-test is quite slow on ppc64 with tcg. We can speed it up
a little bit by decreasing the size of the file that has to be
loaded via TFTP.

Signed-off-by: Thomas Huth <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 3e353773721596971db2d0abc7015e7ea3d3af07
      
https://github.com/qemu/qemu/commit/3e353773721596971db2d0abc7015e7ea3d3af07
  Author: Thomas Huth <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M tests/bios-tables-test.c
    M tests/boot-sector.c
    M tests/boot-sector.h
    M tests/pxe-test.c

  Log Message:
  -----------
  tests/boot-sector: Use mkstemp() to create a unique file name

The pxe-test is run for three different targets now (x86_64, i386
and ppc64), and the bios-tables-test is run for two targets (x86_64
and i386). But each of the tests is using an invariant name for the
disk image with the boot sector code - so if the tests are running in
parallel, there is a race condition that they destroy the disk image
of a parallel test program. Let's use mkstemp() to create unique
temporary files here instead - and since mkstemp() is returning an
integer file descriptor instead of a FILE pointer, we also switch
the fwrite() and fclose() to write() and close() instead.

Reported-by: Sascha Silbe <address@hidden>
Signed-off-by: Thomas Huth <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 74cba2b3b23d069d1a3d9b3ef7876123d939d3ba
      
https://github.com/qemu/qemu/commit/74cba2b3b23d069d1a3d9b3ef7876123d939d3ba
  Author: Thomas Huth <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M tests/boot-sector.c

  Log Message:
  -----------
  tests/boot-sector: Increase time-out to 90 seconds

Since the PXE tester runs rather slow on ppc64 with tcg, there
is a chance that we hit the 60 seconds timeout on machines that
have a heavy CPU load. So let's increase the timeout to ease
the situation.

Signed-off-by: Thomas Huth <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 125a9b2327173f4cd38509276ea74f2133934820
      
https://github.com/qemu/qemu/commit/125a9b2327173f4cd38509276ea74f2133934820
  Author: Nikunj A Dadhania <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M target-ppc/helper.h
    M target-ppc/int_helper.c
    M target-ppc/translate/vmx-impl.inc.c
    M target-ppc/translate/vmx-ops.inc.c

  Log Message:
  -----------
  target-ppc: implement vexts[bh]2w and vexts[bhw]2d

Vector Extend Sign Instructions:

vextsb2w: Vector Extend Sign Byte To Word
vextsh2w: Vector Extend Sign Halfword To Word
vextsb2d: Vector Extend Sign Byte To Doubleword
vextsh2d: Vector Extend Sign Halfword To Doubleword
vextsw2d: Vector Extend Sign Word To Doubleword

Signed-off-by: Nikunj A Dadhania <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 672de881e9367f6d1787901c016c6e836d712f21
      
https://github.com/qemu/qemu/commit/672de881e9367f6d1787901c016c6e836d712f21
  Author: Michael Roth <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: fix inheritance chain for default machine options

Rather than machine instances having backward-compatible option
defaults that need to be repeatedly re-enabled for every new machine
type we introduce, we set the defaults appropriate for newer machine
types, then add code to explicitly disable instance options as needed
to maintain compatibility with older machine types.

Currently pseries-2.5 does not inherit from pseries-2.6 in this
fashion, which is okay at the moment since we do not have any
instance compatibility options for pseries-2.6+ currently.

We will make use of this in future patches though, so fix it here.

Signed-off-by: Michael Roth <address@hidden>
[dwg: Extended to make 2.7 inherit from 2.8 as well]
Signed-off-by: David Gibson <address@hidden>


  Commit: cc706a530518f867c29177a5a337bb08503e617e
      
https://github.com/qemu/qemu/commit/cc706a530518f867c29177a5a337bb08503e617e
  Author: Benjamin Herrenschmidt <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M hw/intc/trace-events
    M hw/intc/xics.c
    M hw/intc/xics_kvm.c
    M hw/intc/xics_spapr.c
    M hw/ppc/spapr_events.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/spapr_vio.c
    M include/hw/ppc/xics.h

  Log Message:
  -----------
  ppc/xics: Make the ICSState a list

Instead of an array of fixed sized blocks, use a list, as we will need
to have sources with variable number of interrupts. SPAPR only uses
a single entry. Native will create more. If performance becomes an
issue we can add some hashed lookup but for now this will do fine.

Signed-off-by: Benjamin Herrenschmidt <address@hidden>
[ move the initialization of list to xics_common_initfn,
  restore xirr_owner after migration and move restoring to
  icp_post_load]
Signed-off-by: Nikunj A Dadhania <address@hidden>
[ clg: removed the icp_post_load() changes from nikunj patchset v3:
       http://patchwork.ozlabs.org/patch/646008/ ]
Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: d4d7a59a7a703220757cdc24d08a498db3e70212
      
https://github.com/qemu/qemu/commit/d4d7a59a7a703220757cdc24d08a498db3e70212
  Author: Benjamin Herrenschmidt <address@hidden>
  Date:   2016-10-14 (Fri, 14 Oct 2016)

  Changed paths:
    M hw/intc/trace-events
    M hw/intc/xics.c
    M hw/intc/xics_kvm.c
    M hw/intc/xics_spapr.c
    M include/hw/ppc/xics.h

  Log Message:
  -----------
  ppc/xics: Split ICS into ics-base and ics class

The existing implementation remains same and ics-base is introduced. The
type name "ics" is retained, and all the related functions renamed as
ics_simple_*

This will allow different implementations for the source controllers
such as the MSI support of PHB3 on Power8 which uses in-memory state
tables for example.

Signed-off-by: Benjamin Herrenschmidt <address@hidden>
Signed-off-by: Nikunj A Dadhania <address@hidden>
Reviewed-by: David Gibson <address@hidden>
[ clg: added ICS_BASE_GET_CLASS and related fixes, based on :
       http://patchwork.ozlabs.org/patch/646010/ ]
Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: cd1b354ec05035f84bb05f591cb632770ad36e7c
      
https://github.com/qemu/qemu/commit/cd1b354ec05035f84bb05f591cb632770ad36e7c
  Author: David Gibson <address@hidden>
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
    M tests/libqos/pci-spapr.c

  Log Message:
  -----------
  libqos: Isolate knowledge of spapr memory map to qpci_init_spapr()

The libqos code for accessing PCI on the spapr machine type uses IOBASE()
and MMIOBASE() macros to determine the address in the CPU memory map of
the windows to PCI address space.

This is a detail of the implementation of PCI in the machine type, it's not
specified by the PAPR standard.  Real guests would get the addresses of the
PCI windows from the device tree.

Finding the device tree in libqos would be awkward, but we can at least
localize this knowledge of the implementation to the init function, saving
it in the QPCIBusSPAPR structure for use by the accessors.

That leaves only one place to fix if we alter the location of the PCI
windows, as we're planning to do.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: c711369087d5964ea77b0fd0e0ff1f268e1a67ee
      
https://github.com/qemu/qemu/commit/c711369087d5964ea77b0fd0e0ff1f268e1a67ee
  Author: David Gibson <address@hidden>
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
    M tests/libqos/pci-spapr.c

  Log Message:
  -----------
  libqos: Correct error in PCI hole sizing for spapr

In pci-spapr.c (as in pci-pc.c from which it was derived), the
pci_hole_start/pci_hole_size and pci_iohole_start/pci_iohole_size pairs[1]
essentially define the region of PCI (not CPU) addresses in which MMIO
or PIO BARs respectively will be allocated.

The size value is relative to the start value.  But in pci-spapr.c it is
set to the entire size of the window supported by the (emulated) hardware,
but the start values are *not* at the beginning of the emulated windows.

That means if you tried to map enough PCI BARs, we'd messily overrun the
IO windows, instead of failing in iomap as we should.

This patch corrects this by calculating the hole sizes from the location
of the window in PCI space and the hole start.

[1] Those are bad names, but that's a problem for another time.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: 8360544a6d3a54df1fce80f55ba4ad075a8ded54
      
https://github.com/qemu/qemu/commit/8360544a6d3a54df1fce80f55ba4ad075a8ded54
  Author: David Gibson <address@hidden>
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
    M tests/libqos/pci-spapr.c

  Log Message:
  -----------
  libqos: Limit spapr-pci to 32-bit MMIO for now

Currently the functions in pci-spapr.c (like pci-pc.c on which it's based)
don't distinguish between 32-bit and 64-bit PCI MMIO.  At the moment, the
qemu side implementation is a bit weird and has a single MMIO window
straddling 32-bit and 64-bit regions, but we're likely to change that in
future.

In any case, pci-pc.c - and therefore the testcases using PCI - only handle
32-bit MMIOs for now.  For spapr despite whatever changes might happen with
the MMIO windows, the 32-bit window is likely to remain at 2..4 GiB in PCI
space.

So, explicitly limit pci-spapr.c to 32-bit MMIOs for now, we can add 64-bit
MMIO support back in when and if we need it.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: 6737d9ad79f6db657c7fc5658355aa5045dbfa2c
      
https://github.com/qemu/qemu/commit/6737d9ad79f6db657c7fc5658355aa5045dbfa2c
  Author: David Gibson <address@hidden>
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_pci.c
    M include/hw/pci-host/spapr.h
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr_pci: Delegate placement of PCI host bridges to machine type

The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
for a PAPR guest.  Unlike on x86, it's routine on Power (both bare metal
and PAPR guests) to have numerous independent PHBs, each controlling a
separate PCI domain.

There are two ways of configuring the spapr-pci-host-bridge device: first
it can be done fully manually, specifying the locations and sizes of all
the IO windows.  This gives the most control, but is very awkward with 6
mandatory parameters.  Alternatively just an "index" can be specified
which essentially selects from an array of predefined PHB locations.
The PHB at index 0 is automatically created as the default PHB.

The current set of default locations causes some problems for guests with
large RAM (> 1 TiB) or PCI devices with very large BARs (e.g. big nVidia
GPGPU cards via VFIO).  Obviously, for migration we can only change the
locations on a new machine type, however.

This is awkward, because the placement is currently decided within the
spapr-pci-host-bridge code, so it breaks abstraction to look inside the
machine type version.

So, this patch delegates the "default mode" PHB placement from the
spapr-pci-host-bridge device back to the machine type via a public method
in sPAPRMachineClass.  It's still a bit ugly, but it's about the best we
can do.

For now, this just changes where the calculation is done.  It doesn't
change the actual location of the host bridges, or any other behaviour.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: 2efff1c0dd15c8debeb1647d574bec97355cd5e6
      
https://github.com/qemu/qemu/commit/2efff1c0dd15c8debeb1647d574bec97355cd5e6
  Author: David Gibson <address@hidden>
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Adjust placement of PCI host bridge to allow > 1TiB RAM

Currently the default PCI host bridge for the 'pseries' machine type is
constructed with its IO windows in the 1TiB..(1TiB + 64GiB) range in
guest memory space.  This means that if > 1TiB of guest RAM is specified,
the RAM will collide with the PCI IO windows, causing serious problems.

Problems won't be obvious until guest RAM goes a bit beyond 1TiB, because
there's a little unused space at the bottom of the area reserved for PCI,
but essentially this means that > 1TiB of RAM has never worked with the
pseries machine type.

This patch fixes this by altering the placement of PHBs on large-RAM VMs.
Instead of always placing the first PHB at 1TiB, it is placed at the next
1 TiB boundary after the maximum RAM address.

Technically, this changes behaviour in a migration-breaking way for
existing machines with > 1TiB maximum memory, but since having > 1 TiB
memory was broken anyway, this seems like a reasonable trade-off.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: daa23699031693b434ec263b212f77ba505e353e
      
https://github.com/qemu/qemu/commit/daa23699031693b434ec263b212f77ba505e353e
  Author: David Gibson <address@hidden>
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_pci.c
    M include/hw/pci-host/spapr.h
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr_pci: Add a 64-bit MMIO window

On real hardware, and under pHyp, the PCI host bridges on Power machines
typically advertise two outbound MMIO windows from the guest's physical
memory space to PCI memory space:
  - A 32-bit window which maps onto 2GiB..4GiB in the PCI address space
  - A 64-bit window which maps onto a large region somewhere high in PCI
    address space (traditionally this used an identity mapping from guest
    physical address to PCI address, but that's not always the case)

The qemu implementation in spapr-pci-host-bridge, however, only supports a
single outbound MMIO window, however.  At least some Linux versions expect
the two windows however, so we arranged this window to map onto the PCI
memory space from 2 GiB..~64 GiB, then advertised it as two contiguous
windows, the "32-bit" window from 2G..4G and the "64-bit" window from
4G..~64G.

This approach means, however, that the 64G window is not naturally aligned.
In turn this limits the size of the largest BAR we can map (which does have
to be naturally aligned) to roughly half of the total window.  With some
large nVidia GPGPU cards which have huge memory BARs, this is starting to
be a problem.

This patch adds true support for separate 32-bit and 64-bit outbound MMIO
windows to the spapr-pci-host-bridge implementation, each of which can
be independently configured.  The 32-bit window always maps to 2G.. in PCI
space, but the PCI address of the 64-bit window can be configured (it
defaults to the same as the guest physical address).

So as not to break possible existing configurations, as long as a 64-bit
window is not specified, a large single window can be specified.  This
will appear the same way to the guest as the old approach, although it's
now implemented by two contiguous memory regions rather than a single one.

For now, this only adds the possibility of 64-bit windows.  The default
configuration still uses the legacy mode.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: 357d1e3bc7d2d80e5271bc4f3ac8537e30dc8046
      
https://github.com/qemu/qemu/commit/357d1e3bc7d2d80e5271bc4f3ac8537e30dc8046
  Author: David Gibson <address@hidden>
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_pci.c
    M include/hw/pci-host/spapr.h
    M tests/endianness-test.c
    M tests/libqos/pci-spapr.c
    M tests/spapr-phb-test.c

  Log Message:
  -----------
  spapr: Improved placement of PCI host bridges in guest memory map

Currently, the MMIO space for accessing PCI on pseries guests begins at
1 TiB in guest address space.  Each PCI host bridge (PHB) has a 64 GiB
chunk of address space in which it places its outbound PIO and 32-bit and
64-bit MMIO windows.

This scheme as several problems:
  - It limits guest RAM to 1 TiB (though we have a limited fix for this
    now)
  - It limits the total MMIO window to 64 GiB.  This is not always enough
    for some of the large nVidia GPGPU cards
  - Putting all the windows into a single 64 GiB area means that naturally
    aligning things within there will waste more address space.
In addition there was a miscalculation in some of the defaults, which meant
that the MMIO windows for each PHB actually slightly overran the 64 GiB
region for that PHB.  We got away without nasty consequences because
the overrun fit within an unused area at the beginning of the next PHB's
region, but it's not pretty.

This patch implements a new scheme which addresses those problems, and is
also closer to what bare metal hardware and pHyp guests generally use.

Because some guest versions (including most current distro kernels) can't
access PCI MMIO above 64 TiB, we put all the PCI windows between 32 TiB and
64 TiB.  This is broken into 1 TiB chunks.  The first 1 TiB contains the
PIO (64 kiB) and 32-bit MMIO (2 GiB) windows for all of the PHBs.  Each
subsequent TiB chunk contains a naturally aligned 64-bit MMIO window for
one PHB each.

This reduces the number of allowed PHBs (without full manual configuration
of all the windows) from 256 to 31, but this should still be plenty in
practice.

We also change some of the default window sizes for manually configured
PHBs to saner values.

Finally we adjust some tests and libqos so that it correctly uses the new
default locations.  Ideally it would parse the device tree given to the
guest, but that's a more complex problem for another time.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>


  Commit: 7bf59dfec4234e75e31b3f397374cb5bab1a5b2c
      
https://github.com/qemu/qemu/commit/7bf59dfec4234e75e31b3f397374cb5bab1a5b2c
  Author: Peter Maydell <address@hidden>
  Date:   2016-10-17 (Mon, 17 Oct 2016)

  Changed paths:
    M hw/intc/trace-events
    M hw/intc/xics.c
    M hw/intc/xics_kvm.c
    M hw/intc/xics_spapr.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_events.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/spapr_vio.c
    M include/hw/pci-host/spapr.h
    M include/hw/ppc/spapr.h
    M include/hw/ppc/xics.h
    M qtest.c
    M target-ppc/helper.h
    M target-ppc/int_helper.c
    M target-ppc/translate/vmx-impl.inc.c
    M target-ppc/translate/vmx-ops.inc.c
    M tests/bios-tables-test.c
    M tests/boot-sector.c
    M tests/boot-sector.h
    M tests/endianness-test.c
    M tests/libqos/pci-spapr.c
    M tests/libqos/virtio-pci.c
    M tests/libqtest.c
    M tests/libqtest.h
    M tests/pxe-test.c
    M tests/spapr-phb-test.c
    M tests/usb-hcd-uhci-test.c
    M tests/virtio-blk-test.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.8-20161017' into 
staging

ppc patch queue 2016-10-17

Highlights:
    * Significant rework of how PCI IO windows are placed for the
      pseries machine type
    * A number of extra tests added for ppc
    * Other tests clean up / fixed
    * Some cleanups to the XICS interrupt controller in preparation
      for the 'powernv' machine type

A number of the test changes aren't strictly in ppc related code, but
are included via my tree because they're primarily focused on
improving test coverage for ppc.

# gpg: Signature made Mon 17 Oct 2016 03:42:41 BST
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>"
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>"
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>"
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.8-20161017:
  spapr: Improved placement of PCI host bridges in guest memory map
  spapr_pci: Add a 64-bit MMIO window
  spapr: Adjust placement of PCI host bridge to allow > 1TiB RAM
  spapr_pci: Delegate placement of PCI host bridges to machine type
  libqos: Limit spapr-pci to 32-bit MMIO for now
  libqos: Correct error in PCI hole sizing for spapr
  libqos: Isolate knowledge of spapr memory map to qpci_init_spapr()
  ppc/xics: Split ICS into ics-base and ics class
  ppc/xics: Make the ICSState a list
  spapr: fix inheritance chain for default machine options
  target-ppc: implement vexts[bh]2w and vexts[bhw]2d
  tests/boot-sector: Increase time-out to 90 seconds
  tests/boot-sector: Use mkstemp() to create a unique file name
  tests/boot-sector: Use minimum length for the Forth boot script
  qtest: ask endianness of the target in qtest_init()
  tests: minor cleanups in usb-hcd-uhci-test

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/ad728364e391...7bf59dfec423