From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W26yf-00080q-Uo for qemu-devel@nongnu.org; Sat, 11 Jan 2014 17:24:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W26yZ-0002tV-B7 for qemu-devel@nongnu.org; Sat, 11 Jan 2014 17:24:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W26yZ-0002tP-1y for qemu-devel@nongnu.org; Sat, 11 Jan 2014 17:24:19 -0500 Message-ID: <52D1C4F0.2010501@redhat.com> Date: Sat, 11 Jan 2014 23:25:52 +0100 From: Max Reitz MIME-Version: 1.0 References: <1386940979-3824-1-git-send-email-kwolf@redhat.com> <1386940979-3824-7-git-send-email-kwolf@redhat.com> In-Reply-To: <1386940979-3824-7-git-send-email-kwolf@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 06/24] block: Don't use guest sector size for qemu_blockalign() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , qemu-devel@nongnu.org Cc: pbonzini@redhat.com, pl@kamp.de, stefanha@redhat.com On 13.12.2013 14:22, Kevin Wolf wrote: > bs->buffer_alignment is set by the device emulation and contains the > logical block size of the guest device. This isn't something that the > block layer should know, and even less something to use for determining > the right alignment of buffers to be used for the host. > > The new BlockLimits field opt_mem_alignment tells the qemu block layer > the optimal alignment to be used so that no bounce buffer must be used > in the driver. > > This patch may change the buffer alignment from 4k to 512 for all > callers that used qemu_blockalign() with the top-level image format > BlockDriverState. The value was never propagated to other levels in the > tree, so in particular raw-posix never required anything else than 512. > > While on disks with 4k sectors direct I/O requires a 4k alignment, > memory may still be okay when aligned to 512 byte boundaries. This is > what must have happened in practice, because otherwise this would > already have failed earlier. Therefore I don't expect regressions even > with this intermediate state. Later, raw-posix can implement the hook > and expose a different memory alignment requirement. > > Signed-off-by: Kevin Wolf > Reviewed-by: Wenchao Xia > --- > block.c | 23 ++++++++++++++++++++--- > include/block/block.h | 3 +++ > include/block/block_int.h | 3 +++ > 3 files changed, 26 insertions(+), 3 deletions(-) Reviewed-by: Max Reitz