[libvirt] [PATCH 8/9] qemu: domain: Reflect USB controller model in guest XML

[Andrea Bolognani]

On Thu, 2016-08-04 at 14:32 +0200, Ján Tomko wrote:
> > +        } else if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
> > +                   cont->model == -1) {
> > +            /* Pick a suitable default model for the USB controller if none
> > +             * has been selected by the user.
> > +             *
> > +             * We rely on device availability instead of setting the model
> > +             * unconditionally because, for some machine types, there's a
> > +             * chance we will get away with using the legacy USB controller
> > +             * when the relevant device is not available.
> > +             *
> > +             * See qemuBuildControllerDevCommandLine() */
> > +            if (ARCH_IS_PPC64(def->os.arch)) {
> > +                /* Default USB controller for ppc64 is pci-ohci */
> > +                if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_PCI_OHCI))
> > +                    cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_PCI_OHCI;
> 
> <thinking_out_loud>
> 
> So, if I understand correctly, if we left the model for PPC64 at -1:
> [A] before 8156493 Fix USB model defaults for ppc64 [v1.3.1-rc1~47]
>   we pass -usb on the command line, drop the controller from migration
>   XML and possibly re-add it on the destination
> [B] after that commit
>   we pass -device pci-usb-ohci, lose that information in migration
> [C] after 192a53e0 send default USB controller in xml [v1.3.5-rc1~459]
>   We use -device pci-usb-ohci, passing the address to the
>   destination
> 
> Migration between [A] and anything else is AFAIK broken since the
> address used by -usb never matches the one we pick for the -device,
> https://bugzilla.redhat.com/show_bug.cgi?id=1357468
> 
> Migration between [C] and [B] should just work as long as hotplugging
> did not change the order of the devices and the controller auto-added on
> the destination gets the same address as the one that was removed.

You mean between [B] and [C]? When migrating between [C] and
[B], the destination will receive the <controller> element,
including the PCI address, so it should have no problem just
using it.

> </thinking_out_loud>
> 
> Is it possible to create a -device syntax that will match the -usb
> command line generated by [A] (e.g. by specifying a 0000:00.00 PCI
> addr)?

Yes, something like

  -device pci-ohci,id=usb,bus=pci.0,addr=0x0

will work for QEMU, but we have no way of representing that in
the guest configuration:

  <address type='pci'
           domain='0x0000' bus='0x00'
           slot='0x00' function='0x0'/>

will result in libvirt assigning a new PCI address for the
device in recent libvirt versions, and an outright error in
older libvirt versions, including [A].

Assuming that we made it possible to specify such an address,
it would be impossible for the target of the migration to make
out whether the migration is coming from [A] or [B] - one of
the two would be broken anyway.

> This change should fix migration from [B] and [C] and back:
> * model=-1 coming from those hosts will get adjusted to OHCI on parsing
> * we should not format model=-1 when migrating back to those hosts

Migration between [B] and [C] should already work in both
directions AFAICT. Can you give me an example where it
wouldn't?

> > +            } else {
> > +                /* Default USB controller for anything else is piix3-uhci */
> > +                if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_PIIX3_USB_UHCI))
> > +                    cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_PIIX3_UHCI;
> 
> For non-PPC64, migration was not broken before.
> 
> Ancient QEMUs not supporting QEMU_CAPS_PIIX3_USB_UHCI will still get
> model=-1 (or not, I doubt anyone will run new libvirt with them).
> Should we set it unconditionally for i440fx machines?
> Everything else gets the model changed to PIIX3-UHCI.

I think we still want to make a last-ditch effort to provide
some sort, any sort, of USB controller. Or rather, that we
have to. Honestly, I'd rather just drop the -usb handling
altogether and expect users not to mix modern-day libvirt
with QEMU versions from 5+ years ago.

> Of course, this breaks migration to pre-0.9.x libvirt which did not
> support USB controllers. I am okay with that, but you might want to get
> a second opinion on that.

How far back can you reasonably expect to migrate a guest? How
would you even migrate a guest that uses USB controllers to a
version of libvirt that doesn't support USB controllers?

-- 
Andrea Bolognani / Red Hat / Virtualization