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 _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx