From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933720AbbHJKwQ (ORCPT ); Mon, 10 Aug 2015 06:52:16 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:46284 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932446AbbHJKwN (ORCPT ); Mon, 10 Aug 2015 06:52:13 -0400 X-IronPort-AV: E=Sophos;i="5.15,644,1432598400"; d="scan'208";a="292926651" Date: Mon, 10 Aug 2015 11:50:45 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Julien Grall CC: , , , , , Konrad Rzeszutek Wilk , Boris Ostrovsky , "David Vrabel" Subject: Re: [PATCH v3 09/20] xen/biomerge: Don't allow biovec to be merge when Linux is not using 4KB page In-Reply-To: <1438966019-19322-10-git-send-email-julien.grall@citrix.com> Message-ID: References: <1438966019-19322-1-git-send-email-julien.grall@citrix.com> <1438966019-19322-10-git-send-email-julien.grall@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 7 Aug 2015, Julien Grall wrote: > On ARM all dma-capable devices on a same platform may not be protected > by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in > order to use correctly the device. > > While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant > mapping will screw this contiguous mapping. > > When Linux is using 64KB page granularitary, the page may be split > accross multiple non-contiguous MFN (Xen is using 4KB page > granularity). Therefore a DMA request will likely fail. > > Checking that a 64KB page is using contiguous MFN is tedious. For > now, always says that biovec are not mergeable. > > Signed-off-by: Julien Grall Please fix the grammar in the subject line. Reviewed-by: Stefano Stabellini > --- > Cc: Konrad Rzeszutek Wilk > Cc: Boris Ostrovsky > Cc: David Vrabel > > There is some ideas to check whether two biovec could be merged > (see [1]) but it's not critical and can be consider as a performance > improvement. > > Changes in v3: > - Update commit message > - s/mfn/bfn/ base on the new renaming > - Update TODO > > Changes in v2: > - Remove the workaround and check if the Linux page granularity > is the same as Xen or not > > [1] https://lkml.org/lkml/2015/7/17/418 > --- > drivers/xen/biomerge.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c > index 8ae2fc90..4da69db 100644 > --- a/drivers/xen/biomerge.c > +++ b/drivers/xen/biomerge.c > @@ -6,10 +6,18 @@ > bool xen_biovec_phys_mergeable(const struct bio_vec *vec1, > const struct bio_vec *vec2) > { > +#if XEN_PAGE_SIZE == PAGE_SIZE > unsigned long bfn1 = pfn_to_bfn(page_to_pfn(vec1->bv_page)); > unsigned long bfn2 = pfn_to_bfn(page_to_pfn(vec2->bv_page)); > > return __BIOVEC_PHYS_MERGEABLE(vec1, vec2) && > ((bfn1 == bfn2) || ((bfn1+1) == bfn2)); > +#else > + /* > + * XXX: Add support for merging bio_vec when using different page > + * size in Xen and Linux. ^ sizes > + */ > + return 0; > +#endif > } > EXPORT_SYMBOL(xen_biovec_phys_mergeable); > -- > 2.1.4 >