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

[Andrew Jones]

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