From patchwork Tue Jan 17 01:09:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 9519769 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7521060244 for ; Tue, 17 Jan 2017 01:12:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 619C528452 for ; Tue, 17 Jan 2017 01:12:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5637A28491; Tue, 17 Jan 2017 01:12:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id BA2BC28452 for ; Tue, 17 Jan 2017 01:12:33 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cTIHG-00008v-Na; Tue, 17 Jan 2017 01:09:34 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cTIHF-00008p-Jm for xen-devel@lists.xenproject.org; Tue, 17 Jan 2017 01:09:33 +0000 Received: from [193.109.254.147] by server-5.bemta-6.messagelabs.com id D9/02-11476-CCE6D785; Tue, 17 Jan 2017 01:09:32 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRWlGSWpSXmKPExsVybKJsh+7JvNo Ig50dmhbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8ayWyfZCtZLVbyf8ZG1gXGuWBcjF4eQwFRG iUstN1khnIlMEi9ezWPsYuTkYBHQlng75zETiM0mYCjx98kmti5GDg4JIHvJZw6QsAhQSePu9 2AlzAK5ElceTWYGsYUFQiS+P+0Ei3MKeEjMf/8YLM4r4CWxecN7FohdzYwSBx/uYgVJiAroSh z694cNokhQ4uTMJywQQ7Uklk/fBmZLCGRIzOuZwwphe0ksunEJylaTuHpuE/MERsFZSNpnIWl fwMi0ilGjOLWoLLVI19BUL6koMz2jJDcxM0fX0MBMLze1uDgxPTUnMalYLzk/dxMjMEAZgGAH 47dlAYcYJTmYlER5N+fWRgjxJeWnVGYkFmfEF5XmpBYfYpTh4FCS4J0MkhMsSk1PrUjLzAHGC kxagoNHSYT3GEiat7ggMbc4Mx0idYpRl+PUjdMvmYRY8vLzUqXEeZ+AFAmAFGWU5sGNgMXtJU ZZKWFeRqCjhHgKUotyM0tQ5V8xinMwKgnzBoFM4cnMK4Hb9AroCCagI67rVIMcUZKIkJJqYKy cffG7Vcfp33x5jizpMcsWnA8N2CnAocTn2dS/tz/Bnafo/e0ZGnWHZL21UgM+vOm98Zs1/3tx a+2UKpaE/kNe0rNK14b+M9Cc8Tnp49l1pkX7Tlx+wBV3TYV92STjL6fKq3dzPUzseNbh/WL+q Qkn7hRyPX2/fY1l6c6aNJlmK6fb95YyP1ViKc5INNRiLipOBAC50u+01gIAAA== X-Env-Sender: sstabellini@kernel.org X-Msg-Ref: server-6.tower-27.messagelabs.com!1484615368!82366306!1 X-Originating-IP: [198.145.29.136] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 57418 invoked from network); 17 Jan 2017 01:09:29 -0000 Received: from mail.kernel.org (HELO mail.kernel.org) (198.145.29.136) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 17 Jan 2017 01:09:29 -0000 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 739AE205E5; Tue, 17 Jan 2017 01:09:26 +0000 (UTC) Received: from [10.0.0.56] (c-50-131-44-19.hsd1.ca.comcast.net [50.131.44.19]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1ACA5205E4; Tue, 17 Jan 2017 01:09:25 +0000 (UTC) Date: Mon, 16 Jan 2017 17:09:24 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-X260 To: Andrii Anisov In-Reply-To: <1484565592-24897-3-git-send-email-andrii.anisov@gmail.com> Message-ID: References: <1484565592-24897-1-git-send-email-andrii.anisov@gmail.com> <1484565592-24897-3-git-send-email-andrii.anisov@gmail.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV using ClamSMTP Cc: xen-devel@lists.xenproject.org, julien.grall@arm.com, sstabellini@kernel.org, andrii_anisov@epam.com Subject: Re: [Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 16 Jan 2017, Andrii Anisov wrote: > From: Andrii Anisov > > Signed-off-by: Andrii Anisov Thanks for the patch! > arch/arm/xen/mm.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c > index ff812a2..dc83a35 100644 > --- a/arch/arm/xen/mm.c > +++ b/arch/arm/xen/mm.c > @@ -176,6 +176,16 @@ static int xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma, > return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size); > } As for the other patch, I would move xen_swiotlb_get_sgtable to drivers/xen/swiotlb-xen.c, if Konrad agrees. > +static int xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt, > + void *cpu_addr, dma_addr_t handle, size_t size, > + unsigned long attrs) > +{ > + if (__generic_dma_ops(dev)->get_sgtable) > + return __generic_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr, handle, > + size, attrs); > + return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size); > +} > + __generic_dma_ops(dev)->get_sgtable on ARM is implemented by arm_dma_get_sgtable, which doesn't work on foreign pages (pages for which bfn != pfn). If get_sgtable is guaranteed to be always called passing references to pages previously allocated with dma_alloc_coherent, then we don't have any issues, because those can't be foreign pages. I suggest we add an in-code comment to explain why this is safe, as for the previous patch. I think this is the case, but I am not 100% sure. On the other hand, if this function can be called passing as parameters cpu_addr and handle that could potentially refer to a foreign page, then we have a problem. On ARM, virt_to_phys doesn't work on some pages, in fact that is the reason why ARM has its own separate get_sgtable implementation (arm_dma_get_sgtable). But with Xen foreign pages, dma_to_pfn doesn't work either, because we have no way of finding out the pfn address corresponding to the mfn of the foreign page. Both arm_dma_get_sgtable and dma_common_get_sgtable wouldn't work. I have no solution to this problem, but maybe we could add a check like the following (also to the previous patch?). I haven't tested it, but I think it should work as long as page_is_ram is returns the correct value for the handle parameter. Signed-off-by: Stefano Stabellini diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index dc83a35..cd0441c 100644 --- a/arch/arm/xen/mm.c +++ b/arch/arm/xen/mm.c @@ -18,6 +18,7 @@ #include #include +#include #include #include #include @@ -180,9 +181,18 @@ static int xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt, void *cpu_addr, dma_addr_t handle, size_t size, unsigned long attrs) { - if (__generic_dma_ops(dev)->get_sgtable) + + if (__generic_dma_ops(dev)->get_sgtable) { + /* We can't handle foreign pages here. */ +#ifdef CONFIG_ARM + unsigned long bfn = dma_to_pfn(dev, handle); +#else + unsigned long bfn = handle >> PAGE_SHIFT; +#endif + BUG_ON (!page_is_ram(bfn)); return __generic_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr, handle, size, attrs); + } return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size); }