Messages in this thread | | | Subject | Re: [PATCH v2 1/4] x86/mm: Export force_dma_unencrypted | From | Thomas Hellström (VMware) <> | Date | Wed, 4 Sep 2019 09:32:30 +0200 |
| |
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
| |