All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.