On Fri, Oct 03, 2025 at 09:11:26AM +0200, Peter Krempa wrote: > On Thu, Sep 25, 2025 at 20:07:13 +0200, Andrea Bolognani via Devel wrote: > > Right now we call qemuValidateDomainDeviceDefControllerUSB() > > quite late, just as we're generating the QEMU command line. > > > > The original intention was likely to prevent configurations > > from being rejected, even though a default USB controller > > model could not be found, because using -usb could be used > > as a last resort. > > > > As it turns out, this premise was always flawed: in order > > for -usb to work, the underlying device still needs to be > > compiled into QEMU, and if that was the case then the > > earlier code would have detected its presence and set the > > model name accordingly. > > > > More recently, we have dropped the use of -usb altogether > > so there's simply no longer anything to fall back to. > > > > With all this in mind, we can move the validation step much > > earlier, making for a better user experience as any issues > > will be reported when the domain is defined rather than when > > an attempt is made to start it. > > Conceptually I agree with this move. My quesion is only how the machine > types with native USB that can exist are handled with this code. > > I'm going to assume that this patch doesn't change libvirts behaviour > wrt. the above machines
For those machine types the USB native controller was never modelled at the libvirt level; attempts to add a USB controller would result in a PCI controller being picked, which QEMU would promptly refuse due to the lack of PCI in the machine type. So all that will change here is that the error message is going to be reported earlier. Thank you for all your help getting this cleanup done! -- Andrea Bolognani / Red Hat / Virtualization
