qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V3 2/3] virtio-blk: fail get_features when both


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH V3 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set
Date: Wed, 22 Jul 2015 12:23:41 +0200

On Wed, 22 Jul 2015 17:35:07 +0800
Jason Wang <address@hidden> wrote:

> 
> 
> On 07/22/2015 04:58 PM, Cornelia Huck wrote:
> > On Wed, 22 Jul 2015 13:59:51 +0800
> > Jason Wang <address@hidden> wrote:
> >
> >> SCSI passthrough was no longer supported in virtio 1.0, so this patch
> >> fail the get_features() when both 1.0 and scsi is set. And also only
> >> advertise VIRTIO_BLK_F_SCSI for legacy virtio-blk device.
> >>
> >> Signed-off-by: Jason Wang <address@hidden>
> >> ---
> >>  hw/block/virtio-blk.c | 9 ++++++++-
> >>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> >> index 4c27974..4716c3e 100644
> >> --- a/hw/block/virtio-blk.c
> >> +++ b/hw/block/virtio-blk.c
> >> @@ -731,7 +731,14 @@ static uint64_t virtio_blk_get_features(VirtIODevice 
> >> *vdev, uint64_t features,
> >>      virtio_add_feature(&features, VIRTIO_BLK_F_GEOMETRY);
> >>      virtio_add_feature(&features, VIRTIO_BLK_F_TOPOLOGY);
> >>      virtio_add_feature(&features, VIRTIO_BLK_F_BLK_SIZE);
> >> -    virtio_add_feature(&features, VIRTIO_BLK_F_SCSI);
> >> +    if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
> >> +        if (s->conf.scsi) {
> >> +            error_setg(errp, "Virtio 1.0 does not support scsi 
> >> passthrough!");
> >> +            return 0;
> >> +        }
> >> +    } else {
> >> +        virtio_add_feature(&features, VIRTIO_BLK_F_SCSI);
> >> +    }
> >>
> >>      if (s->conf.config_wce) {
> >>          virtio_add_feature(&features, VIRTIO_BLK_F_CONFIG_WCE);
> > Do we advertise F_SCSI even if scsi is not configured in order to keep
> > the same bits as before? I'm afraid I don't remember, that thread was
> > long :/
> >
> > I'm asking because I'd like to depend on that bit to decide whether I
> > can negotiate revision 1 for ccw and subsequently offer VERSION_1. It
> > would be an easy thing to do, and I'd like to avoid mucking around with
> > device-specific configuration from the transport.
> 
> I don't see much difference. Both of our patches needs to set scsi to
> off to have 1.0 device. And I don't see advantages that did it from
> transport. If it has, we probably need something similar in virtio-pci.

The crux of the problem seems to be that pci and ccw have different
approaches on supporting legacy and modern devices...

> 
> >
> > To illustrate what I'm talking about, my current patchset for virtio-1
> > on ccw is here:
> >
> > git://github.com/cohuck/qemu virtio-1-ccw-2.5
> >
> 
> Looks like patch "virtio-blk: scsi is legacy only" breaks backward
> compatibility because VIRTIO_BLK_F_SCSI was not notified when scsi is off.

Yeah, that's what I feared.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]