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