From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZEZG-0002qh-7I for qemu-devel@nongnu.org; Fri, 26 Feb 2016 04:20:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZEZD-0007Q0-1R for qemu-devel@nongnu.org; Fri, 26 Feb 2016 04:20:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZEZC-0007Pf-Sq for qemu-devel@nongnu.org; Fri, 26 Feb 2016 04:20:06 -0500 Date: Fri, 26 Feb 2016 10:20:03 +0100 From: Kevin Wolf Message-ID: <20160226092003.GC5668@noname.redhat.com> References: <1450284917-10508-1-git-send-email-apyrgio@arrikto.com> <1450284917-10508-2-git-send-email-apyrgio@arrikto.com> <56BC6DC0.4070204@redhat.com> <56C70168.2050408@arrikto.com> <56CAE64B.4070608@redhat.com> <56CED32C.6020001@arrikto.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56CED32C.6020001@arrikto.com> Subject: Re: [Qemu-devel] [PATCH 1/9] dma-helpers: Expose the sg mapping logic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Pyrgiotis Cc: Paolo Bonzini , famz@redhat.com, qemu-devel@nongnu.org Am 25.02.2016 um 11:10 hat Alex Pyrgiotis geschrieben: > > I think the first step is understanding what to do about the weird "& > > ~BDRV_SECTOR_MASK" case, then. > > We can discuss about this case in the "dma-helpers: Do not truncate > small qiovs" thread. I'm all for the removal of this check, but I was > hoping that Kevin would clarify if it's still relevant. I think all of dma-helpers.c is currently sector based, and as long as it is, this code needs to stay. You need to look at it in relation to the divisions by 512 that the same function performs - the block layer simply expects that if you have an I/O request for one sector, your qiov is 512 bytes in length and not 527. So whenever the integer division rounds down, the qiov needs to be trimmed, too. As soon as you convert the whole function to byte granularity (and the block layer does have byte granularity APIs, so that shouldn't be a lot of work), you don't have any implied rounding by integer divisions any more and the qiov trimming can go away as well. Kevin