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: Michael S. Tsirkin
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 19:15:25 +0300

On Wed, Jul 22, 2015 at 01:40:25PM +0200, Paolo Bonzini wrote:
> 
> 
> On 22/07/2015 12:19, Michael S. Tsirkin 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.
> > > 
> > > Why is SCSI passthrough support not available in virtio 1.0 ? This
> > > will cause a regression for any users of that as & when QEMU changes
> > > to use virtio 1.0 by default. Can we not fix this regression instead.
> >
> > If we wanted to, we might be able to fix this but not for 2.4: we'd have
> > to extend the spec and guest drivers, in some way TBD.
> > 
> > Paolo would be best placed to answer whether this feature is desirable
> > in the future, I think the argument made when the spec was written was that
> > the feature is not widely used, and virtio scsi is available as
> > a replacement for people who need it.
> 
> No, the feature is not desirable in the future. There is no reason
> really not to use virtio-scsi passthrough instead, since virtio-scsi has
> been out for about 3 years now and is stable.
> 

Given the amount of work we are spending handling this corner case,
I'm beginning to think we should just bring it back in.

> In addition, the implementation would either not be compatible with
> virtio 0.9, or would be different from everything else in the spec
> because it requires a particular framing for the buffers.
> 
> Paolo
Of course we'll need some kind of change to avoid depending on framing
of buffers, but how hard is it? Just stick the header size
somewhere in the buffer or in the config space.

Not compatible is probably not the right term to use here,
since when using the legacy interface we can make the old
framing assumption.


-- 
MST



reply via email to

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