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