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: Thu, 2 Jul 2020 06:16:06 -0400	[thread overview]
Message-ID: <20200702060555-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200701181917.62538421.cohuck@redhat.com>

On Wed, Jul 01, 2020 at 06:19:17PM +0200, Cornelia Huck wrote:
> On Tue, 30 Jun 2020 09:04:38 -0400
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Tue, Jun 30, 2020 at 02:25:04PM +0200, Cornelia Huck wrote:
> 
> > > 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?
> 
> Who would do the validation, the virtio core? How can it distinguish
> between transitional and non-transitional? But maybe I'm just not
> getting your idea.

OK I've been thinking about two ideas, we can use them both:
1. virtio core: that can detect VIRTIO_1 being clear
in virtio_validate_features.
2. transports: could use a core API to detect whether
device can be a legacy one, to block device creation.


> Also, ccw does not currently have a way to explicitly configure a
> device non-transitional; the revisions can be used to fence off newer
> features, going down to legacy-only, but fencing off older features is
> not possible (that is only done by the device, if it has no legacy
> support).

I guess for ccw only option 1 works.

-- 
MST



  reply	other threads:[~2020-07-02 10:18 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
2020-07-01 16:19       ` Cornelia Huck
2020-07-02 10:16         ` Michael S. Tsirkin [this message]
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=20200702060555-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.