lkml.org 
[lkml]   [2019]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subjectdma_mmap_fault discussion
From
Date
Hi, Christoph,


On 9/5/19 5:24 PM, Christoph Hellwig wrote:
> On Thu, Sep 05, 2019 at 05:21:24PM +0200, Thomas Hellström (VMware) wrote:
>> On 9/5/19 4:15 PM, Dave Hansen wrote:
>>> Hi Thomas,
>>>
>>> Thanks for the second batch of patches! These look much improved on all
>>> fronts.
>> Yes, although the TTM functionality isn't in yet. Hopefully we won't have to
>> bother you with those though, since this assumes TTM will be using the dma
>> API.
> Please take a look at dma_mmap_prepare and dma_mmap_fault in this
> branch:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-mmap-improvements
>
> they should allow to fault dma api pages in the page fault handler. But
> this is totally hot off the press and not actually tested for the last
> few patches. Note that I've also included your two patches from this
> series to handle SEV.

I took a quick look at the interfaces and have two questions:

1) dma_mmap_prepare(), would it be possible to drop the references to
the actual coherent region? The thing is that TTM doesn't know at mmap
time what memory will be backing the region. It can be VRAM, coherent
memory or system memory. Also see below:

2) @cpu_addr and @dma_addr are the values pointing at the beginning of
an allocated chunk, right? The reason I'm asking is that TTM's coherent
memory pool is sub-allocating from larger chunks into smaller PAGE_SIZE
chunks, which means that a TTM buffer object may be randomly split
across larger chunks, which means we have to store these values for each
PAGE_SiZE chunk.

Thanks,
Thomas


\
 
 \ /
  Last update: 2019-09-05 19:07    [W:0.136 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site