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
