LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, dahi@linux.vnet.ibm.com,
	rusty@rustcorp.com.au,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	linux390@de.ibm.com, Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 4/6] virtio_ccw: rev 1 devices set VIRTIO_F_VERSION_1
Date: Tue, 9 Dec 2014 14:21:18 +0200	[thread overview]
Message-ID: <20141209122118.GF3993@redhat.com> (raw)
In-Reply-To: <20141209120123.117ccfac.cornelia.huck@de.ibm.com>

On Tue, Dec 09, 2014 at 12:01:23PM +0100, Cornelia Huck wrote:
> On Mon, 8 Dec 2014 15:06:03 +0200
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > What does it mean if rev 1 device does not set
> > VIRTIO_F_VERSION_1? E.g. is it native endian?
> 
> My understanding is that revision only determines the set of channel
> commands supported by the device, and their payload. IOW, it just
> governs the transport-specific way to communicate; things like
> endianness are independent of that and only governed by the VERSION_1
> bit which has rev 1 as a pre-req.

Well, that's a valid interpretation but it says so nowhere.

virtio 1.0 spec explicitly says VERSION_1 must be set.
virtio legacy explicitly said revision is 0.

And that is all.

We can go ahead and extend spec to support these configurations
in virtio 1.1.

Meanwhile, implementing random behaviour in guests will make
us support it forever.


> > 
> > Let's not even try to drive such devices:
> > fail attempts to finalize features.
> > virtio core will detect this and bail out.
> 
> Of course, we can still make the decision to refuse non-VERSION_1
> devices if rev 1 has been negotiated, but I'm still not quite sure what
> this buys us.

less configurations to support.


> > 
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >  drivers/s390/kvm/virtio_ccw.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
> > index 789275f..f9f87ba 100644
> > --- a/drivers/s390/kvm/virtio_ccw.c
> > +++ b/drivers/s390/kvm/virtio_ccw.c
> > @@ -758,6 +758,13 @@ static int virtio_ccw_finalize_features(struct virtio_device *vdev)
> >  	struct virtio_feature_desc *features;
> >  	struct ccw1 *ccw;
> > 
> > +	if (vcdev->revision == 1 &&
> 
> If we decide to keep this check, it should be for rev >= 1, though.

Fine, though this is theoretical, right?
Ican change this with a patch on top.

> > +	    !__virtio_test_bit(vdev, VIRTIO_F_VERSION_1)) {
> > +		dev_err(&vdev->dev, "virtio: device uses revision 1 "
> > +			"but does not have VIRTIO_F_VERSION_1\n");
> > +		return -EINVAL;
> > +	}
> > +
> >  	ccw = kzalloc(sizeof(*ccw), GFP_DMA | GFP_KERNEL);
> >  	if (!ccw)
> >  		return 0;
> 
> I'm still not convinced by this change: I'd prefer to allow rev 1
> without VERSION_1, especially as the core makes all its decisions based
> upon VERSION_1.

At the moment, but this is an implementation detail.
This is exactly why I want this hard requirement in code.


> Unless someone else has a good argument in favour of
> this change.


Let's not commit to something we are not sure we
can support.

We can always remove this code, but once we release
guest we won't be able to drop it.



-- 
MST

  reply	other threads:[~2014-12-09 12:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08 13:05 [PATCH v3 0/6] virtio 1.0 enhancements Michael S. Tsirkin
2014-12-08 13:05 ` [PATCH v3 1/6] virtio: add API to detect legacy devices Michael S. Tsirkin
2014-12-08 13:05 ` [PATCH v3 2/6] virtio_ccw: legacy: don't negotiate rev 1/features Michael S. Tsirkin
2014-12-09 10:35   ` Cornelia Huck
2014-12-08 13:05 ` [PATCH v3 3/6] virtio: allow finalize_features to fail Michael S. Tsirkin
2014-12-09 10:46   ` Cornelia Huck
2014-12-09 12:07     ` Michael S. Tsirkin
2014-12-09 12:56       ` Cornelia Huck
2014-12-08 13:06 ` [PATCH v3 4/6] virtio_ccw: rev 1 devices set VIRTIO_F_VERSION_1 Michael S. Tsirkin
2014-12-09 11:01   ` Cornelia Huck
2014-12-09 12:21     ` Michael S. Tsirkin [this message]
2014-12-09 17:23       ` Cornelia Huck
2014-12-09 18:55         ` Michael S. Tsirkin
2014-12-09 19:40         ` Michael S. Tsirkin
2014-12-10  8:41           ` Cornelia Huck
2014-12-08 13:06 ` [PATCH v3 5/6] virtio_balloon: drop legacy_only driver flag Michael S. Tsirkin
2014-12-09 11:24   ` Cornelia Huck
2014-12-08 13:06 ` [PATCH v3 6/6] virtio: " Michael S. Tsirkin
2014-12-09 11:24   ` Cornelia Huck

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=20141209122118.GF3993@redhat.com \
    --to=mst@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=dahi@linux.vnet.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=rusty@rustcorp.com.au \
    --cc=schwidefsky@de.ibm.com \
    --subject='Re: [PATCH v3 4/6] virtio_ccw: rev 1 devices set VIRTIO_F_VERSION_1' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).