OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> 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/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]