All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thomas@shipmail.org>
To: "Koenig, Christian" <Christian.Koenig@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Date: Fri, 24 May 2019 11:55:30 +0200	[thread overview]
Message-ID: <d59cb481-1360-25eb-a2da-1ae64c648daf@shipmail.org> (raw)
In-Reply-To: <d397836b-13a4-b6cd-e059-035203f2edc6@shipmail.org>

On 5/24/19 11:11 AM, Thomas Hellstrom wrote:
> Hi, Christian,
>
> On 5/24/19 10:37 AM, Koenig, Christian wrote:
>> Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
>>> [CAUTION: External Email]
>>>
>>> From: Thomas Hellstrom <thellstrom@vmware.com>
>>>
>>> With SEV encryption, all DMA memory must be marked decrypted
>>> (AKA "shared") for devices to be able to read it. In the future we 
>>> might
>>> want to be able to switch normal (encrypted) memory to decrypted in 
>>> exactly
>>> the same way as we handle caching states, and that would require 
>>> additional
>>> memory pools. But for now, rely on memory allocated with
>>> dma_alloc_coherent() which is already decrypted with SEV enabled. 
>>> Set up
>>> the page protection accordingly. Drivers must detect SEV enabled and 
>>> switch
>>> to the dma page pool.
>>>
>>> This patch has not yet been tested. As a follow-up, we might want to
>>> cache decrypted pages in the dma page pool regardless of their caching
>>> state.
>> This patch is unnecessary, SEV support already works fine with at least
>> amdgpu and I would expect that it also works with other drivers as well.
>>
>> Also see this patch:
>>
>> commit 64e1f830ea5b3516a4256ed1c504a265d7f2a65c
>> Author: Christian König <christian.koenig@amd.com>
>> Date:   Wed Mar 13 10:11:19 2019 +0100
>>
>>       drm: fallback to dma_alloc_coherent when memory encryption is 
>> active
>>
>>       We can't just map any randome page we get when memory 
>> encryption is
>>       active.
>>
>>       Signed-off-by: Christian König <christian.koenig@amd.com>
>>       Acked-by: Alex Deucher <alexander.deucher@amd.com>
>>       Link: https://patchwork.kernel.org/patch/10850833/
>>
>> Regards,
>> Christian.
>
> Yes, I noticed that. Although I fail to see where we automagically 
> clear the PTE encrypted bit when mapping coherent memory? For the 
> linear kernel map, that's done within dma_alloc_coherent() but for 
> kernel vmaps and and user-space maps? Is that done automatically by 
> the x86 platform layer?
>
> /Thomas
>
And, as a follow up question, why do we need dma_alloc_coherent() when 
using SME? I thought the hardware performs the decryption when DMA-ing 
to / from an encrypted page with SME, but not with SEV?

Thanks, Thomas



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-05-24  9:55 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 [this message]
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
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=d59cb481-1360-25eb-a2da-1ae64c648daf@shipmail.org \
    --to=thomas@shipmail.org \
    --cc=Christian.Koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=thellstrom@vmware.com \
    /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.