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