Re: [PATCH v2 11/17] qemu: Validate USB controllers earlier
On Fri, Feb 16, 2024 at 03:54:00PM +0100, Peter Krempa wrote:
I went through qemu to see were the '-usb' is actually used.
Thanks for the excellent analysis!
Then there are machines which create the default controller via:
pci_create_simple(pci_bus, -1, "pci-ohci");
This is the case for:
hw/arm/realview.c
hw/arm/versatilepb.c
hw/ppc/mac_oldworld.c
hw/ppc/mac_newworld.c
and hw/ppc/spapr.c:
uses
pci_create_simple(phb->bus, -1, "pci-ohci");
or
pci_create_simple(phb->bus, -1, "nec-usb-xhci");
both of which our code should be able to detect and use properly at
least after some tweaking.
Currently we don't seem to ever consider 'pci-ohci' as the last resort
controller type for any of the above machines.
No tweaking necessary for pseries, I think: we already check both
before giving up and falling back to the default USB controller.
I think that the path forward for everything except 'microvm'
is to add
'pci-ohci' as last resort USB controller.
The question now is whether we care about microvm. Specifically dropping
'-usb' will most likely cause migration incompatibility.
If we decide that we do care about 'microvm's USB controller then we'll
need to keep adding it via the machine property (so that we can at least
drop all the legacy '-usb' stuff). At that point we should also fix the
implicit bus name.
I think it's completely fine to ignore any concerns about breaking
migration for microvm on account of several facts:
* we don't have formal support for it, and specifically there is
zero test coverage to ensure that it doesn't break as a
consequence of any random change;
* it's a minimal machine designed for fast-booting, minimal guests,
which makes it unlikely that anyone would want to use USB with
it;
* for the reason above, anyone interested in microvm will probably
use QEMU directly to further minimize the overhead;
* as noted, the default USB controller is unusable anyway;
* it's not a versioned machine type, which means that ABI
stability is not guaranteed at the QEMU level.
I could probably come up with a few more, but I think that would be
overkill :)
I agree with making pci-ohci a last resort fallback for the arm and
ppc machine types you've identified. I would not make the fallback
apply more widely though, as that might result in it being selected
for machine types that can't actually use it (e.g. arm machines
without PCI support). In that case, an early failure will probably be
preferable.
I've also added some tests for the versatilepb machine to see
what we
generate, those might make sense to be merged before this.
Please post them, I'll take care of reviewing.
--
Andrea Bolognani / Red Hat / Virtualization