Re: [Qemu-devel] [PATCH V3 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set

[Paolo Bonzini]

On 22/07/2015 18:15, Michael S. Tsirkin wrote:
> > 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.

Please don't.  Perhaps it made sense when Rusty was thinking of
virtio-blk as simply "struct request over virtio", but I'm not even sure
what the use case is.

For virtio-scsi, for example, one reason to use passthrough is that you
can use the same /dev/disk/by-id path on physical and virtual machines.
 But that doesn't work with virtio-blk's pseudo passthrough.

Another is to pass "weird" devices (tapes, media changers, etc.) to
backup appliances, but that also doesn't work with virtio-blk.

So what is it used for?  That's what is needed to make an informed decision.

> > 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.
> 
> 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.

Not compatible in the sense that it requires work in the drivers too
(unlike e.g. CONFIG_WCE, where the old code just works with the proposed
modifications to 1.0).

Paolo