On Fri, Jun 17, 2016 at 06:51:34PM +0200, Andrea Bolognani wrote: > 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. Thumbs up. -usb should probably even be removed from QEMU. The help text says -usb enable the USB driver (will be the default soon) I got tired of trying to hunt down the commit that added the 'default soon' stuff since it's so old... drew > > -- > Andrea Bolognani > Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list