Messages in this thread | | | Subject | Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption | From | Thomas Hellström (VMware) <> | Date | Wed, 4 Sep 2019 14:35:11 +0200 |
| |
On 9/4/19 1:10 PM, Koenig, Christian wrote: > Am 04.09.19 um 10:19 schrieb Thomas Hellström (VMware): >> Hi, Christian, >> >> On 9/4/19 9:33 AM, Koenig, Christian wrote: >>> Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware): >>>> On 9/3/19 10:51 PM, Dave Hansen wrote: >>>>> On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: >>>>>> So the question here should really be, can we determine already at >>>>>> mmap >>>>>> time whether backing memory will be unencrypted and adjust the *real* >>>>>> vma->vm_page_prot under the mmap_sem? >>>>>> >>>>>> Possibly, but that requires populating the buffer with memory at mmap >>>>>> time rather than at first fault time. >>>>> I'm not connecting the dots. >>>>> >>>>> vma->vm_page_prot is used to create a VMA's PTEs regardless of if they >>>>> are created at mmap() or fault time. If we establish a good >>>>> vma->vm_page_prot, can't we just use it forever for demand faults? >>>> With SEV I think that we could possibly establish the encryption flags >>>> at vma creation time. But thinking of it, it would actually break with >>>> SME where buffer content can be moved between encrypted system memory >>>> and unencrypted graphics card PCI memory behind user-space's back. >>>> That would imply killing all user-space encrypted PTEs and at fault >>>> time set up new ones pointing to unencrypted PCI memory.. >>> Well my problem is where do you see encrypted system memory here? >>> >>> At least for AMD GPUs all memory accessed must be unencrypted and that >>> counts for both system as well as PCI memory. >> We're talking SME now right? >> >> The current SME setup is that if a device's DMA mask says it's capable >> of addressing the encryption bit, coherent memory will be encrypted. >> The memory controllers will decrypt for the device on the fly. >> Otherwise coherent memory will be decrypted. >> >>> So I don't get why we can't assume always unencrypted and keep it >>> like that. >> I see two reasons. First, it would break with a real device that >> signals it's capable of addressing the encryption bit. > Why? Because we don't use dma_mmap_coherent()?
Well, assuming always unencrypted would obviously break on a real device with encrypted coherent memory?
dma_mmap_coherent() would work from the encryption point of view (although I think it's currently buggy and will send out an RFC for what I believe is a fix for that).
> > I've already talked with Christoph that we probably want to switch TTM > over to using that instead to also get rid of the ttm_io_prot() hack.
OK, would that mean us ditching other memory modes completely? And on-the-fly caching transitions? or is it just for the special case of cached coherent memory? Do we need to cache the coherent kernel mappings in TTM as well, for ttm_bo_kmap()?
/Thomas
> > Regards, > Christian. > >> Second I can imagine unaccelerated setups (something like vkms using >> prime feeding a VNC connection) where we actually want the TTM buffers >> encrypted to protect data. >> >> But at least the latter reason is way far out in the future. >> >> So for me I'm ok with that if that works for you? >> >> /Thomas >> >> >>> Regards, >>> Christian. >>
| |