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 Thu, 2015-07-02 at 10:51 +0200, Paolo Bonzini wrote:
> 
> On 02/07/2015 10:48, Michael S. Tsirkin wrote:
> >> > 
> >> > The above footnote is a consequence of the conformance statements in the
> >> > "Device Operation" section.  (Hence putting it in a footnote only).
> > Hmm I don't get it.
> > 
> > The only non-legacy text that mention writethrough is this:
> > 	VIRTIO_BLK_F_CONFIG_WCE (11) Device can toggle its cache between
> > 	writeback and writethrough modes.
> > 
> > so this is the only definition of these terms.
> 
> After the patch (quoting from v2):
> 
> +If the VIRTIO_BLK_F_CONFIG_WCE feature is negotiated and the
> +\field{writeback} field in configuration space is 0, the device MUST
> +ensure that all writes are committed to non-volatile storage before
> +reporting completion.
> +
> +If the VIRTIO_BLK_F_CONFIG_WCE feature is negotiated, the driver MAY
> +switch to writethrough or writeback mode by writing respectively 0 and
> +1 to the \field{writeback} field.  After writing a 0 to \field{writeback},
> +the driver MUST NOT assume that writes submitted while the field was 1 have
> +been committed to non-volatile storage.
> 
> > Also, isn't the flush command special in the writeback mode?
> > maybe mention this...
> 
> Again quoting from v2:
> 
> +If the \field{VIRTIO_BLK_F_FLUSH} feature is negotiated, upon receipt
> +of a VIRTIO_BLK_T_FLUSH request, the device MUST ensure that any writes
> +which were completed are committed to non-volatile storage.
> 
> > 
> > Also
> > 	Some older legacy devices did not operate in writethrough mode
> > 	even after a driver announced lack of
> > 	support for VIRTIO_BLK_F_FLUSH.
> > 
> > What does this mean? let's just say in which mode they did operate.
> > Also what should driver do in this case?
> 
> In v2:
> 
> +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.

James




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