All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH RFC] virtio-fs: force virtio 1.x usage
Date: Mon, 29 Jun 2020 11:45:35 -0400	[thread overview]
Message-ID: <20200629114515-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200629173933.35cea40f.cohuck@redhat.com>

On Mon, Jun 29, 2020 at 05:39:33PM +0200, Cornelia Huck wrote:
> On Mon, 29 Jun 2020 10:53:23 -0400
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Mon, Jun 29, 2020 at 12:27:58PM +0200, Cornelia Huck wrote:
> > > virtio-fs devices are only specified for virtio-1, so it is unclear
> > > how a legacy or transitional device should behave.
> > > 
> > > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> > > ---
> > > 
> > > Forcing off legacy now (after the virtio-fs device has already been
> > > available) may have unintended consequences, therefore RFC.
> > > 
> > > By default, a virtio-pci device uses 'AUTO' for disable_legacy, which
> > > will resolve to different values based upon which bus the device has
> > > been plugged. Therefore, forcing disable_legacy may result in the same
> > > device or a quite different one.
> > > 
> > > Even though pre-virtio-1 behaviour of virtio-fs devices is simply not
> > > specified, toggling disable_legacy will have implications for the BAR
> > > layout, IIRC, and therefore a guest might end up getting a different
> > > device, even if it always used it with virtio-1 anyway.
> > > 
> > > Not sure what the best way to solve this problem is. Adding a compat
> > > property for disable_legacy=AUTO may be the right thing to do, but I'm
> > > not quite clear if there are any further implications here.  
> > 
> > Well I notice that this device is not migrateable.
> > So I think that we can just switch it over and be done with it.
> 
> Oh, that makes things easier. (I'm wondering if libvirt already
> configures this correctly?)
> 
> > 
> > 
> > > Whatever we do here, we should make sure that the ccw incarnation of
> > > this device indeed forces virtio-1.  
> > 
> > I agree. I notice that the API virtio_pci_force_virtio_1 turned out
> > to be too fragile. I propose that instead we have a whitelist of
> > devices which can be legacy or transitional. Force rest to modern.
> 
> Also, there are further complications because the mechanism is per
> transport, and therefore easy to miss.
> 
> bool virtio_legacy_allowed(VirtIODevice *vdev)
> {
>     switch (vdev->device_id) {
>     case <...>:
>     <list of legacy-capable devices>
>         return true;
>     default:
>         return false;
> }
> 
> Seems straightforward enough.


Agreed. virtio spec has the list.

> > 
> > 
> > > ---
> > >  hw/virtio/vhost-user-fs-pci.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/hw/virtio/vhost-user-fs-pci.c b/hw/virtio/vhost-user-fs-pci.c
> > > index e11c889d82b3..244205edf765 100644
> > > --- a/hw/virtio/vhost-user-fs-pci.c
> > > +++ b/hw/virtio/vhost-user-fs-pci.c
> > > @@ -44,6 +44,7 @@ static void vhost_user_fs_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> > >          vpci_dev->nvectors = dev->vdev.conf.num_request_queues + 2;
> > >      }
> > >  
> > > +    virtio_pci_force_virtio_1(vpci_dev);
> > >      qdev_realize(vdev, BUS(&vpci_dev->bus), errp);
> > >  }
> > >  
> > > -- 
> > > 2.25.4  
> > 



  reply	other threads:[~2020-06-29 15:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29 10:27 [PATCH RFC] virtio-fs: force virtio 1.x usage Cornelia Huck
2020-06-29 14:53 ` Michael S. Tsirkin
2020-06-29 15:39   ` Cornelia Huck
2020-06-29 15:45     ` Michael S. Tsirkin [this message]
2020-06-30  9:35       ` Cornelia Huck
2020-06-30 10:45         ` Michael S. Tsirkin
2020-06-30 11:30           ` Cornelia Huck
2020-06-30 13:02             ` Michael S. Tsirkin
2020-07-01 13:58               ` Cornelia Huck
2020-07-02 10:24                 ` Michael S. Tsirkin
2020-06-29 17:05   ` Dr. David Alan Gilbert
2020-06-30 12:10 ` Stefan Hajnoczi
2020-06-30 12:25   ` Cornelia Huck
2020-06-30 13:04     ` Michael S. Tsirkin
2020-07-01 16:19       ` Cornelia Huck
2020-07-02 10:16         ` Michael S. Tsirkin
2020-07-02 10:45           ` Cornelia Huck
2020-07-02 11:22             ` Michael S. Tsirkin
2020-07-02 11:55               ` Cornelia Huck
2020-07-02 13:22                 ` 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=20200629114515-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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.