Re: [PATCH v2 1/4] x86/mm: Export force_dma_unencrypted

[Thomas HellstrÃm (VMware)]

On 9/4/19 8:58 AM, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 10:46:18PM +0200, Thomas HellstrÃm (VMware) wrote:
> > What I mean with "from an engineering perspective" is that drivers would end
> > up with a non-trivial amount of code supporting purely academic cases:
> > Setups where software rendering would be faster than gpu accelerated, and
> > setups on platforms where the driver would never run anyway because the
> > device would never be supported on that platform...
> And actually work on cases you previously called academic and which now
> matter to you because your employer has a suddent interest in SEV.
> Academic really is in the eye of the beholder (and of those who pay
> the bills).

But in this particular case we *do* adhere to the dma api, at least as 
far as we can. But we're missing functionality.

> > That is not really true. The dma API can't handle faulting of coherent pages
> > which is what this series is really all about supporting also with SEV
> > active. To handle the case where we move graphics buffers or send them to
> > swap space while user-space have them mapped.
> And the only thing we need to support the fault handler is to add an
> offset to the dma_mmap_* APIs.  Which I had planned to do for Christian
> (one of the few grapics developers who actually tries to play well
> with the rest of the kernel instead of piling hacks over hacks like
> many others) anyway, but which hasn't happened yet.

That sounds great. Is there anything I can do to help out? I thought 
this was more or less a dead end since the current dma_mmap_ API 
requires the mmap_sem to be held in write mode (modifying the 
vma->vm_flags) whereas fault() only offers read mode. But that would 
definitely work.

> > Still, I need a way forward and my questions weren't really answered by
> > this.
> This is pretty demanding.  If you "need" a way forward just work with
> all the relevant people instead of piling ob local hacks.

But I think that was what I was trying to initiate. The question was

"If it's the latter, then I would like to reiterate that it would be 
better that we work to come up with a long term plan to add what's 
missing to the DMA api to help graphics drivers use coherent memory?"

And since you NAK'd the original patches, I was sort of hoping for a 
point in the right direction.

Thanks,

Thomas