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: Tue, 30 Jun 2020 09:04:38 -0400	[thread overview]
Message-ID: <20200630090327-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200630142504.688aa989.cohuck@redhat.com>

On Tue, Jun 30, 2020 at 02:25:04PM +0200, Cornelia Huck wrote:
> On Tue, 30 Jun 2020 13:10:37 +0100
> Stefan Hajnoczi <stefanha@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>
> > > ---  
> > 
> > I thought that the following already forced VIRTIO 1.0 because it
> > doesn't advertize Legacy or Transitional devices:
> > 
> >   static const VirtioPCIDeviceTypeInfo vhost_user_fs_pci_info = {
> >       .base_name             = TYPE_VHOST_USER_FS_PCI,
> >       .non_transitional_name = "vhost-user-fs-pci",
> >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >       .instance_size = sizeof(VHostUserFSPCI),
> >       .instance_init = vhost_user_fs_pci_instance_init,
> >       .class_init    = vhost_user_fs_pci_class_init,
> >   };
> 
> This indeed makes vhost-user-fs-pci modern-only, I had not spotted that
> when I wrote the patch. Other modern-only devices do not go down this
> route and use the virtio_pci_force_virtio_1() approach.
> 
> > 
> > Do you have a guest that sees this VIRTIO 1.0 device and still fails to
> > negotiate the VERSION_1 feature bit?
> > 
> > > 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);  
> > 
> > Can this be moved to virtio_pci_types_register() so that it
> > automatically happens for .non_transitional_name devices?
> 
> There are several existing modern-only devices that don't use that kind
> of naming scheme...
> 
> What bothers me most is that you need to explicitly request a device to
> be modern-only, while that should be the default for any newly added
> device. Hence the approach with the centralized list of device types
> mentioned in a parallel thread. The main problem with that is that the
> proxy device starts getting realized before the virtio device with its
> id is present... I failed to find a solution so far. But I'd really
> like an approach that can work for all transports.

So how about simply validating that the device is modern only,
unless it's one of the whitelist?

-- 
MST



  reply	other threads:[~2020-06-30 13:05 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
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 [this message]
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=20200630090327-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.