Re: [virtio-comment] [PATCH 2/5] virtio-blk spec: writeback cache enable improvements

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Aug 19, 2013 at 08:00:27PM +0200, Paolo Bonzini wrote:
> Il 19/08/2013 18:44, James Bottomley ha scritto:
> >>   The difference is that the SCSI RPC is very small, and the
> >> complicated/evolving parts are at a different level, so the host and
> >> guest code that implements the virtio-scsi spec is very small.
> > 
> >> Those complicated/evolving parts are _still_ there, so the code needed
> >> in the host to implement virtio-scsi is indeed much larger than
> >> virtio-blk.  But it's a non-issue for a non-toy VMM because that code is
> >> needed anyway, for example to support USB storage.
> > 
> > It might be now, but once you've done the feature creep in the
> > virtio-blk spec to support all of our user visible features (DIF,
> > discard, etc.) you'll probably find that the need to translate the
> > commands causes virtio-blk to grow faster than virtio-scsi.
> 
> Oh, definitely!  In fact, we've decided not to do much feature-creep in
> virtio-blk.
> 
> There was none after this patch.  Rusty said discard would be borderline
> but acceptable, but he already wasn't sure about write-zeroes.
> 
> >> And piggybacking on SCSI means that whenever a new feature comes along,
> >> someone else is already doing the work to integrate into the Linux block
> >> layer, to use it, to export it to userspace, etc.  This typically
> >> happens before hosts implement the feature, so us virt people get a
> >> large part of the work for free; we only need to implement the feature
> >> in the host, because these feature rarely if ever affect the SCSI RPC
> >> interface.  Instead, adding the smallest feature to virtio-blk always
> >> necessitates updates to both the spec and the guest drivers, in addition
> >> to the VMM (typically QEMU).
> > 
> > Spec, possibly, since someone needs to be told about commands added to
> > block, but it shouldn't need modification of correctly implemented
> > drivers.  If the encapsulation were done right, the client would just
> > send the correct commands, so no code growth.
> 
> Ah, I see what you mean now.  It's a different channel to describe
> features.  That would be a virtio-blk v2 basically.  It would have made
> sense if done in the beginning, but not now.

It's worth considering. We can deprecate the WCE bit if we want to.
I don't think that's virtio-blk v2 really.

> > But this is illustrative of the point.  When the block layer is patched
> > to add more stuff (which has been happening quite a lot lately), you
> > have to rev your spec and update all the guest and host drivers.  This
> > is one of the reasons for the current SCSI architecture model: not to
> > have to do this.
> > 
> >>> For standards purposes, I'm not really sure
> >>> how to proceed on this but I believe linux will be the only implementor
> >>> of virtio-blk, right, so it probably doesn't matter.
> >>
> >> There are Windows drivers for virtio-blk.
> > 
> > Which are thus effectively emulator drivers.
> 
> Yes.
> 
> But honestly I'm not sure what your point is... I'm submitting this
> patch at Rusty's request in order to clean up IP issues.  It's already
> part of the spec, of QEMU, of the guest drivers.  I don't plan on any
> other feature creep in virtio-blk, or fwiw no one else doesn't.
> 
> Paolo

virtio-blk is widely used. I wouldn't write it off just yet.
So I think these comments are valuable.

For example, this made me realize that even when scsi command
pass-through is enabled, we either take the clue on WCE support from
host feature bit. This is wrong, isn't it? We really should send scsi
commands to the device to figure out and set/clear it.

I also note that virtio-blk simply has custom sysfs attributes
for WCE control and status. Is this normal?
James, are there tools that send scsi commands to block devices
to control WCE?

-- 
MST