linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org,
	"pv-drivers@vmware.com" <pv-drivers@vmware.com>,
	"Thomas Hellstrom" <thellstrom@vmware.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: dma_mmap_fault discussion
Date: Thu, 5 Sep 2019 19:05:43 +0200	[thread overview]
Message-ID: <cbbb0e95-8df1-9ab8-59ad-81bd7f3933fa@shipmail.org> (raw)
In-Reply-To: <20190905152438.GA18286@infradead.org>

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



  parent reply	other threads:[~2019-09-05 17:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-05 10:35 [RFC PATCH 0/2] Fix SEV user-space mapping of unencrypted coherent memory Thomas Hellström (VMware)
2019-09-05 10:35 ` [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit Thomas Hellström (VMware)
2019-09-05 14:15   ` Dave Hansen
2019-09-05 15:21     ` Thomas Hellström (VMware)
2019-09-05 15:24       ` Christoph Hellwig
2019-09-05 16:40         ` Thomas Hellström (VMware)
2019-09-05 17:05         ` Thomas Hellström (VMware) [this message]
2019-09-06  6:32           ` dma_mmap_fault discussion Christoph Hellwig
2019-09-06  7:10             ` Thomas Hellström (VMware)
2019-09-06  7:20               ` Christoph Hellwig
2019-09-10  8:37                 ` Thomas Hellström (VMware)
2019-09-10 16:11         ` [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit Andy Lutomirski
2019-09-10 19:26           ` Thomas Hellström (VMware)
2019-09-11  4:18             ` Andy Lutomirski
2019-09-11  7:49               ` Thomas Hellström (VMware)
2019-09-11 18:03                 ` Andy Lutomirski
2019-09-12  8:29                   ` Thomas Hellström (VMware)
2019-09-11  9:08             ` Koenig, Christian
2019-09-11 10:10               ` TTM huge page-faults WAS: " Thomas Hellström (VMware)
2019-09-11 14:06                 ` Koenig, Christian
2019-09-11 15:08                   ` Thomas Hellström (VMware)
2019-09-24 12:03                     ` Koenig, Christian
2019-09-05 15:59       ` Dave Hansen
2019-09-05 16:29         ` Thomas Hellström (VMware)
2019-09-05 10:35 ` [RFC PATCH 2/2] dma-mapping: Fix dma_pgprot() for unencrypted coherent pages Thomas Hellström (VMware)
2019-09-05 11:23 ` [RFC PATCH 0/2] Fix SEV user-space mapping of unencrypted coherent memory Christoph Hellwig
2019-09-10  6:11   ` Christoph Hellwig
2019-09-10  6:25     ` Thomas Hellström (VMware)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cbbb0e95-8df1-9ab8-59ad-81bd7f3933fa@shipmail.org \
    --to=thomas_os@shipmail.org \
    --cc=christian.koenig@amd.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pv-drivers@vmware.com \
    --cc=thellstrom@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).