On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote: > On 7 June 2018 at 20:21, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote: [..] > >> > >> Why not just use kmalloc, it will always return a DMAable buffer. > >> > > > > For the buffers being targeted by request_firmware_into_buf() the > > problem is that some of them has requirements of physical placement and > > they are all too big for kmalloc() (i.e. tens of mb). > > > > > > For the dma_alloc_coherent() buffer that was mentioned earlier, which is > > not related to the firmware loading, it's not used because the buffer is > > passed to secure world, which temporarily locks Linux out from the > > memory region. Traditionally this region was kmalloc'ed downstream, but > > due to speculative access violations this code moved to use the DMA > > streaming API, although there's no actual DMA going on. > > > > OK, so you are relying on the fact that dma_alloc_coherent() gives you > a device mapping (because the qcom_scm device is described as non > cache coherent), but this sounds risky to me. The linear alias of that > memory will still be mapped cacheable, and could potentially still be > accessed speculatively AFAIK. > Yes and we are aware of the risk of having the linear alias present, but have yet to find a suitable way to handle this. The proposed mechanism was to use reserved-memory and memremap() the region while it should be available in Linux, but while this would work for some cases (e.g. memory regions for semi-static firmware executed by co-processors) it doesn't handle the scenarios where the memory-need is dynamic. So suggestions are very welcome on how to better handle this. Regards, Bjorn _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
