On Tue, Aug 19, 2025 at 18:22:33 +0200, Andrea Bolognani via Devel wrote:
This is another case where the current behavior can be traced back to the fact that x86 was the only architecture to really be taken into account for a long time: in reality, using an Intel-specific USB1 controller for a modern, PCIe-native, virtualization-friendly Arm guest just doesn't make any sense.
Remove this fallback. All virt machine types now behave the same across architectures.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- src/qemu/qemu_domain.c | 1 + ...default-fallback-virt-aarch64.aarch64-latest.args | 5 ++--- ...-default-fallback-virt-aarch64.aarch64-latest.xml | 12 ++++-------- tests/qemuxmlconftest.c | 4 ++-- 4 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 529acefbd7..df64ddbec1 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4322,6 +4322,7 @@ qemuDomainDefaultUSBControllerModel(const virDomainDef *def, bool abiUpdate = !!(parseFlags & VIR_DOMAIN_DEF_PARSE_ABI_UPDATE);
if (ARCH_IS_LOONGARCH(def->os.arch) || + qemuDomainIsARMVirt(def) || qemuDomainIsRISCVVirt(def)) { /* Use USB3 for modern architectures */ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_QEMU_XHCI))
I agree with using the same code as long as it doesn't require the NEC controller in the fallback path. If the aarch virt machine requires it, have a separate branch for it, but adding a pointless fallback to other arches doesn't make it worth.