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(a)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(a)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