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 <[email protected]> > --- > 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.
