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

[Koenig, Christian]

Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
> On Tue, 2019-05-28 at 15:50 +0000, Lendacky, Thomas wrote:
>> 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
> +1!
>
>> 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.
> Yes, on 64-bit systems. On 32-bit systems (do they exist with SEV?),
> they don't.

I don't think so, but feel free to prove me wrong Tom.

> And similarly TTM user-space mappings and vmap() doesn't copy from the
> kernel map either,  so I think we actually do need to modify the page-
> prot like done in the patch.

Well the problem is that this won't have any effect.

As Tom explained encryption is not implemented as a page protection bit, 
but rather as part of the physical address of the part.

I have no idea how that is actually handled thought,
Christian.

>
> /Thomas
>
>> 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