[libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
Eduardo Habkost
ehabkost at redhat.com
Tue Nov 20 11:51:02 UTC 2018
On Tue, Nov 20, 2018 at 11:52:27AM +0100, Cornelia Huck wrote:
> On Mon, 19 Nov 2018 22:44:54 -0200
> Eduardo Habkost <ehabkost at redhat.com> wrote:
>
> > On Thu, Nov 15, 2018 at 11:50:56AM +0100, Cornelia Huck wrote:
> > > On Thu, 15 Nov 2018 10:05:59 +0000
> > > Daniel P. Berrangé <berrange at redhat.com> wrote:
>
> > > > If libvirt did this compatibility approach, can you
> > > > confirm this would be live migration state compatible.
> > > >
> > > > ie can live migrate virtio-*-pci -> virtio-*-pci-transitional,
> > > > provided only PCI bus was used.
> > >
> > > It also needs to make sure that neither disable-legacy nor
> > > disable-modern is set. Then this would have a compatible state AFAICS.
> > >
> > > >
> > > > > - virtio-*-pci-non-transitional: modern-only
> > > > > - Supports both Conventional PCI and PCI Express buses
> > > >
> > > > IIUC, libvirt can again provide compatibility with old
> > > > QEMU by simply using the existing device type and setting
> > > > disable-legacy ? Can you confirm this would be live
> > > > migration compatible
> > > >
> > > > virtio-*-pci + disable-legacy -> virtio-*pci-non-transitional
> > >
> > > I think yes.
> >
> > This is exactly how it is implemented internally, but I'm not
> > promising that this will be kept compatible forever. And I
> > wouldn't like to make that promise unless there's an important
> > use case for that.
>
> Shouldn't we be able to ensure compatibility by normal virtio feature
> bit handling, as we have already done in the past?
Ensuring compatibility is possible, and even likely. I just want
to avoid spending effort keeping such a promise unless it's
really necessary.
>
> >
> > We could easily ensure it will be compatible in pc-4.0 and older,
> > though. Would that be enough for the use case we have in mind?
> >
>
--
Eduardo
More information about the libvir-list
mailing list