Messages in this thread | | | Subject | Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool | From | Jon Masters <> | Date | Mon, 25 Jan 2021 00:26:52 -0500 |
| |
On 1/7/21 1:09 PM, Florian Fainelli wrote: > On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote: >> On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote: >>> Hi Greg and Konrad, >>> >>> This change is intended to be non-arch specific. Any arch that lacks DMA access >>> control and has devices not behind an IOMMU can make use of it. Could you share >>> why you think this should be arch specific? >> >> The idea behind non-arch specific code is it to be generic. The devicetree >> is specific to PowerPC, Sparc, and ARM, and not to x86 - hence it should >> be in arch specific code. > > In premise the same code could be used with an ACPI enabled system with > an appropriate service to identify the restricted DMA regions and unlock > them. > > More than 1 architecture requiring this function (ARM and ARM64 are the > two I can think of needing this immediately) sort of calls for making > the code architecture agnostic since past 2, you need something that scales. > > There is already code today under kernel/dma/contiguous.c that is only > activated on a CONFIG_OF=y && CONFIG_OF_RESERVED_MEM=y system, this is > no different.
<unrelated to these patches, which are useful for the case cited>
Just a note for history/archives that this approach would not be appropriate on general purpose Arm systems, such as SystemReady-ES edge/non-server platforms seeking to run general purpose distros. I want to have that in the record before someone at Arm (or NVidia, or a bunch of others that come to mind who have memory firewalls) gets an idea.
If you're working at an Arm vendor and come looking at this later thinking "wow, what a great idea!", please fix your hardware to have a real IOMMU/SMMU and real PCIe. You'll be pointed at this reply.
Jon.
-- Computer Architect
| |