Re: [Qemu-devel] Is cache=writeback safe yet?

[Virtbie]

On 02/20/12 16:43, Virtbie wrote:
> Great explanation Anthony,
>
> may I still ask:
>
> 1)
> Is WCE + volatile flag exposed to the guest, by all three virtual 
> devices:
> - virtio
> - scsi
> - ide
> ?
> (if not, I still don't understand how this works)
>
>
> 2) Is there a minimum guest kernel and a minimum viostor Windows 
> driver version, to see such WCE+volatile flag in a virtio disk, so 
> that the guest OS can actually see the cache?
>
>
> Because I can't seem to find such flag for a virtio disk on a linux 
> 2.6.38 guest and that seems serious to me.
> Is it visible somewhere in /sys hierarchy? Or is 2.6.38 too old?

Is it this commit?

commit f1b0ef062602713c2c7cfa12362d5d90ed01c5f6
Author: Christoph Hellwig <address@hidden>
Date:   Thu Sep 17 19:57:42 2009 +0200

    virtio_blk: add support for cache flush

    Recent qemu has added a VIRTIO_BLK_F_FLUSH flag to advertise that the
    virtual disk has a volatile write cache that needs to be flushed.  
In case
    we see this feature implement tell the Linux block layer about the fact
    and use the new VIRTIO_BLK_T_FLUSH to flush the cache when 
required.  This
    allows for an correct and simple implementation of write barriers.

    Signed-off-by: Christoph Hellwig <address@hidden>
    Signed-off-by: Rusty Russell <address@hidden>



That was introduced in 2.6.32 .
So can I suppose that a guest running linux 2.6.32+ detects the write 
cache in a virtio disk and actually flushes? (suppose a wise filesystem)


The flag seems to go into :

    /* Feature bits */
    #define VIRTIO_BLK_F_BARRIER    0       /* Does host support 
barriers? */
    #define VIRTIO_BLK_F_SIZE_MAX   1       /* Indicates maximum 
segment size */
    #define VIRTIO_BLK_F_SEG_MAX    2       /* Indicates maximum # of 
segments */
    #define VIRTIO_BLK_F_GEOMETRY   4       /* Legacy geometry 
available  */
    #define VIRTIO_BLK_F_RO         5       /* Disk is read-only */
    #define VIRTIO_BLK_F_BLK_SIZE   6       /* Block size of disk is 
available*/
    #define VIRTIO_BLK_F_SCSI       7       /* Supports scsi command 
passthru */
    #define VIRTIO_BLK_F_FLUSH      9       /* Cache flush command 
support */
    #define VIRTIO_BLK_F_TOPOLOGY   10      /* Topology information is 
available */

    #define VIRTIO_BLK_ID_BYTES     20      /* ID string length */

    ........

    static unsigned int features[] = {
            VIRTIO_BLK_F_SEG_MAX, VIRTIO_BLK_F_SIZE_MAX, 
VIRTIO_BLK_F_GEOMETRY,
            VIRTIO_BLK_F_RO, VIRTIO_BLK_F_BLK_SIZE, VIRTIO_BLK_F_SCSI,
            VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_TOPOLOGY
    };

so the presence of volatile cache is probably exposed by:

    $ cat /sys/block/vda/device/features
    0010101101100000000000000000100000000000000000000000000000000000

I don't understand if I should look at the 10th bit (9 in 0-based as per 
#define's ) which would be 0 == "no cache" in this case, or at the 7th 
bit (by the position in features[] array), which would be 1 == "has 
cache" in this case .


Thank you
Vb.