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?
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe:
> Unsubscribe:
> List help:
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
