From: Andrea Bolognani <abologna@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
"Kevin Wolf" <kwolf@redhat.com>, "Amit Shah" <amit@kernel.org>,
libvir-list@redhat.com, "Markus Armbruster" <armbru@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Max Reitz" <mreitz@redhat.com>,
"Caio Carrara" <ccarrara@redhat.com>,
Gonglei <arei.gonglei@huawei.com>,
"Laine Stump" <laine@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Cleber Rosa" <crosa@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Cole Robinson" <crobinso@redhat.com>,
"Daniel Berrange" <berrange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-4.0 v4 0/2] virtio: Provide version-specific variants of virtio PCI devices
Date: Tue, 05 Mar 2019 16:56:43 +0100 [thread overview]
Message-ID: <81d22ed88833ed22a1c3781c3c0c1eafad99b280.camel@redhat.com> (raw)
In-Reply-To: <20190305143801.lq4gpetubspftkda@sirius.home.kraxel.org>
On Tue, 2019-03-05 at 15:38 +0100, Gerd Hoffmann wrote:
> Hi,
>
> > -device virtio-blk-pci-non-transitional \
> > -device virtio-net-pci-non-transitional \
> > -device virtio-gpu-pci-non-transitional \
> >
> > and you wouldn't have to question why you can use the
> > non-transitional variant for pretty much everything, except for the
> > few cases where you can't - for no apparent reason...
>
> Well, there are no variants, only a single virtio-$foo-pci* device. So
> you don't have to worry about picking one of the available variants,
> there is no choice in the first place.
>
> When adding an virtio-gpu-pci-non-transitional variant we'll create
> confusion too, because it wouldn't be a real variant. We would have two
> 100% identical devices then, and people will probably wonder why they
> exist and what the difference is ...
When looking at a single device, I mostly agree with your assessment;
however, when looking at the overall situation with VirtIO devices,
one might quite reasonably infer the following rules:
* devices marked as (non-)transitional are going to show up as
(non-)transitional;
* unmarked devices might show up as either one, depending on some
factor which is not immediately obvious.
So if you knew you wanted non-transitional devices you would expect
to just use the non-transitional variant for *all* VirtIO devices,
including virtio-gpu, without necessarily caring whether the unmarked
devices behaves any differently; if you tried to use the transitional
device, you'd get an error message telling you that device doesn't
exist, which is pretty reasonable and easy to research / understand.
With the current situation, once you've tried using non-transitional
virtio-gpu and gotten back an error message, there's quite a bit more
digging required to figure out *why* the device is not there in the
first place.
So I agree neither scenario is exactly perfect, but I still think
adding non-transitional alias devices would overall be more
user-friendly.
> So I can't see how this would be so much better. We have to document
> the mess no matter what.
We have some documentation in libvirt:
https://libvirt.org/formatdomain.html#elementsVirtioTransitional
Not that more / improved documentation is ever a bad idea :)
--
Andrea Bolognani / Red Hat / Virtualization
next prev parent reply other threads:[~2019-03-05 15:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 19:57 [Qemu-devel] [PATCH for-4.0 v4 0/2] virtio: Provide version-specific variants of virtio PCI devices Eduardo Habkost
2018-12-05 19:57 ` [Qemu-devel] [PATCH for-4.0 v4 1/2] virtio: Helper for registering virtio device types Eduardo Habkost
2018-12-05 19:57 ` [Qemu-devel] [PATCH for-4.0 v4 2/2] virtio: Provide version-specific variants of virtio PCI devices Eduardo Habkost
2018-12-07 12:03 ` Caio Carrara
2019-01-03 9:38 ` Thomas Huth
2019-01-03 10:14 ` Thomas Huth
2019-01-03 10:48 ` Cornelia Huck
2019-01-03 18:32 ` Eduardo Habkost
2019-01-04 4:27 ` Michael S. Tsirkin
2019-01-04 8:27 ` Cornelia Huck
2018-12-05 21:42 ` [Qemu-devel] [libvirt] [PATCH for-4.0 v4 0/2] " no-reply
2018-12-12 1:18 ` [Qemu-devel] " Eduardo Habkost
2018-12-12 1:22 ` Michael S. Tsirkin
2019-03-05 12:09 ` Andrea Bolognani
2019-03-05 14:38 ` Gerd Hoffmann
2019-03-05 15:56 ` Andrea Bolognani [this message]
2019-03-06 7:41 ` [Qemu-devel] [libvirt] " Peter Krempa
2019-03-06 8:30 ` Ján Tomko
2019-03-06 9:08 ` Andrea Bolognani
2019-03-06 9:10 ` Daniel P. Berrangé
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=81d22ed88833ed22a1c3781c3c0c1eafad99b280.camel@redhat.com \
--to=abologna@redhat.com \
--cc=amit@kernel.org \
--cc=arei.gonglei@huawei.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=ccarrara@redhat.com \
--cc=cohuck@redhat.com \
--cc=crobinso@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jasowang@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=laine@redhat.com \
--cc=libvir-list@redhat.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).