| Message ID | 20190903131504.18935-1-thomas_os@shipmail.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Have TTM support SEV encryption with coherent memory | expand |
On Tue, Sep 03, 2019 at 03:15:00PM +0200, Thomas Hellström (VMware) wrote: > With SEV memory encryption and in some cases also with SME memory > encryption, coherent memory is unencrypted. In those cases, TTM doesn't > set up the correct page protection. Fix this by having the TTM > coherent page allocator call into the platform code to determine whether > coherent memory is encrypted or not, and modify the page protection if > it is not. > > v2: > - Use force_dma_unencrypted() rather than sev_active() to catch also the > special SME encryption cases. We should probably cc Christoph Hellwig on this ... better to hear his screams before merging than afterwards. As much as I don't support screaming maintainers, that seems the least bad option here. -Daniel
On 9/3/19 3:15 PM, Thomas Hellström (VMware) wrote: > With SEV memory encryption and in some cases also with SME memory > encryption, coherent memory is unencrypted. In those cases, TTM doesn't > set up the correct page protection. Fix this by having the TTM > coherent page allocator call into the platform code to determine whether > coherent memory is encrypted or not, and modify the page protection if > it is not. > > v2: > - Use force_dma_unencrypted() rather than sev_active() to catch also the > special SME encryption cases. So, this patchset is obviously withdrawn since a) We shouldn't have TTM shortcut the dma API in this way. b) To reviewers it was pretty unclear why this was needed in the first place, and became even more unclear in the context of the TTM fault handler. I've just send out an RFC patchset that basically does the same but in the context of dma_mmap_coherent() I hope this clears things up and we should hopefully be able to use a new dma API function from within the TTM fault handler. Thanks, Thomas