linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-arch@vger.kernel.org, linux-efi@vger.kernel.org,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	linux-mm@kvack.org, iommu@lists.linux-foundation.org,
	"Rik van Riel" <riel@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Larry Woodman" <lwoodman@redhat.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Andy Lutomirski" <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Andrey Ryabinin" <aryabinin@virtuozzo.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Dmitry Vyukov" <dvyukov@google.com>
Subject: Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption
Date: Tue, 15 Nov 2016 12:29:35 -0600	[thread overview]
Message-ID: <4d97f998-5835-f4e0-9840-7f7979251275@amd.com> (raw)
In-Reply-To: <20161115171443-mutt-send-email-mst@kernel.org>

On 11/15/2016 9:16 AM, Michael S. Tsirkin wrote:
> On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote:
>> Since DMA addresses will effectively look like 48-bit addresses when the
>> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
>> device performing the DMA does not support 48-bits. SWIOTLB will be
>> initialized to create un-encrypted bounce buffers for use by these devices.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>>  arch/x86/include/asm/dma-mapping.h |    5 ++-
>>  arch/x86/include/asm/mem_encrypt.h |    5 +++
>>  arch/x86/kernel/pci-dma.c          |   11 ++++---
>>  arch/x86/kernel/pci-nommu.c        |    2 +
>>  arch/x86/kernel/pci-swiotlb.c      |    8 ++++-
>>  arch/x86/mm/mem_encrypt.c          |   17 +++++++++++
>>  include/linux/swiotlb.h            |    1 +
>>  init/main.c                        |   13 ++++++++
>>  lib/swiotlb.c                      |   58 +++++++++++++++++++++++++++++++-----
>>  9 files changed, 103 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h
>> index 4446162..c9cdcae 100644
>> --- a/arch/x86/include/asm/dma-mapping.h
>> +++ b/arch/x86/include/asm/dma-mapping.h

..SNIP...

>>  
>> +/*
>> + * If memory encryption is active, the DMA address for an encrypted page may
>> + * be beyond the range of the device. If bounce buffers are required be sure
>> + * that they are not on an encrypted page. This should be called before the
>> + * iotlb area is used.
> 
> Makes sense, but I think at least a dmesg warning here
> might be a good idea.

Good idea.  Should it be a warning when it is first being set up or
a warning the first time the bounce buffers need to be used.  Or maybe
both?

> 
> A boot flag that says "don't enable devices that don't support
> encryption" might be a good idea, too, since most people
> don't read dmesg output and won't notice the message.

I'll look into this. It might be something that can be checked as
part of the device setting its DMA mask or the first time a DMA
API is used if the device doesn't explicitly set its mask.

Thanks,
Tom

> 
> 

  reply	other threads:[~2016-11-15 18:29 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-10  0:34 [RFC PATCH v3 00/20] x86: Secure Memory Encryption (AMD) Tom Lendacky
2016-11-10  0:34 ` [RFC PATCH v3 01/20] x86: Documentation for AMD Secure Memory Encryption (SME) Tom Lendacky
2016-11-10 10:51   ` Borislav Petkov
2016-11-14 17:15     ` Tom Lendacky
2016-11-10  0:34 ` [RFC PATCH v3 02/20] x86: Set the write-protect cache mode for full PAT support Tom Lendacky
2016-11-10 13:14   ` Borislav Petkov
2016-11-11  1:26     ` Kani, Toshimitsu
2016-11-14 16:51       ` Tom Lendacky
2016-11-10  0:34 ` [RFC PATCH v3 03/20] x86: Add the Secure Memory Encryption cpu feature Tom Lendacky
2016-11-11 11:53   ` Borislav Petkov
2016-11-10  0:35 ` [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME Tom Lendacky
2016-11-15 12:10   ` Joerg Roedel
2016-11-15 12:14     ` Borislav Petkov
2016-11-15 14:40       ` Tom Lendacky
2016-11-15 15:33         ` Borislav Petkov
2016-11-15 16:06           ` Tom Lendacky
2016-11-15 16:33             ` Borislav Petkov
2016-11-15 17:08               ` Tom Lendacky
2016-11-15 21:22       ` Tom Lendacky
2016-11-15 21:33         ` Borislav Petkov
2016-11-15 22:01           ` Tom Lendacky
2016-11-15 14:32     ` Tom Lendacky
2016-11-10  0:35 ` [RFC PATCH v3 05/20] x86: Add Secure Memory Encryption (SME) support Tom Lendacky
2016-11-10  0:35 ` [RFC PATCH v3 06/20] x86: Add support to enable SME during early boot processing Tom Lendacky
2016-11-14 17:29   ` Borislav Petkov
2016-11-14 18:18     ` Tom Lendacky
2016-11-14 20:01       ` Borislav Petkov
2016-11-10  0:35 ` [RFC PATCH v3 07/20] x86: Provide general kernel support for memory encryption Tom Lendacky
2016-11-10  0:36 ` [RFC PATCH v3 08/20] x86: Add support for early encryption/decryption of memory Tom Lendacky
2016-11-16 10:46   ` Borislav Petkov
2016-11-16 19:22     ` Tom Lendacky
2016-11-10  0:36 ` [RFC PATCH v3 09/20] x86: Insure that boot memory areas are mapped properly Tom Lendacky
2016-11-17 12:20   ` Borislav Petkov
2016-11-19 18:12     ` Tom Lendacky
2016-11-10  0:36 ` [RFC PATCH v3 10/20] Add support to access boot related data in the clear Tom Lendacky
2016-11-11 16:17   ` Kani, Toshimitsu
2016-11-14 16:24     ` Tom Lendacky
2016-11-17 15:55   ` Borislav Petkov
2016-11-19 18:33     ` Tom Lendacky
2016-11-20 23:04       ` Borislav Petkov
2016-12-07 13:19   ` Matt Fleming
2016-12-09 14:26     ` Tom Lendacky
2016-11-10  0:36 ` [RFC PATCH v3 11/20] x86: Add support for changing memory encryption attribute Tom Lendacky
2016-11-17 17:39   ` Borislav Petkov
2016-11-19 18:48     ` Tom Lendacky
2016-11-21  8:27       ` Borislav Petkov
2016-11-10  0:37 ` [RFC PATCH v3 12/20] x86: Decrypt trampoline area if memory encryption is active Tom Lendacky
2016-11-17 18:09   ` Borislav Petkov
2016-11-19 18:50     ` Tom Lendacky
2016-11-10  0:37 ` [RFC PATCH v3 13/20] x86: DMA support for memory encryption Tom Lendacky
2016-11-15 14:39   ` Radim Krčmář
2016-11-15 17:02     ` Tom Lendacky
2016-11-15 18:17       ` Radim Krčmář
2016-11-15 20:33         ` Tom Lendacky
2016-11-15 15:16   ` Michael S. Tsirkin
2016-11-15 18:29     ` Tom Lendacky [this message]
2016-11-15 19:16       ` Michael S. Tsirkin
2016-11-22 11:38       ` Borislav Petkov
2016-11-22 15:22         ` Michael S. Tsirkin
2016-11-22 15:41           ` Borislav Petkov
2016-11-22 20:41             ` Michael S. Tsirkin
2016-11-10  0:37 ` [RFC PATCH v3 14/20] iommu/amd: Disable AMD IOMMU if memory encryption is active Tom Lendacky
2016-11-14 16:32   ` Joerg Roedel
2016-11-14 16:48     ` Tom Lendacky
2016-11-10  0:37 ` [RFC PATCH v3 15/20] x86: Check for memory encryption on the APs Tom Lendacky
2016-11-22 19:25   ` Borislav Petkov
2016-11-29 18:00     ` Tom Lendacky
2016-11-10  0:37 ` [RFC PATCH v3 16/20] x86: Do not specify encrypted memory for video mappings Tom Lendacky
2016-11-10  0:38 ` [RFC PATCH v3 17/20] x86/kvm: Enable Secure Memory Encryption of nested page tables Tom Lendacky
2016-11-10  0:38 ` [RFC PATCH v3 18/20] x86: Access the setup data through debugfs un-encrypted Tom Lendacky
2016-11-10  0:38 ` [RFC PATCH v3 19/20] x86: Add support to make use of Secure Memory Encryption Tom Lendacky
2016-11-24 12:50   ` Borislav Petkov
2016-11-29 18:40     ` Tom Lendacky
2016-11-10  0:38 ` [RFC PATCH v3 20/20] " Tom Lendacky
2016-11-22 18:58   ` Borislav Petkov
2016-11-26 20:47   ` Borislav Petkov
2016-11-29 18:48     ` Tom Lendacky
2016-11-29 19:56       ` Borislav Petkov

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=4d97f998-5835-f4e0-9840-7f7979251275@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=lwoodman@redhat.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=riel@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).