[RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption

[Lendacky, Thomas]

On 5/28/19 10:17 AM, Koenig, Christian wrote:
> Hi Thomas,
> 
> Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
>> Hi, Tom,
>>
>> Thanks for the reply. The question is not graphics specific, but lies 
>> in your answer further below:
>>
>> On 5/28/19 4:48 PM, Lendacky, Thomas wrote:
>>> On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
>>> [SNIP]
>>> As for kernel vmaps and user-maps, those pages will be marked encrypted
>>> (unless explicitly made un-encrypted by calling set_memory_decrypted()).
>>> But, if you are copying to/from those areas into the un-encrypted DMA
>>> area then everything will be ok.
>>
>> The question is regarding the above paragraph.
>>
>> AFAICT,  set_memory_decrypted() only changes the fixed kernel map PTEs.
>> But when setting up other aliased PTEs to the exact same decrypted 
>> pages, for example using dma_mmap_coherent(), kmap_atomic_prot(), 
>> vmap() etc. What code is responsible for clearing the encrypted flag 
>> on those PTEs? Is there something in the x86 platform code doing that?
> 
> Tom actually explained this:
>> The encryption bit is bit-47 of a physical address.
> 
> In other words set_memory_decrypted() changes the physical address in 
> the PTEs of the kernel mapping and all other use cases just copy that 
> from there.

Except I don't think the PTE attributes are copied from the kernel mapping
in some cases. For example, dma_mmap_coherent() will create the same
vm_page_prot value regardless of whether or not the underlying memory is
encrypted or not. But kmap_atomic_prot() will return the kernel virtual
address of the page, so that would be fine.

This is an area that needs looking into to be sure it is working properly
with SME and SEV.

Thanks,
Tom

> 
> That's rather nifty, because this way everybody will either use or not 
> use encryption on the page.
> 
> Christian.
> 
>>
>> Thanks,
>> Thomas
>>
>>
>>>
>>> Things get fuzzy for me when it comes to the GPU access of the memory
>>> and what and how it is accessed.
>>>
>>> Thanks,
>>> Tom
>