aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-11-05image-fuzzer: Use OSerror.strerror instead of tuple subscriptEduardo Habkost
OSError can't be used like a tuple on Python 3, so change the code to use `e.sterror` instead of `e[1]`. Reported-by: John Snow <jsnow@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20191021214117.18091-1-ehabkost@redhat.com Message-Id: <20191021214117.18091-1-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Use errors parameter of subprocess.Popen()Eduardo Habkost
Instead of manually encoding stderr and stdout output, use `errors` parameter of subprocess.Popen(). This will make process.communicate() return unicode strings instead of bytes objects. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-11-ehabkost@redhat.com Message-Id: <20191016192430.25098-11-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Run using python3Eduardo Habkost
image-fuzzer is now supposed to be ready to run using Python 3. Remove the __future__ imports and change the interpreter line to "#!/usr/bin/env python3". Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-10-ehabkost@redhat.com Message-Id: <20191016192430.25098-10-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Encode file name and file format to bytesEduardo Habkost
Callers of create_image() will pass strings as arguments, but the Image class will expect bytes objects to be provided. Encode them inside create_image(). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-9-ehabkost@redhat.com Message-Id: <20191016192430.25098-9-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Use bytes constant for field valuesEduardo Habkost
Field values are supposed to be bytes objects, not unicode strings. Change two constants that were declared as strings. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-8-ehabkost@redhat.com Message-Id: <20191016192430.25098-8-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Return bytes objects on string fuzzing functionsEduardo Habkost
No caller of fuzzer functions is interested in unicode string values, so replace them with bytes sequences. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-7-ehabkost@redhat.com Message-Id: <20191016192430.25098-7-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Use %r for all fiels at Field.__repr__()Eduardo Habkost
This makes the formatting code simpler, and safer if we change the type of self.value from str to bytes. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-6-ehabkost@redhat.com Message-Id: <20191016192430.25098-6-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Use io.StringIOEduardo Habkost
StringIO.StringIO is not available on Python 3, but io.StringIO is available on both Python 2 and 3. io.StringIO is slightly different from the Python 2 StringIO module, though, so we need bytes coming from subprocess.Popen() to be explicitly decoded. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-5-ehabkost@redhat.com Message-Id: <20191016192430.25098-5-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Explicitly use integer division operatorEduardo Habkost
Most of the division expressions in image-fuzzer assume integer division. Use the // operator to keep the same behavior when we move to Python 3. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-4-ehabkost@redhat.com Message-Id: <20191016192430.25098-4-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Write bytes instead of string to image fileEduardo Habkost
This is necessary for Python 3 compatibility. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-3-ehabkost@redhat.com Message-Id: <20191016192430.25098-3-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05image-fuzzer: Open image files in binary modeEduardo Habkost
This probably never caused problems because on Linux there's no actual newline conversion happening, but on Python 3 the binary/text distinction is stronger and we must explicitly open the image file in binary mode. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191016192430.25098-2-ehabkost@redhat.com Message-Id: <20191016192430.25098-2-ehabkost@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-05hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accessesPhilippe Mathieu-Daudé
The Plug & Play region of the AHB/APB bridge can be accessed by various word size, however the implementation is clearly restricted to 32-bit: static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size) { APBPnp *apb_pnp = GRLIB_APB_PNP(opaque); return apb_pnp->regs[offset >> 2]; } Set the MemoryRegionOps::impl min/max fields to 32-bit, so memory.c::access_with_adjusted_size() can adjust when the access is not 32-bit. This is required to run RTEMS on leon3, the grlib scanning functions do byte accesses. Reported-by: Jiri Gaisler <jiri@gaisler.se> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com> Message-Id: <20191025110114.27091-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2019-11-05hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registersPhilippe Mathieu-Daudé
Guests can crash QEMU when writting to PnP registers: $ echo 'writeb 0x800ff042 69' | qemu-system-sparc -M leon3_generic -S -bios /etc/magic -qtest stdio [I 1571938309.932255] OPENED [R +0.063474] writeb 0x800ff042 69 Segmentation fault (core dumped) (gdb) bt #0 0x0000000000000000 in () #1 0x0000555f4bcdf0bc in memory_region_write_with_attrs_accessor (mr=0x555f4d7be8c0, addr=66, value=0x7fff07d00f08, size=1, shift=0, mask=255, attrs=...) at memory.c:503 #2 0x0000555f4bcdf185 in access_with_adjusted_size (addr=66, value=0x7fff07d00f08, size=1, access_size_min=1, access_size_max=4, access_fn=0x555f4bcdeff4 <memory_region_write_with_attrs_accessor>, mr=0x555f4d7be8c0, attrs=...) at memory.c:539 #3 0x0000555f4bce2243 in memory_region_dispatch_write (mr=0x555f4d7be8c0, addr=66, data=69, op=MO_8, attrs=...) at memory.c:1489 #4 0x0000555f4bc80b20 in flatview_write_continue (fv=0x555f4d92c400, addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, addr1=66, l=1, mr=0x555f4d7be8c0) at exec.c:3161 #5 0x0000555f4bc80c65 in flatview_write (fv=0x555f4d92c400, addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3201 #6 0x0000555f4bc80fb0 in address_space_write (as=0x555f4d7aa460, addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3291 #7 0x0000555f4bc8101d in address_space_rw (as=0x555f4d7aa460, addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, is_write=true) at exec.c:3301 #8 0x0000555f4bcdb388 in qtest_process_command (chr=0x555f4c2ed7e0 <qtest_chr>, words=0x555f4db0c5d0) at qtest.c:432 Instead of crashing, log the access as unimplemented. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com> Message-Id: <20191025110114.27091-2-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2019-11-05qemu-options: Rework the help text of the '-display' optionThomas Huth
Improve the help text of the "-display" option: - Only print the options that we have enabled in the binary (similar to what we do for other options like -netdev already) - The "frame=on|off" from "-display sdl" has been removed in commit 09bd7ba9f5f7 ("Remove deprecated -no-frame option"), so we should not show this in the help text anymore - The "-display egl-headless" line was missing a "\n" at the end - Indent the default display text in a nicer way Signed-off-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191023120129.13721-1-huth@tuxfamily.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-11-05linux-user: Support for NETLINK socket optionsJosh Kunz
This change includes support for all AF_NETLINK socket options up to about kernel version 5.4 (5.4 is not formally released at the time of writing). Socket options that were introduced in kernel versions before the oldest currently stable kernel version are guarded by kernel version macros. This change has been built under gcc 8.3, and clang 9.0, and it passes `make check`. The netlink options have been tested by emulating some non-trival software that uses NETLINK socket options, but they have not been exaustively verified. Signed-off-by: Josh Kunz <jkz@google.com> Message-Id: <20191029224310.164025-1-jkz@google.com> [lv: updated patch according to CODING_STYLE] Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2019-11-05hw/i386: AMD-Vi IVRS DMA alias supportAlex Williamson
When we account for DMA aliases in the PCI address space, we can no longer use a single IVHD entry in the IVRS covering all devices. We instead need to walk the PCI bus and create alias ranges when we find a conventional bus. These alias ranges cannot overlap with a "Select All" range (as currently implemented), so we also need to enumerate each device with IVHD entries. Importantly, the IVHD entries used here include a Device ID, which is simply the PCI BDF (Bus/Device/Function). The guest firmware is responsible for programming bus numbers, so the final revision of this table depends on the update mechanism (acpi_build_update) to be called after guest PCI enumeration. For an example guest configuration of: -+-[0000:40]---00.0-[41]----00.0 Intel Corporation 82574L Gigabit Network Connection \-[0000:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller +-01.0 Device 1234:1111 +-02.0-[01]----00.0 Intel Corporation 82574L Gigabit Network Connection +-02.1-[02]----00.0 Red Hat, Inc. QEMU XHCI Host Controller +-02.2-[03]-- +-02.3-[04]-- +-02.4-[05]-- +-02.5-[06-09]----00.0-[07-09]--+-00.0-[08]-- | \-01.0-[09]----00.0 Intel Corporation 82574L Gigabit Network Connection +-02.6-[0a-0c]----00.0-[0b-0c]--+-01.0-[0c]-- | \-03.0 Intel Corporation 82540EM Gigabit Ethernet Controller +-02.7-[0d]----0e.0 Intel Corporation 82540EM Gigabit Ethernet Controller +-03.0 Red Hat, Inc. QEMU PCIe Expander bridge +-04.0 Advanced Micro Devices, Inc. [AMD] Device 0020 +-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface Controller +-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus Controller Where we have: 00:02.7 PCI bridge: Intel Corporation 82801 PCI Bridge (dmi-to-pci-bridge) 00:03.0 Host bridge: Red Hat, Inc. QEMU PCIe Expander bridge (pcie-expander-bus) 06:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Upstream) (pcie-switch-upstream-port) 07:00.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (pcie-switch-downstream-port) 07:01.0 PCI bridge: Texas Instruments XIO3130 PCI Express Switch (Downstream) (pcie-switch-downstream-port) 0a:00.0 PCI bridge: Red Hat, Inc. Device 000e (pcie-to-pci-bridge) The following IVRS table is produced: AMD-Vi: Using IVHD type 0x10 AMD-Vi: device: 00:04.0 cap: 0040 seg: 0 flags: d1 info 0000 AMD-Vi: mmio-addr: 00000000fed80000 AMD-Vi: DEV_SELECT devid: 40:00.0 flags: 00 AMD-Vi: DEV_SELECT_RANGE_START devid: 41:00.0 flags: 00 AMD-Vi: DEV_RANGE_END devid: 41:1f.7 AMD-Vi: DEV_SELECT devid: 00:00.0 flags: 00 AMD-Vi: DEV_SELECT devid: 00:01.0 flags: 00 AMD-Vi: DEV_SELECT devid: 00:02.0 flags: 00 AMD-Vi: DEV_SELECT_RANGE_START devid: 01:00.0 flags: 00 AMD-Vi: DEV_RANGE_END devid: 01:1f.7 AMD-Vi: DEV_SELECT devid: 00:02.1 flags: 00 AMD-Vi: DEV_SELECT_RANGE_START devid: 02:00.0 flags: 00 AMD-Vi: DEV_RANGE_END devid: 02:1f.7 AMD-Vi: DEV_SELECT devid: 00:02.2 flags: 00 AMD-Vi: DEV_SELECT_RANGE_START devid: 03:00.0 flags: 00 AMD-Vi: DEV_RANGE_END devid: 03:1f.7 AMD-Vi: DEV_SELECT devid: 00:02.3 flags: 00 AMD-Vi: DEV_SELECT_RANGE_START devid: 04:00.0 flags: 00 AMD-Vi: DEV_RANGE_END devid: 04:1f.7 AMD-Vi: DEV_SELECT devid: 00:02.4 flags: 00 AMD-Vi: DEV_SELECT_RANGE_START devid: 05:00.0 flags: 00 AMD-Vi: DEV_RANGE_END devid: 05:1f.7 AMD-Vi: DEV_SELECT devid: 00:02.5 flags: 00 AMD-Vi: DEV_SELECT devid: 06:00.0 flags: 00 AMD-Vi: DEV_SELECT devid: 07:00.0 flags: 00 AMD-Vi: DEV_SELECT_RANGE_START devid: 08:00.0 flags: 00 AMD-Vi: DEV_RANGE_END devid: 08:1f.7 AMD-Vi: DEV_SELECT devid: 07:01.0 flags: 00 AMD-Vi: DEV_SELECT_RANGE_START devid: 09:00.0 flags: 00 AMD-Vi: DEV_RANGE_END devid: 09:1f.7 AMD-Vi: DEV_SELECT devid: 00:02.6 flags: 00 AMD-Vi: DEV_SELECT devid: 0a:00.0 flags: 00 AMD-Vi: DEV_ALIAS_RANGE devid: 0b:00.0 flags: 00 devid_to: 0b:00.0 AMD-Vi: DEV_RANGE_END devid: 0c:1f.7 AMD-Vi: DEV_SELECT devid: 00:02.7 flags: 00 AMD-Vi: DEV_ALIAS_RANGE devid: 0d:00.0 flags: 00 devid_to: 00:02.7 AMD-Vi: DEV_RANGE_END devid: 0d:1f.7 AMD-Vi: DEV_SELECT devid: 00:03.0 flags: 00 AMD-Vi: DEV_SELECT devid: 00:04.0 flags: 00 AMD-Vi: DEV_SELECT devid: 00:1f.0 flags: 00 AMD-Vi: DEV_SELECT devid: 00:1f.2 flags: 00 AMD-Vi: DEV_SELECT devid: 00:1f.3 flags: 00 Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Message-Id: <157187084880.5439.16700585779699233836.stgit@gimli.home> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-11-05pci: Use PCI aliases when determining device IOMMU address spaceAlex Williamson
PCIe requester IDs are used by modern IOMMUs to differentiate devices in order to provide a unique IOVA address space per device. These requester IDs are composed of the bus/device/function (BDF) of the requesting device. Conventional PCI pre-dates this concept and is simply a shared parallel bus where transactions are claimed by decoding target ranges rather than the packetized, point-to-point mechanisms of PCI-express. In order to interface conventional PCI to PCIe, the PCIe-to-PCI bridge creates and accepts packetized transactions on behalf of all downstream devices, using one of two potential forms of a requester ID relating to the bridge itself or its subordinate bus. All downstream devices are therefore aliased by the bridge's requester ID and it's not possible for the IOMMU to create unique IOVA spaces for devices downstream of such buses. At least that's how it works on bare metal. Until now point we've ignored this nuance of vIOMMU support in QEMU, creating a unique AddressSpace per device regardless of the virtual bus topology. Aside from simply being true to bare metal behavior, there are aspects of a shared address space that we can use to our advantage when designing a VM. For instance, a PCI device assignment scenario where we have the following IOMMU group on the host system: $ ls /sys/kernel/iommu_groups/1/devices/ 0000:00:01.0 0000:01:00.0 0000:01:00.1 An IOMMU group is considered the smallest set of devices which are fully DMA isolated from other devices by the IOMMU. In this case the root port at 00:01.0 does not guarantee that it prevents peer to peer traffic between the endpoints on bus 01: and the devices are therefore grouped together. VFIO considers an IOMMU group to be the smallest unit of device ownership and allows only a single shared IOVA space per group due to the limitations of the isolation. Therefore, if we attempt to create the following VM, we get an error: qemu-system-x86_64 -machine q35... \ -device intel-iommu,intremap=on \ -device pcie-root-port,addr=1e.0,id=pcie.1 \ -device vfio-pci,host=1:00.0,bus=pcie.1,addr=0.0,multifunction=on \ -device vfio-pci,host=1:00.1,bus=pcie.1,addr=0.1 qemu-system-x86_64: -device vfio-pci,host=1:00.1,bus=pcie.1,addr=0.1: vfio \ 0000:01:00.1: group 1 used in multiple address spaces VFIO only allows a single IOVA space (AddressSpace) for both devices, but we've placed them into a topology where the vIOMMU expects a separate AddressSpace for each device. On bare metal we know that a conventional PCI bus would provide the sort of aliasing we need here, forcing the IOMMU to consider these devices to be part of a single shared IOVA space. The support provided here does the same for QEMU, such that we can create a conventional PCI topology to expose equivalent AddressSpace sharing requirements to the VM: qemu-system-x86_64 -machine q35... \ -device intel-iommu,intremap=on \ -device pcie-pci-bridge,addr=1e.0,id=pci.1 \ -device vfio-pci,host=1:00.0,bus=pci.1,addr=1.0,multifunction=on \ -device vfio-pci,host=1:00.1,bus=pci.1,addr=1.1 There are pros and cons to this configuration; it's not necessarily recommended, it's simply a tool we can use to create configurations which may provide additional functionality in spite of host hardware limitations or as a benefit to the guest configuration or resource usage. An incomplete list of pros and cons: Cons: a) Extended PCI configuration space is unavailable to devices downstream of a conventional PCI bus. The degree to which this is a drawback depends on the device and guest drivers. b) Applying this topology to devices which are already isolated by the host IOMMU (singleton IOMMU groups) will result in devices which appear to be non-isolated to the VM (non-singleton groups). This can limit configurations within the guest, such as userspace drivers or nested device assignment. Pros: a) QEMU better emulates bare metal. b) Configurations as above are now possible. c) Host IOMMU resources and VM locked memory requirements are reduced in vIOMMU configurations due to shared IOMMU domains on the host and avoidance of duplicate locked memory accounting. Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Message-Id: <157187083548.5439.14747141504058604843.stgit@gimli.home> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-11-04qga: Add "guest-get-memory-block-info" to blacklistBasil Salman
Memory block commands are only supported for linux with sysfs, "guest-get-memory-block-info" was not in blacklist for other cases. Reported on: https://bugzilla.redhat.com/show_bug.cgi?id=1751431 Signed-off-by: Basil Salman <bsalman@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2019-11-04qga-win: network-get-interfaces command name field bug fixBishara AbuHattoum
Network interface name is fetched as an encoded WCHAR array, (wide character), then it is decoded using the guest's CP_ACP Windows code page, which is the default code page as configure in the guest's Windows, then it is returned as a byte array, (char array). As stated in the BZ#1733165, when renaming a network interface to a Chinese name and invoking this command, the returned name field has the (\ufffd) value for each Chinese character the name had, this value is an indication that the code page does not have the decoding information for the given character. This bug is a result of using the CP_ACP code page for decoding which is an interchangeable code page, instead CP_UTF8 code page should be used for decoding the network interface's name. https://bugzilla.redhat.com/show_bug.cgi?id=1733165 Signed-off-by: Bishara AbuHattoum <bishara@daynix.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2019-11-04block/file-posix: Let post-EOF fallocate serializeMax Reitz
The XFS kernel driver has a bug that may cause data corruption for qcow2 images as of qemu commit c8bb23cbdbe32f. We can work around it by treating post-EOF fallocates as serializing up until infinity (INT64_MAX in practice). Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20191101152510.11719-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-11-04block: Add bdrv_co_get_self_request()Max Reitz
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20191101152510.11719-3-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-11-04block: Make wait/mark serialising requests publicMax Reitz
Make both bdrv_mark_request_serialising() and bdrv_wait_serialising_requests() public so they can be used from block drivers. Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20191101152510.11719-2-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-11-04block/block-copy: fix s->copy_size for compressed clusterVladimir Sementsov-Ogievskiy
0e2402452f1f20429 allowed writes larger than cluster, but that's unsupported for compressed write. Fix it. Fixes: 0e2402452f1f20429 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20191029150934.26416-1-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-11-04nvme: fix NSSRS offset in CAP registerKlaus Jensen
Fix the offset of the NSSRS field the CAP register. From NVME 1.4, section 3 ("Controller Registers"), subsection 3.1.1 ("Offset 0h: CAP – Controller Capabilities") CAP_NSSRS_SHIFT is bit 36, not 33. Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Reported-by: Javier Gonzalez <javier.gonz@samsung.com> Message-id: 20191023073315.446534-1-its@irrelevant.dk Reviewed-by: John Snow <jsnow@redhat.com> [mreitz: Added John's note on the location in the specification where this information can be found] Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-11-02Merge remote-tracking branch 'remotes/palmer/tags/palmer-for-master-4.2-sf1' ↵Peter Maydell
into staging Update my MAINTAINERS file entry This contains a single patch to change my email address. # gpg: Signature made Fri 01 Nov 2019 16:14:45 GMT # gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 # gpg: issuer "palmer@dabbelt.com" # gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown] # gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41 * remotes/palmer/tags/palmer-for-master-4.2-sf1: MAINTAINERS: Change to my personal email address Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-02Merge remote-tracking branch ↵Peter Maydell
'remotes/pmaydell/tags/pull-target-arm-20191101-2' into staging target-arm queue: * Support SVE in KVM guests * Don't UNDEF on M-profile 'vmrs apsr_nzcv, fpscr' * Update hflags after boot.c modifies CPU state # gpg: Signature made Sat 02 Nov 2019 10:38:59 GMT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20191101-2: target/arm: Allow reading flags from FPSCR for M-profile hw/arm/boot: Rebuild hflags when modifying CPUState at boot target/arm/kvm: host cpu: Add support for sve<N> properties target/arm/cpu64: max cpu: Support sve properties with KVM target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features target/arm/kvm64: max cpu: Enable SVE when available target/arm/kvm64: Add kvm_arch_get/put_sve target/arm/cpu64: max cpu: Introduce sve<N> properties target/arm: Allow SVE to be disabled via a CPU property tests: arm: Introduce cpu feature tests target/arm/monitor: Introduce qmp_query_cpu_model_expansion Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm: Allow reading flags from FPSCR for M-profileChristophe Lyon
rt==15 is a special case when reading the flags: it means the destination is APSR. This patch avoids rejecting vmrs apsr_nzcv, fpscr as illegal instruction. Cc: qemu-stable@nongnu.org Signed-off-by: Christophe Lyon <christophe.lyon@linaro.org> Message-id: 20191025095711.10853-1-christophe.lyon@linaro.org [PMM: updated the comment] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01hw/arm/boot: Rebuild hflags when modifying CPUState at bootEdgar E. Iglesias
Rebuild hflags when modifying CPUState at boot. Fixes: e979972a6a Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-id: 20191031040830.18800-2-edgar.iglesias@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm/kvm: host cpu: Add support for sve<N> propertiesAndrew Jones
Allow cpu 'host' to enable SVE when it's available, unless the user chooses to disable it with the added 'sve=off' cpu property. Also give the user the ability to select vector lengths with the sve<N> properties. We don't adopt 'max' cpu's other sve property, sve-max-vq, because that property is difficult to use with KVM. That property assumes all vector lengths in the range from 1 up to and including the specified maximum length are supported, but there may be optional lengths not supported by the host in that range. With KVM one must be more specific when enabling vector lengths. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Message-id: 20191031142734.8590-10-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm/cpu64: max cpu: Support sve properties with KVMAndrew Jones
Extend the SVE vq map initialization and validation with KVM's supported vector lengths when KVM is enabled. In order to determine and select supported lengths we add two new KVM functions for getting and setting the KVM_REG_ARM64_SVE_VLS pseudo-register. This patch has been co-authored with Richard Henderson, who reworked the target/arm/cpu64.c changes in order to push all the validation and auto-enabling/disabling steps into the finalizer, resulting in a nice LOC reduction. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Message-id: 20191031142734.8590-9-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init featuresAndrew Jones
kvm_arm_create_scratch_host_vcpu() takes a struct kvm_vcpu_init parameter. Rather than just using it as an output parameter to pass back the preferred target, use it also as an input parameter, allowing a caller to pass a selected target if they wish and to also pass cpu features. If the caller doesn't want to select a target they can pass -1 for the target which indicates they want to use the preferred target and have it passed back like before. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Beata Michalska <beata.michalska@linaro.org> Message-id: 20191031142734.8590-8-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm/kvm64: max cpu: Enable SVE when availableAndrew Jones
Enable SVE in the KVM guest when the 'max' cpu type is configured and KVM supports it. KVM SVE requires use of the new finalize vcpu ioctl, so we add that now too. For starters SVE can only be turned on or off, getting all vector lengths the host CPU supports when on. We'll add the other SVE CPU properties in later patches. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Beata Michalska <beata.michalska@linaro.org> Message-id: 20191031142734.8590-7-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm/kvm64: Add kvm_arch_get/put_sveAndrew Jones
These are the SVE equivalents to kvm_arch_get/put_fpsimd. Note, the swabbing is different than it is for fpsmid because the vector format is a little-endian stream of words. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Message-id: 20191031142734.8590-6-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm/cpu64: max cpu: Introduce sve<N> propertiesAndrew Jones
Introduce cpu properties to give fine control over SVE vector lengths. We introduce a property for each valid length up to the current maximum supported, which is 2048-bits. The properties are named, e.g. sve128, sve256, sve384, sve512, ..., where the number is the number of bits. See the updates to docs/arm-cpu-features.rst for a description of the semantics and for example uses. Note, as sve-max-vq is still present and we'd like to be able to support qmp_query_cpu_model_expansion with guests launched with e.g. -cpu max,sve-max-vq=8 on their command lines, then we do allow sve-max-vq and sve<N> properties to be provided at the same time, but this is not recommended, and is why sve-max-vq is not mentioned in the document. If sve-max-vq is provided then it enables all lengths smaller than and including the max and disables all lengths larger. It also has the side-effect that no larger lengths may be enabled and that the max itself cannot be disabled. Smaller non-power-of-two lengths may, however, be disabled, e.g. -cpu max,sve-max-vq=4,sve384=off provides a guest the vector lengths 128, 256, and 512 bits. This patch has been co-authored with Richard Henderson, who reworked the target/arm/cpu64.c changes in order to push all the validation and auto-enabling/disabling steps into the finalizer, resulting in a nice LOC reduction. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Beata Michalska <beata.michalska@linaro.org> Message-id: 20191031142734.8590-5-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm: Allow SVE to be disabled via a CPU propertyAndrew Jones
Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via a CPU property") we can disable the 'max' cpu model's VFP and neon features, but there's no way to disable SVE. Add the 'sve=on|off' property to give it that flexibility. We also rename cpu_max_get/set_sve_vq to cpu_max_get/set_sve_max_vq in order for them to follow the typical *_get/set_<property-name> pattern. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Beata Michalska <beata.michalska@linaro.org> Message-id: 20191031142734.8590-4-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01tests/fw_cfg: Test 'reboot-timeout=-1' special valuePhilippe Mathieu-Daudé
The special value -1 means "don't reboot" for QEMU/libvirt. Add a trivial test. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-11-01fw_cfg: Allow reboot-timeout=-1 againDr. David Alan Gilbert
Commit ee5d0f89de3e53cdb0dc added range checking on reboot-timeout to only allow the range 0..65535; however both qemu and libvirt document the special value -1 to mean don't reboot. Allow it again. Fixes: ee5d0f89de3e53cdb0dc ("fw_cfg: Fix -boot reboot-timeout error checking") RH bz: https://bugzilla.redhat.com/show_bug.cgi?id=1765443 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20191025165706.177653-1-dgilbert@redhat.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <37ac197c-f20e-dd05-ff6a-13a2171c7148@redhat.com> [PMD: Applied Laszlo's suggestions] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-11-01MAINTAINERS: Change to my personal email addressPalmer Dabbelt
I'm leaving SiFive in a bit less than two weeks, which means I'll be losing my @sifive email address. I don't have my new email address yet, so I'm switching over to my personal address. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2019-11-01tests: arm: Introduce cpu feature testsAndrew Jones
Now that Arm CPUs have advertised features lets add tests to ensure we maintain their expected availability with and without KVM. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20191031142734.8590-3-drjones@redhat.com [PMM: squash in fix to avoid failure on aarch32-compat] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01target/arm/monitor: Introduce qmp_query_cpu_model_expansionAndrew Jones
Add support for the query-cpu-model-expansion QMP command to Arm. We do this selectively, only exposing CPU properties which represent optional CPU features which the user may want to enable/disable. Additionally we restrict the list of queryable cpu models to 'max', 'host', or the current type when KVM is in use. And, finally, we only implement expansion type 'full', as Arm does not yet have a "base" CPU type. More details and example queries are described in a new document (docs/arm-cpu-features.rst). Note, certainly more features may be added to the list of advertised features, e.g. 'vfp' and 'neon'. The only requirement is that we can detect invalid configurations and emit failures at QMP query time. For 'vfp' and 'neon' this will require some refactoring to share a validation function between the QMP query and the CPU realize functions. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Beata Michalska <beata.michalska@linaro.org> Message-id: 20191031142734.8590-2-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-31Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into stagingPeter Maydell
Pull request # gpg: Signature made Thu 31 Oct 2019 15:55:44 GMT # gpg: using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [full] # Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB # Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E * remotes/jnsnow/tags/ide-pull-request: hd-geo-test: Add tests for lchs override bootdevice: FW_CFG interface for LCHS values bootdevice: Refactor get_boot_devices_list bootdevice: Gather LCHS from all relevant devices scsi: Propagate unrealize() callback to scsi-hd bootdevice: Add interface to gather LCHS block: Support providing LCHS from user block: Refactor macros - fix tabbing IDE: deprecate ide-drive Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-31hd-geo-test: Add tests for lchs overrideSam Eiderman
Add QTest tests to check the logical geometry override option. The tests in hd-geo-test are out of date - they only test IDE and do not test interesting MBRs. Creating qcow2 disks with specific size and MBR layout is currently unused - we only use a default empty MBR. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> Signed-off-by: Sam Eiderman <sameid@google.com> Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-31bootdevice: FW_CFG interface for LCHS valuesSam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS. Non-standard logical geometries break under QEMU. A virtual disk which contains an operating system which depends on logical geometries (consistent values being reported from BIOS INT13 AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard logical geometries - for example 56 SPT (sectors per track). No matter what QEMU will report - SeaBIOS, for large enough disks - will use LBA translation, which will report 63 SPT instead. In addition we cannot force SeaBIOS to rely on physical geometries at all. A virtio-blk-pci virtual disk with 255 phyiscal heads cannot report more than 16 physical heads when moved to an IDE controller, since the ATA spec allows a maximum of 16 heads - this is an artifact of virtualization. By supplying the logical geometries directly we are able to support such "exotic" disks. We serialize this information in a similar way to the "bootorder" interface. The new fw_cfg entry is "bios-geometry". Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> Signed-off-by: Sam Eiderman <sameid@google.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-31bootdevice: Refactor get_boot_devices_listSam Eiderman
Move device name construction to a separate function. We will reuse this function in the following commit to pass logical CHS parameters through fw_cfg much like we currently pass bootindex. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> Signed-off-by: Sam Eiderman <sameid@google.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-31bootdevice: Gather LCHS from all relevant devicesSam Eiderman
Relevant devices are: * ide-hd (and ide-cd, ide-drive) * scsi-hd (and scsi-cd, scsi-disk, scsi-block) * virtio-blk-pci We do not call del_boot_device_lchs() for ide-* since we don't need to - IDE block devices do not support unplugging. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> Signed-off-by: Sam Eiderman <sameid@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-31scsi: Propagate unrealize() callback to scsi-hdSam Eiderman
We will need to add LCHS removal logic to scsi-hd's unrealize() in the next commit. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> Signed-off-by: Sam Eiderman <sameid@google.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-31bootdevice: Add interface to gather LCHSSam Eiderman
Add an interface to provide direct logical CHS values for boot devices. We will use this interface in the next commits. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> Signed-off-by: Sam Eiderman <sameid@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-31block: Support providing LCHS from userSam Eiderman
Add logical geometry variables to BlockConf. A user can now supply "lcyls", "lheads" & "lsecs" for any HD device that supports CHS ("cyls", "heads", "secs"). These devices include: * ide-hd * scsi-hd * virtio-blk-pci In future commits we will use the provided LCHS and pass it to the BIOS through fw_cfg to be supplied using INT13 routines. Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com> Signed-off-by: Sam Eiderman <sameid@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-31iotests: Remove 130 from the "auto" groupThomas Huth
Peter hit a "Could not open 'TEST_DIR/t.IMGFMT': Failed to get shared 'write' lock - Is another process using the image [TEST_DIR/t.IMGFMT]?" error with 130 already twice. Looks like this test is a little bit shaky, and currently nobody has a real clue what could be causing this issue, so for the time being, let's disable it from the "auto" group so that it does not gate the pull requests. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-31Merge remote-tracking branch ↵Peter Maydell
'remotes/stsquad/tags/pull-testing-next-311019-1' into staging Fixes to get CI green again - fix m68k acceptance tests (Cleber) - stop build breakage (Daniel) # gpg: Signature made Thu 31 Oct 2019 10:00:53 GMT # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-testing-next-311019-1: Acceptance test: update kernel for m68k/q800 test Acceptance test: cancel test if m68k kernel packages goes missing tests: fix conditional for disabling XTS test Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 09:55:28 +0000