[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-virtualization
Subject:    Re: [PATCH RFC v6 19/20] virtio-blk: revision specific feature bits
From:       Cornelia Huck <cornelia.huck () de ! ibm ! com>
Date:       2015-01-30 14:10:49
Message-ID: 20150130151049.2e4c5331.cornelia.huck () de ! ibm ! com
[Download RAW message or body]

On Wed, 7 Jan 2015 21:11:44 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Wed, Jan 07, 2015 at 05:29:49PM +0100, Cornelia Huck wrote:
> > On Sun, 28 Dec 2014 12:24:46 +0200
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > 
> > > On Thu, Dec 11, 2014 at 02:25:21PM +0100, Cornelia Huck wrote:
> > > > Wire up virtio-blk to provide different feature bit sets depending
> > > > on whether legacy or v1.0 has been requested.
> > > > 
> > > > Note that VERSION_1 is still disabled due to missing ANY_LAYOUT support.
> > > > 
> > > > Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> > > 
> > > So we need some way for devices to tell transports
> > > not to negotiate rev 1.
> > > Does clearing VERSION_1 have this effect?
> > > 
> > I just noticed that my patch is running in circles here.
> > 
> > What we need is probably the transport-dependent maximum revision
> > checker (which at least for ccw is acting on a device) pass in the
> > requested revision and check if the feature bits for the revision
> > include VERSION_1. Does that make sense?
> 
> Just make devices set 'rev 1 supported' flag?

I'm now using the ->get_features() callback to check for VERSION_1
(assuming every device that supports it adds the bit in its callback)
and only allow rev 1 if it is present. Will play with this a bit as
well.

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[prev in list] [next in list] [prev in thread] [next in thread]