Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758271AbaKULtC (ORCPT ); Fri, 21 Nov 2014 06:49:02 -0500 Received: from smtp.citrix.com ([66.165.176.89]:54824 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754592AbaKULs7 (ORCPT ); Fri, 21 Nov 2014 06:48:59 -0500 X-IronPort-AV: E=Sophos;i="5.07,429,1413244800"; d="scan'208";a="193667428" Date: Fri, 21 Nov 2014 11:48:33 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Stefano Stabellini CC: , David Vrabel , Ian Campbell , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC] add a struct page* parameter to dma_map_ops.unmap_page In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 17 Nov 2014, Stefano Stabellini wrote: > Hi all, > I am writing this email to ask for your advice. > > On architectures where dma addresses are different from physical > addresses, it can be difficult to retrieve the physical address of a > page from its dma address. > > Specifically this is the case for Xen on arm and arm64 but I think that > other architectures might have the same issue. > > Knowing the physical address is necessary to be able to issue any > required cache maintenance operations when unmap_page, > sync_single_for_cpu and sync_single_for_device are called. > > Adding a struct page* parameter to unmap_page, sync_single_for_cpu and > sync_single_for_device would make Linux dma handling on Xen on arm and > arm64 much easier and quicker. > > I think that other drivers have similar problems, such as the Intel > IOMMU driver having to call find_iova and walking down an rbtree to get > the physical address in its implementation of unmap_page. > > Callers have the struct page* in their hands already from the previous > map_page call so it shouldn't be an issue for them. A problem does > exist however: there are about 280 callers of dma_unmap_page and > pci_unmap_page. We have even more callers of the dma_sync_single_for_* > functions. > > > > Is such a change even conceivable? How would one go about it? > > I think that Xen would not be the only one to gain from it, but I would > like to have a confirmation from others: given the magnitude of the > changes involved I would actually prefer to avoid them unless multiple > drivers/archs/subsystems could really benefit from them. Given the lack of interest from the community, I am going to drop this idea. > Cheers, > > Stefano > > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index d5d3881..158a765 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -31,8 +31,9 @@ struct dma_map_ops { > unsigned long offset, size_t size, > enum dma_data_direction dir, > struct dma_attrs *attrs); > - void (*unmap_page)(struct device *dev, dma_addr_t dma_handle, > - size_t size, enum dma_data_direction dir, > + void (*unmap_page)(struct device *dev, struct page *page, > + dma_addr_t dma_handle, size_t size, > + enum dma_data_direction dir, > struct dma_attrs *attrs); > int (*map_sg)(struct device *dev, struct scatterlist *sg, > int nents, enum dma_data_direction dir, > @@ -41,10 +42,10 @@ struct dma_map_ops { > struct scatterlist *sg, int nents, > enum dma_data_direction dir, > struct dma_attrs *attrs); > - void (*sync_single_for_cpu)(struct device *dev, > + void (*sync_single_for_cpu)(struct device *dev, struct page *page, > dma_addr_t dma_handle, size_t size, > enum dma_data_direction dir); > - void (*sync_single_for_device)(struct device *dev, > + void (*sync_single_for_device)(struct device *dev, struct page *page, > dma_addr_t dma_handle, size_t size, > enum dma_data_direction dir); > void (*sync_sg_for_cpu)(struct device *dev, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/