On Tue, Aug 19, 2025 at 18:22:12 +0200, Andrea Bolognani via Devel wrote:
These tests are intended to show what happens when the device that libvirt would use by default is not available in QEMU by dropping the corresponding capabilities, but we're not doing that correctly at the moment and so we still get the default USB controller instead of a failure.
Do I understand correctly (from the diff) that the "incorrect" approach is that the tests copied the list of the controllers to remove from the x86 cases and thus the aarch tests still picked the default they'd pick normally? Preferrably clarify this in the commit message.
Note that the usb-controller-automatic-unavailable tests are still behaving the same despite dropping all the expected capabilities: the reason is that, for that scenario, we're not currently checking whether the device is available before using it. That's a separate issue that will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> ---
[...]
diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c index dea8b1af14..26afdf7a7e 100644 --- a/tests/qemuxmlconftest.c +++ b/tests/qemuxmlconftest.c @@ -1944,7 +1944,7 @@ mymain(void) ARG_CAPS_ARCH, "armv7l", ARG_CAPS_VER, "latest", ARG_FLAGS, FLAG_EXPECT_FAILURE, - ARG_QEMU_CAPS_DEL, QEMU_CAPS_PCI_OHCI, QEMU_CAPS_LAST, + ARG_QEMU_CAPS_DEL, QEMU_CAPS_DEVICE_QEMU_XHCI, QEMU_CAPS_NEC_USB_XHCI, QEMU_CAPS_PIIX3_USB_UHCI, QEMU_CAPS_PCI_OHCI, QEMU_CAPS_LAST, ARG_END);
Alternatively shouldn't this keep some of the non-default ones if the we're selecting another option? Reviewed-by: Peter Krempa <pkrempa@redhat.com>