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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
