Re: Re: [PATCH 06/18] tests: Drop various redundant tests
On Wed, Jan 17, 2024 at 01:18:55PM +0100, Peter Krempa wrote:
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.
>
> - /* 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);
>
> - /* 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.
You're right in saying that it's possible to obtain a GPEX-less
aarch64 QEMU binary by compiling out the virt machine type.
However, the only way in which we actually use the capability outside
of the test suite is to decide whether the virt machine is capable of
PCI, for which the answer is always "yes".
The remaining usages, in the test suite, are there to confirm that
the virt machine type will fall back to virtio-mmio is PCI is not
available. But that's no longer a scenario that can present itself,
as demonstrated by the fact that we have to go way out of our way to
trick libvirt into behaving that way, so why have coverage?
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?
The original tests were introduced at a time when we still supported
versions of QEMU where the virt machine type wasn't PCI capable. They
made sense at the time, but that's no longer the case today.
With regards to other machine types, we already have some coverage
showing how libvirt handles the absence of PCI support: specifically
arm-vexpressa9-* and disk-arm-virtio-sd. That seems good enough to
me.
--
Andrea Bolognani / Red Hat / Virtualization