From: Cornelia Huck <cohuck@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Caio Carrara" <ccarrara@redhat.com>,
"Fabian Deutsch" <fdeutsch@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
qemu-devel@nongnu.org, Gonglei <arei.gonglei@huawei.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Laine Stump" <laine@redhat.com>,
"Cleber Rosa" <crosa@redhat.com>,
"Andrea Bolognani" <abologna@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] virtio: Provide version-specific variants of virtio PCI devices
Date: Tue, 16 Oct 2018 10:39:30 +0200 [thread overview]
Message-ID: <20181016103930.287d0c2a.cohuck@redhat.com> (raw)
In-Reply-To: <20181015181404.GQ31060@habkost.net>
On Mon, 15 Oct 2018 15:14:04 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Sun, Oct 14, 2018 at 05:35:12PM -0400, Michael S. Tsirkin wrote:
> > On Fri, Oct 12, 2018 at 11:54:35PM -0300, Eduardo Habkost wrote:
> > > 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 is 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-0.9: legacy virtio device
> > > - Supports Conventional PCI buses only, because
> > > it has a PIO BAR
> > > - virtio-*-pci-1.0-transitional: virtio-1.0 device supporting legacy drivers
> > > - Supports Conventional PCI buses only, because
> > > it has a PIO BAR
> > > - virtio-*-pci-1.0: modern-only
> > > - Supports both Conventional PCI and PCI Express buses
> >
> > I would prefer a "modern" suffix since it will likely cover future
> > revisions as well.
>
> That's on purpose. The new device types don't cover future
> revisions, otherwise we'll have exactly the same ambiguity
> problems in the future.
>
> The moment we have a new virtio specification released, a device
> type called "modern" will automatically become ambiguous.
I don't think that's a problem.
Most of the issues come from the major changes that virtio-pci did when
moving to the 1.0 standard (like that PIO BAR, or the changed ids). The
1.0 standard allows for gradual enhancements and changes guarded by
feature bits.
Consider the packed ring layout, which is one of the major changes for
1.1: It is completely guarded by feature bits, and it does not come
with any changes down in the pci area. If we want to fence it off for
compat machines, we need to fence off offering the bits (for _any_
transport), which does not imply a new type of virtio-pci device.
There are other, pci-specific changes which are also guarded by feature
bits and don't need a new device type.
Also, many of the enhancements of the virtio standard are likely to be
new device types and new features for existing device types. None of
that is pci specific.
So, what I'd propose is:
- virtio-*-pci-standard: compliant with the virtio standard 1.0 or
later; no legacy fallback
- virtio-*-pci-transitional: compliant with the virtio standard 1.0 or
later; fallback to legacy included, as specified by the standard
(- virtio-*-pci-legacy: legacy devices, should we need that for compat
reasons)
We could also use '-virtio-1' instead of '-standard', if we do a major
break with a 2.x standard (I don't see it yet). But having a new type
for 1.1 sounds wrong.
Also note that virtio-ccw does not need this (we managed to avoid many
of the issues virtio-pci had due to being late to the party :). I'm not
sure what virtio-mmio does, or if we even care.
next prev parent reply other threads:[~2018-10-16 8:39 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-13 2:54 [Qemu-devel] [PATCH] virtio: Provide version-specific variants of virtio PCI devices Eduardo Habkost
2018-10-14 21:35 ` Michael S. Tsirkin
2018-10-15 18:14 ` Eduardo Habkost
2018-10-16 8:39 ` Cornelia Huck [this message]
2018-10-16 13:32 ` Eduardo Habkost
2018-10-16 15:51 ` Cornelia Huck
2018-10-16 17:02 ` Daniel P. Berrangé
2018-10-16 19:12 ` Laine Stump
2018-10-17 5:57 ` [Qemu-devel] No more chameleon devices (was: [PATCH] virtio: Provide version-specific variants of virtio PCI devices) Markus Armbruster
2018-10-17 6:34 ` Gerd Hoffmann
2018-10-17 11:56 ` [Qemu-devel] No more chameleon devices Markus Armbruster
2018-10-17 15:56 ` [Qemu-devel] No more chameleon devices (was: [PATCH] virtio: Provide version-specific variants of virtio PCI devices) Eduardo Habkost
2018-10-17 16:38 ` Michael S. Tsirkin
2018-10-17 19:19 ` Eduardo Habkost
2018-10-18 14:11 ` [Qemu-devel] No more chameleon devices Marcel Apfelbaum
2018-10-18 14:15 ` Peter Maydell
2018-10-18 14:38 ` Daniel P. Berrangé
2018-10-18 14:41 ` Peter Maydell
2018-10-18 14:45 ` Marcel Apfelbaum
2018-10-18 14:48 ` Peter Maydell
2018-10-18 15:39 ` Marcel Apfelbaum
2018-10-18 18:07 ` Eduardo Habkost
2018-10-17 10:43 ` [Qemu-devel] [PATCH] virtio: Provide version-specific variants of virtio PCI devices Andrea Bolognani
2018-10-17 15:01 ` Eduardo Habkost
2018-10-17 15:06 ` Michael S. Tsirkin
2018-10-17 15:57 ` Eduardo Habkost
2018-10-18 10:25 ` Andrea Bolognani
2018-10-18 10:27 ` Daniel P. Berrangé
2018-11-14 18:20 ` Eduardo Habkost
2018-10-15 8:16 ` Gerd Hoffmann
2018-10-15 10:27 ` Michael S. Tsirkin
2018-10-15 23:03 ` Eduardo Habkost
2018-10-16 6:48 ` Gerd Hoffmann
2018-10-16 13:39 ` Eduardo Habkost
2018-10-16 18:42 ` Gerd Hoffmann
2018-10-17 5:49 ` [Qemu-devel] "no-user" for properties (was: [PATCH] virtio: Provide version-specific variants of virtio PCI devices) Markus Armbruster
2018-10-15 9:45 ` [Qemu-devel] [PATCH] virtio: Provide version-specific variants of virtio PCI devices Cornelia Huck
2018-10-15 23:32 ` Eduardo Habkost
2018-10-17 9:22 ` Stefan Hajnoczi
2018-10-17 15:10 ` Eduardo Habkost
2018-10-17 15:32 ` Michael S. Tsirkin
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=20181016103930.287d0c2a.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=abologna@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=armbru@redhat.com \
--cc=ccarrara@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=fdeutsch@redhat.com \
--cc=kraxel@redhat.com \
--cc=laine@redhat.com \
--cc=mst@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--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).