From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Cornelia Huck" <cohuck@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, Gonglei <arei.gonglei@huawei.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Amit Shah" <amit@kernel.org>,
"Andrea Bolognani" <abologna@redhat.com>,
"Cleber Rosa" <crosa@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Fam Zheng" <famz@redhat.com>, "Kevin Wolf" <kwolf@redhat.com>,
"Max Reitz" <mreitz@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
libvir-list@redhat.com, "Markus Armbruster" <armbru@redhat.com>,
"Laine Stump" <laine@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Caio Carrara" <ccarrara@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices
Date: Tue, 20 Nov 2018 10:46:05 +0000 [thread overview]
Message-ID: <20181120104605.GF25047@redhat.com> (raw)
In-Reply-To: <20181120004454.GA4755@habkost.net>
On Mon, Nov 19, 2018 at 10:44:54PM -0200, Eduardo Habkost 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@redhat.com> wrote:
> >
> > > On Wed, Nov 14, 2018 at 09:38:31PM -0200, Eduardo Habkost wrote:
> > > > Many of the current virtio-*-pci device types actually represent
> > > > 3 different types of devices:
> > > > * virtio 1.0 non-transitional devices
> > > > * virtio 1.0 transitional devices
> > > > * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
> > > >
> > > > That would be just an annoyance if it didn't break our device/bus
> > > > compatibility QMP interfaces. With this multi-purpose device
> > > > type, there's no way to tell management software that
> > > > transitional devices and legacy devices require a Conventional
> > > > PCI bus.
> > > >
> > > > The multi-purpose device types would also prevent us from telling
> > > > management software what's the PCI vendor/device ID for them,
> > > > because their PCI IDs change at runtime depending on the bus
> > > > where they were plugged.
> > > >
> > > > This patch adds separate device types for each of those virtio
> > > > device flavors:
> > > >
> > > > - virtio-*-pci: the existing multi-purpose device types
> > > > - Configurable using `disable-legacy` and `disable-modern`
> > > > properties
> > > > - Legacy driver support is automatically enabled/disabled
> > > > depending on the bus where it is plugged
> > > > - Supports Conventional PCI and PCI Express buses
> > > > (but Conventional PCI is incompatible with
> > > > disable-legacy=off)
> > > > - Changes PCI vendor/device IDs at runtime
> > > > - virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
> >
> > It's a virtio-1 (not 1.0) device. Otherwise, I like this terminology
> > better.
> >
> > > > - Supports Conventional PCI buses only, because
> > > > it has a PIO BAR
> > >
> > > Am I right in thinking that this is basically identical
> > > to virtio-*-pci, aside from only being valid for PCI
> > > buses ?
> > >
> > > IOW, libvirt can expose this device even if QEMU does
> > > not support it, by simply using the existing device
> > > type and only ever placing it in a PCI bus ?
> > >
> > > 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.
>
> 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?
I guess that as long as it is compat in all existing machine types,
it doesn't matter what new machine types do.
Libvirt would only use the back compat stuff with QEMU < 4.0, in
which case you can guarantee a machine type < pc-4.0. If libvirt
saw a QEMU >= 4.0, it would never use the back compat approach,
so it wouldn't matter if >= pc-4.0 were not compatible. ie for
live migration it would be a case of
QEMU-3.1 + pc-3.1 -----> QEMU_4.0 + pc-3.1
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2018-11-20 10:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-14 23:38 [Qemu-devel] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices Eduardo Habkost
2018-11-15 8:40 ` no-reply
2018-11-15 10:05 ` Daniel P. Berrangé
2018-11-15 10:50 ` Cornelia Huck
2018-11-15 10:52 ` Daniel P. Berrangé
2018-11-20 0:44 ` Eduardo Habkost
2018-11-20 10:46 ` Daniel P. Berrangé [this message]
2018-11-20 10:52 ` Cornelia Huck
2018-11-20 11:51 ` Eduardo Habkost
2018-11-15 11:21 ` Cornelia Huck
2018-11-15 15:01 ` Cornelia Huck
2018-11-27 0:35 ` Eduardo Habkost
2018-11-15 16:29 ` Andrea Bolognani
2018-11-16 3:45 ` Eduardo Habkost
2018-11-19 10:41 ` Cornelia Huck
2018-11-19 18:07 ` Michael S. Tsirkin
2018-11-19 18:32 ` Cornelia Huck
2018-11-19 18:42 ` Michael S. Tsirkin
2018-11-19 18:56 ` Cornelia Huck
2018-11-19 19:14 ` Michael S. Tsirkin
2018-11-20 12:27 ` Andrea Bolognani
2018-11-20 19:14 ` Michael S. Tsirkin
2018-11-21 16:20 ` Andrea Bolognani
2018-11-19 21:32 ` Eduardo Habkost
2018-11-20 10:35 ` Cornelia Huck
2018-11-19 21:47 ` Eduardo Habkost
2018-11-20 3:08 ` Michael S. Tsirkin
2018-11-20 3:22 ` Eduardo Habkost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181120104605.GF25047@redhat.com \
--to=berrange@redhat.com \
--cc=abologna@redhat.com \
--cc=amit@kernel.org \
--cc=arei.gonglei@huawei.com \
--cc=armbru@redhat.com \
--cc=ccarrara@redhat.com \
--cc=cohuck@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=famz@redhat.com \
--cc=jasowang@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=laine@redhat.com \
--cc=libvir-list@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=wainersm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).