[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]