All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thellstrom@vmware.com>
To: "Thomas.Lendacky@amd.com" <Thomas.Lendacky@amd.com>,
	"Christian.Koenig@amd.com" <Christian.Koenig@amd.com>,
	"thomas@shipmail.org" <thomas@shipmail.org>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Date: Tue, 28 May 2019 16:27:32 +0000	[thread overview]
Message-ID: <6dac8c560f75cae65e81a0f6466cbfdb270575e8.camel@vmware.com> (raw)
In-Reply-To: <a1bdbae7-009a-85ad-beb1-f938995274db@amd.com>

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

  reply	other threads:[~2019-05-28 16:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24  8:11 [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption Thomas Hellström (VMware)
2019-05-24  8:37 ` Koenig, Christian
2019-05-24  9:11   ` Thomas Hellstrom
2019-05-24  9:55     ` Thomas Hellstrom
2019-05-24 10:18       ` Koenig, Christian
2019-05-24 10:37         ` Thomas Hellstrom
2019-05-24 12:03           ` Koenig, Christian
2019-05-24 12:30             ` Thomas Hellstrom
2019-05-24 15:08               ` Alex Deucher
2019-05-28  7:31                 ` Thomas Hellstrom
2019-05-28 14:48                   ` Lendacky, Thomas
2019-05-28 15:05                     ` Christian König
2019-05-28 15:11                     ` Thomas Hellstrom
2019-05-28 15:17                       ` Koenig, Christian
2019-05-28 15:50                         ` Lendacky, Thomas
2019-05-28 16:27                           ` Thomas Hellstrom [this message]
2019-05-28 16:32                             ` Koenig, Christian
2019-05-28 17:00                               ` Lendacky, Thomas
2019-05-28 17:05                                 ` Thomas Hellstrom
2019-05-28 17:23                                   ` Lendacky, Thomas
2019-05-29  7:50                                     ` Christian König
2019-05-29  9:27                                       ` Thomas Hellstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6dac8c560f75cae65e81a0f6466cbfdb270575e8.camel@vmware.com \
    --to=thellstrom@vmware.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=thomas@shipmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.