Re: [libvirt] [PATCH] qemu: Don't use legacy USB for aarch64 mach-virt guests

On Fri, 2016-06-17 at 11:20 -0400, Laine Stump wrote: > On 06/17/2016 09:20 AM, Andrea Bolognani wrote: > > The '-usb' option doesn't have any effect for aarch64 mach-virt > > guests, >  > Do you mean that having -usb on the commandline doesn't result in a usb  > controller? qemu should also be giving an error then... That's what it looks like to me. No USB controller is visible from the guest, and running 'info qtree' in the QEMU console doesn't yield anything that looks like a USB controller. Plus, if you try and add something like   <input type='mouse' bus='usb'/> QEMU will complain loudly about the lack of a USB host controller and refuse to start the guest. > >   so the fact that it's currently enabled by default is not > > really causing any issue. > >  > > However, that might change in the future (although unlikely), and > > having it as part of the QEMU command line can cause confusion to > > someone looking through the process list. > >  > > Avoid it completely, like it's already happening for q35. >  > I've forgotten if this was intended to solve some problem, or if it's  > just a side-effect of the fact that a libvirt Q35 config originally  > didn't add any usb controller by default. Everything around the "add a  > 'default' usb controller by default if none is specified" has always  > been so mixed up anyway. It's really too bad we have to keep all that  > cruft around just for backwards compatibility with something that we  > decided was a bad idea 5 or 6 years ago) >  >  > At any rate,  again (as with your earlier "eliminate the PCI controllers  > patch" which I'm reviewing now) you are using qemuDomainMachineIsVirt(),  > which doesn't check the arch, but only machinetype (and so would match  > on virt for any other arch). But in this case I think any arch modern  > enough to have a virt machinetype is also modern enough that we won't  > want "-usb" (personally I think that any USB controller added to any  > guest should always have the controller model fully specified, so we  > really should eliminate any possibility of "-usb" everywhere unless  > there is some odd arch that has no other way to add a USB controller. I vehemently agree. The domain XML should be a *faithful* and *complete* representation of the guest hardware - if a certain machine type includes a USB controller that the user can't remove, then the domain XML should include an element representing that controller. If no such element is present, then the guest should have no USB controllers. Of course it's not as simple as that, because of the compatibility requirements you mentioned above :( But I plan to rewrite qemuBuildControllerDevCommandLine() so that it enables legacy USB on a /whitelist/ basis instead of a /blacklist/ basis. If I can get it to work, at leas we'll be sure no future machine type will end up enabling legacy USB just because we forgot to esplicitly blacklist it. > ACK from me. Great, thanks! I'll wait for Drew's thumbs up before actually pushing this, though.

--  Andrea Bolognani Software Engineer - Virtualization Team