From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzXQI-0006ui-Du for qemu-devel@nongnu.org; Mon, 20 Feb 2012 12:53:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzXQB-0003vW-KV for qemu-devel@nongnu.org; Mon, 20 Feb 2012 12:53:14 -0500 Received: from blade3.isti.cnr.it ([194.119.192.19]:1137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzXQB-0003ut-F9 for qemu-devel@nongnu.org; Mon, 20 Feb 2012 12:53:07 -0500 Received: from [192.168.7.52] ([155.253.6.254]) by mx.isti.cnr.it (PMDF V6.5-x6 #31988) with ESMTPSA id <01OC82B7ZP1OJQIB7U@mx.isti.cnr.it> for qemu-devel@nongnu.org; Mon, 20 Feb 2012 18:52:32 +0100 (MET) Date: Mon, 20 Feb 2012 18:52:44 +0100 From: Virtbie In-reply-to: <4F426A16.9090609@shiftmail.org> Message-id: <4F42886C.1010804@shiftmail.org> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7bit References: <4F425643.2@shiftmail.org> <4F42616D.30800@codemonkey.ws> <4F426A16.9090609@shiftmail.org> Subject: Re: [Qemu-devel] Is cache=writeback safe yet? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , qemu-devel@nongnu.org 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 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 Signed-off-by: Rusty Russell 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.