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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list