Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752937AbaKQOMS (ORCPT ); Mon, 17 Nov 2014 09:12:18 -0500 Received: from smtp.citrix.com ([66.165.176.89]:33751 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752408AbaKQOMQ (ORCPT ); Mon, 17 Nov 2014 09:12:16 -0500 X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192046949" Date: Mon, 17 Nov 2014 14:11:51 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: CC: David Vrabel , Ian Campbell , , , , , , , Stefano Stabellini , , , , , , , , , , , , , , Subject: [RFC] add a struct page* parameter to dma_map_ops.unmap_page Message-ID: 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 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. 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/