On Wed, Jan 17, 2024 at 10:54:39 +0100, Andrea Bolognani wrote:
All of these are either a subset of other tests, or provide
coverage for scenarios that are not really possible: for all
versions of QEMU that we support, the virt machine type has a
hard dependency on the generic PCIe controller, which means
that we will never need to fall back to virtio-mmio.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
...ch64-aavmf-virtio-mmio.aarch64-latest.args | 46 ---------------
.../aarch64-aavmf-virtio-mmio.xml | 49 ----------------
...rch64-virt-virtio-MMIO.aarch64.latest.args | 48 ----------------
.../arm-virt-virtio.aarch64-latest.args | 54 ------------------
tests/qemuxml2argvdata/arm-virt-virtio.xml | 45 ---------------
.../riscv64-virt-pci.riscv64-latest.args | 35 ------------
tests/qemuxml2argvdata/riscv64-virt-pci.xml | 24 --------
.../riscv64-virt.riscv64-latest.args | 38 -------------
tests/qemuxml2argvdata/riscv64-virt.xml | 19 -------
tests/qemuxml2argvtest.c | 18 ------
...rch64-aavmf-virtio-mmio.aarch64-latest.xml | 56 -------------------
tests/qemuxml2xmltest.c | 4 --
12 files changed, 436 deletions(-)
delete mode 100644 tests/qemuxml2argvdata/aarch64-aavmf-virtio-mmio.aarch64-latest.args
delete mode 100644 tests/qemuxml2argvdata/aarch64-aavmf-virtio-mmio.xml
delete mode 100644 tests/qemuxml2argvdata/aarch64-virt-virtio-MMIO.aarch64.latest.args
delete mode 100644 tests/qemuxml2argvdata/arm-virt-virtio.aarch64-latest.args
delete mode 100644 tests/qemuxml2argvdata/arm-virt-virtio.xml
delete mode 100644 tests/qemuxml2argvdata/riscv64-virt-pci.riscv64-latest.args
delete mode 100644 tests/qemuxml2argvdata/riscv64-virt-pci.xml
delete mode 100644 tests/qemuxml2argvdata/riscv64-virt.riscv64-latest.args
delete mode 100644 tests/qemuxml2argvdata/riscv64-virt.xml
delete mode 100644 tests/qemuxml2xmloutdata/aarch64-aavmf-virtio-mmio.aarch64-latest.xml
-
- /* test default config if pcie bus is not available */
- DO_TEST_FULL("aarch64-virt-virtio", "-MMIO.aarch64.latest",
- ARG_CAPS_ARCH, "aarch64",
- ARG_CAPS_VER, "latest",
- ARG_QEMU_CAPS_DEL,
- QEMU_CAPS_OBJECT_GPEX, QEMU_CAPS_DEVICE_PCI_BRIDGE,
- QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE, QEMU_CAPS_DEVICE_IOH3420,
- QEMU_CAPS_LAST, ARG_END);
DO_TEST_CAPS_ARCH_VER("aarch64-virt-virtio", "aarch64",
"4.2.0");
DO_TEST_CAPS_ARCH_LATEST("aarch64-virt-virtio", "aarch64");
@@ -2526,13 +2515,6 @@ mymain(void)
DO_TEST_CAPS_LATEST("vhost-user-fs-hugepages");
DO_TEST_CAPS_LATEST_PARSE_ERROR("vhost-user-fs-readonly");
- /* The generic pcie bridge emulation device can be compiled out of qemu. */
- DO_TEST_CAPS_ARCH_LATEST_FULL("riscv64-virt", "riscv64",
- ARG_QEMU_CAPS_DEL,
- QEMU_CAPS_OBJECT_GPEX,
- QEMU_CAPS_LAST);
I'm not sure about riscv64, but I'm fairly sure we do support non-virt
arm machines and it seems that GPEX can be compiled out if you compile
out that machine.
Arguably that would be an insane configuration and might not be worth
worrying about, but we had tests for it. Would it make sense to switch
to a different machine type?