From patchwork Mon Dec 28 16:09:48 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Avi Kivity X-Patchwork-Id: 41855 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 3B101B6EF5 for ; Tue, 29 Dec 2009 03:10:36 +1100 (EST) Received: from localhost ([127.0.0.1]:45908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPIAw-0002A2-W4 for incoming@patchwork.ozlabs.org; Mon, 28 Dec 2009 11:10:31 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPIAR-000288-LL for qemu-devel@nongnu.org; Mon, 28 Dec 2009 11:09:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPIAM-00024L-Ic for qemu-devel@nongnu.org; Mon, 28 Dec 2009 11:09:58 -0500 Received: from [199.232.76.173] (port=38986 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPIAM-00024H-DJ for qemu-devel@nongnu.org; Mon, 28 Dec 2009 11:09:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:4268) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NPIAL-0007Qu-Vb for qemu-devel@nongnu.org; Mon, 28 Dec 2009 11:09:54 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nBSG9o8Q007555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Dec 2009 11:09:50 -0500 Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com [10.35.255.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nBSG9nZd004608; Mon, 28 Dec 2009 11:09:49 -0500 Received: from localhost.localdomain (dhcp-1-27.tlv.redhat.com [10.35.1.27]) by cleopatra.tlv.redhat.com (Postfix) with ESMTP id EC9A925004D; Mon, 28 Dec 2009 18:09:48 +0200 (IST) From: Avi Kivity To: Rusty Russell Date: Mon, 28 Dec 2009 18:09:48 +0200 Message-Id: <1262016588-15136-1-git-send-email-avi@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: [Qemu-devel] [PATCH] virtio-blk physical block size X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org This patch adds a physical block size attribute to virtio disks, corresponding to /sys/devices/.../physical_block_size. It is defined as the request alignment which will not trigger RMW cycles. This can be important for modern disks which use 4K physical sectors (though they still support 512 logical sectors), and for file-backed disk images (which have both the underlying filesystem block size and their own allocation granularity to consider). Installers use this to align partitions to physical block boundaries. Note the spec already defined blk_size as the performance rather than minimum alignment. However the driver interpreted this as the logical block size, so I updated the spec to match the driver assuming the driver predates the spec and that this is an error. Signed-off-by: Avi Kivity --- virtio-spec-0.8.3.lyx.orig 2009-12-28 17:42:40.000000000 +0200 +++ virtio-spec-0.8.3.lyx 2009-12-28 18:05:17.000000000 +0200 @@ -4131,6 +4131,19 @@ \end_layout \begin_layout Description +VIRTIO_BLK_F_PHYS_BLK_SIZE(7) Physical block size of disk (writes aligned + to this will not trigger read-modify-write cycles) is in +\begin_inset Quotes erd +\end_inset + +phys_blk_size +\begin_inset Quotes erd +\end_inset + +. +\end_layout + +\begin_layout Description VIRTIO_BLK_F_SECTOR_MAX \begin_inset space ~ \end_inset @@ -4214,6 +4227,11 @@ \begin_layout Plain Layout + u32 phys_blk_size; +\end_layout + +\begin_layout Plain Layout + }; \end_layout @@ -4241,9 +4259,9 @@ \begin_layout Enumerate If the VIRTIO_BLK_F_BLK_SIZE feature is negotiated, the blk_size field can - be read to determine the optimal sector size for the driver to use. + be read to determine the sector size for the driver to use. This does not effect the units used in the protocol (always 512 bytes), - but awareness of the correct value can effect performance. + but requests must be aligned to this size. \end_layout \begin_layout Enumerate @@ -4257,6 +4275,13 @@ No requests should be submitted which go beyond this limit. \end_layout +\begin_layout Enumerate +If the VIRTIO_BLK_F_PHYS_BLK_SIZE feature is negotiated, the phys_blk_size + field should be read to determine the hardware block size. + Smaller writes are liable to require read-modify-write cycles on behalf + of the underlying hardware, however they are still supported. +\end_layout + \begin_layout Section* Device Operation \end_layout