[RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Thomas Hellstrom
thellstrom at vmware.com
Tue May 28 16:27:32 UTC 2019
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.
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.
/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
More information about the dri-devel
mailing list