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
