[libvirt] [PATCH v2 1/6] tests: qemuxml2argv: remove some QEMU_CAPS_DEVICE problem cases

[Andrea Bolognani]

On Wed, 2016-02-10 at 11:21 +0100, Martin Kletzander wrote:
> > > > > Why did I think that we had eliminated all use of "-usb"? Is it that we're
> > > > > currently only using it in the tests? If so, that's another thing to eliminate
> > > > > - we should never be using -usb unless that's the only way to get a usb device
> > > > > for a particular qemu (and I don't know that that is *ever* the case).
> > > > > 
> > > > The qemu_command.c chunk is:
> > > > 
> > > >      if (usbcontroller == 0 &&
> > > >          !qemuDomainMachineIsQ35(def) &&
> > > >          !ARCH_IS_S390(def->os.arch))
> > > >          virCommandAddArg(cmd, "-usb")
> > > > 
> > > > Where usbcontroller == 0 if we didn't build a -device string for a USB
> > > > controller. I'd need to dig into qemu to figure out what -usb actually maps to
> > > > to determine if that makes sense anymore
> > > 
> > > Okay, that's what I remember. usbcontroller will only be 0 if there was no
> > > <controller type='usb'/> in the xml, and that shouldn't happen because the
> > > post-parse will add a usb controller if there isn't any (except in a few cases
> > > - see qemuDomainDefAddDefaultDevices). So is the post-parse not happening for
> > > the qemuxml2argvtest? (there are dozens and dozens of "-usb" in the *.args files)
> > 
> > PostParse is triggered automatically via DomainDefParse. You can see in the
> > qemuxml2xml output that there's a USB controller added.
> > 
> > Looking deeper, that usbcontroller bit is only set if QEMU_CAPS_PIIX3_USB_UHCI
> > is available, otherwise it uses legacyusb aka -usb. Maybe that's another flag
> > that we can assume is available unconditionally for the qemu we support, I'd
> > need to dig a bit
> 
> Just my two cents here.  I remember that we were dealing with this
> because of ppc64 with Andrea and I think we are using '-usb' in one
> particular case even when there is the option to specify it as a
> device.  That case is when we know the default usb controller that used
> to be added with '-usb' and that particular controller is not available
> (listed) in the list of devices, so to keep the guest ABI the same, we
> fallback to '-usb' because we have no other way to do that.  However,
> this will be a problem in the future when qemu changes the default
> controller added with -usb.  That's just another rabbit hole I don't
> want to go too deep in.  Maybe Andrea already knows more and started
> doing something with it.  Andrea?

The idea in the current code is pretty much: we know what kind of USB
controller would '-usb' would add (pci-ohci for ppc64, piix3-uhci for
everything else), so if that device is available in QEMU we can just
use explicit '-device'. If it isn't, we drop to legacy '-usb'.

As we discussed when we were fixing that code, I'm not sure that the
current approach really buys us much: if we know what controller
'-usb' would add to the host, and we've detected that device is not
available in QEMU, what's the point of adding '-usb' at all?

The only situation I can think of in which this approach actually
helps is when QEMU changes the default controller model associated
with '-usb', which I believe is going to happen on ppc64 to move
from OHCI to XHCI. But then again that's not going to be very good
for guest ABI stability, is it?

I guess the idea is to make a last-ditch effort to provide some
sort of USB controller, any sort of USB controller, to the guest
even though to the best of libvirt's knowledge the support just
isn't there.

So this is the current situation AFAIK. Suggestions on how to
improve it are very welcome :)

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team