Re: [PATCH] qemu: Use legacy USB on ppc64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2016-07-20 at 14:17 +0100, Daniel P. Berrange wrote:
> On Tue, Jul 19, 2016 at 07:04:36PM +0200, Andrea Bolognani wrote:
> > 
> > On Tue, 2016-07-19 at 16:17 +0200, Andrea Bolognani wrote:
> > > 
> > > Commit 8156493d8db9 changed libvirt so that '-device pci-ohci'
> > > would be used instead of '-usb' on ppc64 when no specific USB
> > > controller model had been specified in the guest configuration.
> > >  
> > > While the device that ends up being presented by the guest is
> > > exactly the same, '-usb' causes it to be assigned to PCI address
> > > 00:00.0 while '-device pci-ohci', being subject to the regular
> > > PCI address assignment logic, will be at a different address.
> > >  
> > > This PCI address mismatch breaks migration of existing guests
> > > to new libvirt versions.
> > >  
> > > Luckily, when QEMU has switched its default '-usb' controller
> > > from pci-ohci to nec-usb-xhci (QEMU commit 57040d451315), it
> > > has done so without affecting older machine types, which means
> > > we can keep using '-usb' without risking guest ABI breakage.
> > >  
> > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1357468
> > > ---
> > >   src/qemu/qemu_command.c                                       | 8 +++++---
> > >   tests/qemuxml2argvdata/qemuxml2argv-ppc64-usb-controller.args | 2 +-
> > >   tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-default.args  | 2 +-
> > >   3 files changed, 7 insertions(+), 5 deletions(-)
> > 
> > Ján pointed out that applying this would un-break migration
> > for ppc64 guests created before 8156493d8db9, but at the
> > same time break migration for those created since, eg. in
> > the last ~6 months.
> > 
> > I'm kinda out of ideas here, so if anyone has a brilliant
> > plan to make migration work for both old and new guests,
> > please do share :)
> 
> It seems that we could solve this by just changing the logic in
> qemuDomainAssignDevicePCISlots() so that when it is auto-assigning
> addresses, it always uses 00:00.0 for the USB controller when guest
> arch is ppc64.
> 
> Existing guests deployed from a libvirt version using -device won't
> be affected, because we'll have recorded a PCI address for that
> in the XML and continue to use that. ie the auto-allocation logic
> won't run for them.
> 
> Existing guests deployed from a libvirt version using -usb should
> then get the fixed PCI address of 00:00.0 when they upgrade to the
> fix libvirt (assuming they didn't get run with a broken libvirt
> in between).

Mh, that could actually work! Thanks :)

I'll try to cook up a patch tomorrow.

> Regardless though, I'm very much against any change that tales us
> back to using -usb. This is long since obsolete syntax we should
> aim to never use - bringing ppc inline with other arches using
> -device is very much desirable.

Agreed - that was the reasoning behind the original, sadly
flawed, attempt to get rid of it.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]