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

[James Bottomley <jbottomley@parallels.com>]

On Mon, 2013-08-19 at 18:25 +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 19, 2013 at 05:09:37PM +0200, Paolo Bonzini wrote:
> > Il 19/08/2013 17:03, James Bottomley ha scritto:
> > > On Mon, 2013-08-19 at 11:55 +0200, Paolo Bonzini wrote:
> > >> This patch introduces two improvements to writeback cache handling
> > >> in the virtio-blk spec.
> > >>
> > >> 1) The VIRTIO_BLK_F_FLUSH feature is renamed to VIRTIO_BLK_F_WCE, and
> > >> QEMU's behavior is documented explicitly as part of the spec: the host
> > >> negotiates the feature only if its cache is writeback.  The obvious dual
> > >> requirement is imposed on the guest: it should negotiate the feature
> > >> only if it is able to send flushes.  And in order to protect against
> > >> data loss, the spec now mandates that the host operates in writethrough
> > >> mode if the guest does not negotiate VIRTIO_BLK_F_WCE (this behavior
> > >> was already _allowed_ by the spec so far).  This can change with every
> > >> reset of course; typically the BIOS will run as writethrough, while the
> > >> "main" OS will run in writeback mode.  This is a backwards-compatible
> > >> refinement geared towards old or limited guests, so there is no need
> > >> for a new feature bit.
> > >>
> > >> 2) a second feature is added, VIRTIO_BLK_F_CONFIG_WCE, that provides
> > >> the same information in the configuration.  This will enable the driver
> > >> to modify the write-cache setting at runtime (via sysfs for Linux, via
> > >> MODE SELECT for Windows).
> > > 
> > > I've got to say this looks cockeyed; you're effectively translating SCSI
> > > commands into your own command set:
> > 
> > Note that this is only for Windows, because all block drivers in Windows
> > must speak SCSI.  Microsoft provides an ATA->SCSI translataion layer,
> > while for everything else you're on your own.  For what it's worth, Xen
> > paravirtualized drivers for Windows have to do the same dance.
> > 
> > On Linux, there's no MODE SELECT involved, as the commit message says.
> > 
> > > the way you're setting this up you
> > > have to modify the driver for every spec feature you support
> > 
> > Yes, that's known and that's one of the reasons why virtio-scsi was born.
> > 
> > > and have
> > > some sort of elaborate protocol to identify the supported feature set.
> > 
> > It's not elaborate (it's just a feature bit), but that's indeed another
> > of the reasons why virtio-scsi was born.
> > 
> > > What does this buy you?
> > 
> > Nothing, which is why virtio-scsi does it...
> > 
> > > SCSI is already a packet transport protocol.
> > > Just transport the SCSI commands over the virtio-interface and let the
> > > server reply (with I don't know what you're talking about if the command
> > > isn't supported).  This is the way SCSI probes real device, so if you do
> > > it this way there's no need for the elaborate protocol identification
> > > and SCSI will work out what the supported feature set is.
> > 
> > ... exactly this way.
> > 
> > Paolo
> 
> Hmm can VIRTIO_BLK_F_SCSI work for this somehow?

Well, yes, effectively.  You only have two implemented VIRTIO drivers:
virtio-scsi and virtio-blk, both of which emulate packet transport
protocols.  Block is much more problematic because it's not really
designed to be a wire protocol unlike SCSI.  However, what you should be
doing is mirroring the REQ_ protocol and have a side handshake to set
the capability flags.  That will ensure that all block features just
work (tm) in the same way.  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.

James