Re: [PATCH v3 4/6] virtio_ccw: rev 1 devices set VIRTIO_F_VERSION_1

Michael S. Tsirkin
2014-12-09T19:40:52Z

On Tue, Dec 09, 2014 at 06:23:19PM +0100, Cornelia Huck wrote:
> On Tue, 9 Dec 2014 14:21:18 +0200
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > 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:
>
> > > > 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;
>
> This needs
>
> + struct virtio_device *vdev = &vcdev->vdev;
>
> to make it compile :)

In fact why does it?
vdev is a parameter.

> > > >
> > > > + 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.
> >
>
> OK, with your qemu patch on the host side this seems to be fine. No
> further objections from me for now.