Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?

[Luis R. Rodriguez]

On Mon, Jun 25, 2018 at 05:08:08PM -0700, Bjorn Andersson wrote:
> On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote:
> 
> > On 7 June 2018 at 20:21, Bjorn Andersson <bjorn.andersson at linaro.org> 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,

That's still IO memory, and so it would be up to the specific device if
or not it could access the memory before a full write is done.

> 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.

I *believe* Vlastimil's seems to suggest kvmalloc(), but note that if getting the
memory to be contiguous fails, it would fallback to a non-contiguous (vmalloc)
allocation.

  Luis