qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).