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

[James Bottomley <jbottomley@parallels.com>]

On Mon, 2013-08-19 at 17:34 +0200, Paolo Bonzini wrote:
> Il 19/08/2013 17:25, Michael S. Tsirkin ha scritto:
> > 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.
> > 
> > Hmm can VIRTIO_BLK_F_SCSI work for this somehow?
> 
> No, it cannot.  First of all, it only works for virtio-blk devices
> backed by a physical disk (not a logical volume, not a partition, not a
> file).  That's a feature, not a bug, since we do not want virtio-blk
> devices to carry a SCSI target implementation (QEMU's is 2.5 kSLOC).

The unstated assumption above is that SCSI emulators are huge.  This is
bogus.  The tiny USB key you probably have in your pocket at the moment
that you bought for a tenner has a minimal SCSI emulator inside its rom.

You don't need to emulate every command.  Just those that provide the
features you want.

> Second, any change you make through SCSI requests is not visible to the
> host.  For example, if the guest kernel used SCSI requests to enable
> writeback caching, the host would not know about it and will not send
> flushes (thus a power loss will eat data).

I'm a bit lost here.  If you mean the native case, so host passes
commands directly to underlying SCSI, then, of course, you're correct,
the host driver doesn't snoop.  But the command chain is unbroken from
guest to physical device, so there's no data loss on power failure.  If
you mean the emulated case, then the host has to intercept the command.

James

> These reasons are why Windows drivers make no attempt to use
> VIRTIO_BLK_F_SCSI, they just ignore it and emulate the handful of
> commands that Windows actually uses (basically INQUIRY, READ CAPACITY,
> READ, WRITE, MODE SENSE, TEST UNIT READY, SYNCHRONIZE CACHE).
> 
> VIRTIO_BLK_F_SCSI is a huge hack.  There are some cases where it's
> useful if you're stuck with virtio-blk, but if you need it it's probably
> a better idea to migrate to virtio-scsi.
> 
> Paolo