On Tue, 21 Nov 2023 at 12:47, Chiu, Chasel <chasel.chiu@xxxxxxxxx> wrote: > > > Hi Ard, > > I'm not familiar with how dma-ranges will be utilized, could you educate me more? > For example, PlatformInit may assign dma-ranges = <0 0x100000000> // 0 ~ 4GB, but we still want to prevent DMA access from some sensitive regions within this huge range. dma-ranges is typically used to describe how DMA addresses map to CPU physical addresses, (i.e., how the interconnect is wired up) and consists of a series of <cpu addr, dma addr, size> triplets describing which regions are valid and how they are translated. I suppose it would be possible to omit some otherwise accessible RAM regions from this description, but it will only prevent the DMA software layer from using the region, which it shouldn't be doing anyway if it is not available for allocation. IOW, the device will still be capable of DMA'ing into the memory if the hardware permits it. > Does that mean we rely on reserved-memory node to prevent DMA from some regions? /reserved-memory prevents RAM from being used to allocate DMA buffers, but it does not prevent a device driver from creating DMA transactions that access this memory. > Or are there any other nodes that PlatformInit/Payload has to provide? > If you want to prevent DMA access to sensitive RAM regions, you need an IOMMU, in which case you need to set dma-ranges appropriately for the DT node that describes the IOMMU, and everything else is managed by the IOMMU driver. If you don't have a IOMMU, playing with 'dma-ranges' is only going to give you a false sense of security (IMHO), given that it does not prevent the hardware from accessing the memory. (e.g., any DMA capable device using descriptors in RAM could be tricked into accessing the memory when such a descriptor gets corrupted) > > -----Original Message----- > > From: Simon Glass <sjg@xxxxxxxxxxxx> > > Sent: Tuesday, November 21, 2023 9:38 AM > > To: Ard Biesheuvel <ardb@xxxxxxxxxx> > > Cc: Tan, Lean Sheng <sheng.tan@xxxxxxxxxxxxx>; Devicetree Discuss > > <devicetree@xxxxxxxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Guo, Gua > > <gua.guo@xxxxxxxxx>; Chiu, Chasel <chasel.chiu@xxxxxxxxx>; Dong, Guo > > <guo.dong@xxxxxxxxx>; Brune, Maximilian <maximilian.brune@xxxxxxxxxxxxx> > > Subject: Re: DMA not supported below 4GB > > > > Hi Ard, > > > > On Tue, 21 Nov 2023 at 10:31, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > dma-ranges is supposed to handle this, but I'm not sure how well it > > interoperates with SMMUs (which remap DMA addresses into a virtual address > > space, and this can both solve and create issues when it comes to DMA address > > limits). > > > > > > Adding a 'no-dma-above-4g' property is a bad idea. Not only does it > > > result in potential inconsistencies wrt 'dma-ranges', it also only > > > describes 32 bits of DMA addressing capability, and other DMA > > > addressing limits exist too (40 bits is also common) > > > > OK, thank you for that. We will use dma-ranges for this. > > > > Regards, > > Simon > > > > > > > > > > > > > > > > > On Tue, 21 Nov 2023 at 12:01, Lean Sheng Tan <sheng.tan@xxxxxxxxxxxxx> > > wrote: > > >> > > >> Added Ard for some input on this. > > >> > > >> Best Regards, > > >> Lean Sheng Tan > > >> > > >> > > >> > > >> 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany > > >> Email: sheng.tan@xxxxxxxxxxxxx > > >> Phone: +49 234 68 94 188 > > >> Mobile: +49 176 76 113842 > > >> > > >> Registered office: Bochum > > >> Commercial register: Amtsgericht Bochum, HRB 17519 > > >> Management: Sebastian German, Eray Bazaar > > >> > > >> Data protection information according to Art. 13 GDPR > > >> > > >> > > >> On Tue, 14 Nov 2023 at 23:17, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > >>> > > >>> Hi, > > >>> > > >>> Some devices do not support DMA above 4GB. Is there a way to express > > >>> this in the devicetree? > > >>> > > >>> Should we add sometimes a 'no-dma-above-4g' property? > > >>> > > >>> Or should we be using dma-ranges for this? > > >>> > > >>> Regards, > > >>> Simon > > >>>
