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


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

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

Subject: Re: [virtio] [PATCH] virtio-blk: restore VIRTIO_BLK_F_CONFIG_WCE (VIRTIO-144)

On 02/07/2015 19:16, Michael S. Tsirkin wrote:
> On Thu, Jul 02, 2015 at 03:10:48PM +0200, Paolo Bonzini wrote:
>> On 02/07/2015 13:21, James Bottomley wrote:
>>>> +If the \field{VIRTIO_BLK_F_FLUSH} feature is not negotiated, the
>>>> +device SHOULD ensure that all writes are committed to non-volatile
>>>> +storage before reporting completion.  It MUST do so if it proposed
>>>> +\field{VIRTIO_BLK_F_FLUSH}.  Failure to do so can cause data loss.
>>> Not SHOULD, MUST.  Please don't leave spec based doors open to bad
>>> implementations.  An implementation that allows data corruption MUST NOT
>>> have a spec interpretation that supports it.
>> What I'm trying to do is to make it possible for the guest to detect an
>> implementation that is intentionally unsafe.  Such an implementation
>> MUST NOT propose the VIRTIO_BLK_F_FLUSH feature, unlike the USB drives
>> you mention.  I totally agree that WCE and FLUSH are not separable.
> Hmm. Very simple drivers don't negotiate any features.
> Making such drivers lose data isn't a good idea I think.

But it won't!  Unless it talks to a very simple device that also doesn't
negotiate any feature (including VIRTIO_BLK_F_FLUSH).

Bringing the "cheap USB pen drive" parallel forward, such a simple
device would probably disregard MUSTs left and right anyway.  At least
what I wrote makes it possible for a not-so-simple driver to know it's
talking to a very simple device.


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