Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2957893ybl; Thu, 29 Aug 2019 15:48:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqy0doz4VLJ8jhEtUh/vJBsr6MtXeYFZJ+T6RbbK2yVzZXn6WNWNLWRuRo817cbHQTLiJDDz X-Received: by 2002:a17:90a:c70f:: with SMTP id o15mr1555107pjt.37.1567118894726; Thu, 29 Aug 2019 15:48:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567118894; cv=none; d=google.com; s=arc-20160816; b=zxgVWSjoBwV5p8rt3qX2kaaiYezfGYt9eZAzWk6C0ud/mqlNRt7efXIxTRIADE1jSK F7lh2SN2DM4Oo4Ob/7dB0cwTpFGHOPWMVqAvax+X8g+ghMRjPG5Qk9Qex42fDeJPnjv+ +T08hBEH4XaHIJTU92yt3aTPkV2jVzYTRkOOLgBLHBcJwl536nfccMg1ZlBP1/8BRBIj YhJUUOIxfMtFRe0DpFh3Z4d/lCb1AjTGPOe2my4QIThzk4Oo9pkV9aAQg7R75T7K25yK sgYOl3BlXb9TV9nZHZlB0OZ0Mg6eUtcyIcI4By2vw8TlOUWk/UxgA+TJ1G2J8QEtQBWB ybMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature; bh=3cCEjgiVYTOntiyWCeQ+e31SwwiqnCIr3o/ZGmG3HIM=; b=rR16KriEp948sMg9OKRz9u3lnNoswsiBn6cymKefvF3i7GPHEwwO9js2oGHxdlcnx6 EGxmUXFetD7L0nWcDL0GekZ2vHfM7Cw37MHmAkk5RAbKN6ykklKYR3T1GYhJEVIPQkxP 0Vv7GKS20astrHhsj5aEsAquGZK/30BjxllgGuX0Kf/rj0c521nuAHoEBN5joYnBS7lm OXfOfmlUJXn7OqtNCXXErSeYzkVDgJeA1/W4thSAiGC93cq+pH+EePMDA99NJTc/3phX +Nt97x7jeyYs4CYwZQIDaDC24mUwq1mKEtkQPGDXeYZ/44ilFuDRqVNraRBGKjfyUfLH bGBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=CVS10g5r; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 26si3427222pja.6.2019.08.29.15.47.59; Thu, 29 Aug 2019 15:48:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=CVS10g5r; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728407AbfH2WrJ (ORCPT + 99 others); Thu, 29 Aug 2019 18:47:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:60052 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728162AbfH2WrI (ORCPT ); Thu, 29 Aug 2019 18:47:08 -0400 Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4A34F22CEA; Thu, 29 Aug 2019 22:47:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567118827; bh=sm/nKdM9UsIhUb6FhRZ+kQtsA7U5a/JALl6VUJ4+q2Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CVS10g5rx/XTa3zAqZYWqPzwDeS4hTCFiG0WkGUDDDvXuwqoTWMRvCZy+4vIOeCa2 EitnmAkmPhgz8IptegpIpXy8m7xG5dzQc1bFjFWw2Ct4h9eHOTj1kDXw4/JUM1rcEQ U7l6bmF3dACn+UY4Le2fqo/wliNCIcEHTnE8qZXE= Date: Thu, 29 Aug 2019 15:47:06 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Christoph Hellwig cc: Stefano Stabellini , Konrad Rzeszutek Wilk , x86@kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 07/11] swiotlb-xen: use the same foreign page check everywhere In-Reply-To: <20190826121944.515-8-hch@lst.de> Message-ID: References: <20190826121944.515-1-hch@lst.de> <20190826121944.515-8-hch@lst.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 26 Aug 2019, Christoph Hellwig wrote: > xen_dma_map_page uses a different and more complicated check for foreign > pages than the other three cache maintainance helpers. Switch it to the > simpler pfn_valid method a well, and document the scheme with a single > improved comment in xen_dma_map_page. > > Signed-off-by: Christoph Hellwig Reviewed-by: Stefano Stabellini > --- > include/xen/arm/page-coherent.h | 31 +++++++++---------------------- > 1 file changed, 9 insertions(+), 22 deletions(-) > > diff --git a/include/xen/arm/page-coherent.h b/include/xen/arm/page-coherent.h > index 0e244f4fec1a..07c104dbc21f 100644 > --- a/include/xen/arm/page-coherent.h > +++ b/include/xen/arm/page-coherent.h > @@ -41,23 +41,17 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page, > dma_addr_t dev_addr, unsigned long offset, size_t size, > enum dma_data_direction dir, unsigned long attrs) > { > - unsigned long page_pfn = page_to_xen_pfn(page); > - unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr); > - unsigned long compound_pages = > - (1< - bool local = (page_pfn <= dev_pfn) && > - (dev_pfn - page_pfn < compound_pages); > + unsigned long pfn = PFN_DOWN(dev_addr); > > /* > - * Dom0 is mapped 1:1, while the Linux page can span across > - * multiple Xen pages, it's not possible for it to contain a > - * mix of local and foreign Xen pages. So if the first xen_pfn > - * == mfn the page is local otherwise it's a foreign page > - * grant-mapped in dom0. If the page is local we can safely > - * call the native dma_ops function, otherwise we call the xen > - * specific function. > + * Dom0 is mapped 1:1, and while the Linux page can span across multiple > + * Xen pages, it is not possible for it to contain a mix of local and > + * foreign Xen pages. Calling pfn_valid on a foreign mfn will always > + * return false, so if pfn_valid returns true the pages is local and we > + * can use the native dma-direct functions, otherwise we call the Xen > + * specific version. > */ > - if (local) > + if (pfn_valid(pfn)) > dma_direct_map_page(hwdev, page, offset, size, dir, attrs); > else > __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs); > @@ -67,14 +61,7 @@ static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle, > size_t size, enum dma_data_direction dir, unsigned long attrs) > { > unsigned long pfn = PFN_DOWN(handle); > - /* > - * Dom0 is mapped 1:1, while the Linux page can be spanned accross > - * multiple Xen page, it's not possible to have a mix of local and > - * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a > - * foreign mfn will always return false. If the page is local we can > - * safely call the native dma_ops function, otherwise we call the xen > - * specific function. > - */ > + > if (pfn_valid(pfn)) > dma_direct_unmap_page(hwdev, handle, size, dir, attrs); > else > -- > 2.20.1 >