Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752587AbdFNQu7 (ORCPT ); Wed, 14 Jun 2017 12:50:59 -0400 Received: from mail.skyhub.de ([5.9.137.197]:59752 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751714AbdFNQu4 (ORCPT ); Wed, 14 Jun 2017 12:50:56 -0400 Date: Wed, 14 Jun 2017 18:50:52 +0200 From: Borislav Petkov To: Tom Lendacky Cc: linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, iommu@lists.linux-foundation.org, Rik van Riel , Radim =?utf-8?B?S3LEjW3DocWZ?= , Toshimitsu Kani , Arnd Bergmann , Jonathan Corbet , Matt Fleming , "Michael S. Tsirkin" , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Larry Woodman , Brijesh Singh , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Dave Young , Thomas Gleixner , Dmitry Vyukov Subject: Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME Message-ID: <20170614165052.fyn5t4gkq5leczcc@pd.tnic> References: <20170607191309.28645.15241.stgit@tlendack-t1.amdoffice.net> <20170607191732.28645.42876.stgit@tlendack-t1.amdoffice.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170607191732.28645.42876.stgit@tlendack-t1.amdoffice.net> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2776 Lines: 82 On Wed, Jun 07, 2017 at 02:17:32PM -0500, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate action - if necessary. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/mem_encrypt.h | 8 ++++++++ > include/asm-generic/mem_encrypt.h | 5 +++++ > include/linux/dma-mapping.h | 9 +++++++++ > lib/swiotlb.c | 3 +++ > 4 files changed, 25 insertions(+) > > diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h > index f1215a4..c7a2525 100644 > --- a/arch/x86/include/asm/mem_encrypt.h > +++ b/arch/x86/include/asm/mem_encrypt.h > @@ -69,6 +69,14 @@ static inline bool sme_active(void) > return !!sme_me_mask; > } > > +static inline u64 sme_dma_mask(void) > +{ > + if (!sme_me_mask) > + return 0ULL; > + > + return ((u64)sme_me_mask << 1) - 1; > +} > + > /* > * The __sme_pa() and __sme_pa_nodebug() macros are meant for use when > * writing to or comparing values from the cr3 register. Having the > diff --git a/include/asm-generic/mem_encrypt.h b/include/asm-generic/mem_encrypt.h > index b55c3f9..fb02ff0 100644 > --- a/include/asm-generic/mem_encrypt.h > +++ b/include/asm-generic/mem_encrypt.h > @@ -22,6 +22,11 @@ static inline bool sme_active(void) > return false; > } > > +static inline u64 sme_dma_mask(void) > +{ > + return 0ULL; > +} > + > /* > * The __sme_set() and __sme_clr() macros are useful for adding or removing > * the encryption mask from a value (e.g. when dealing with pagetable > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index 4f3eece..e2c5fda 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > > /** > * List of possible attributes associated with a DMA mapping. The semantics > @@ -577,6 +578,10 @@ static inline int dma_set_mask(struct device *dev, u64 mask) > > if (!dev->dma_mask || !dma_supported(dev, mask)) > return -EIO; > + > + if (sme_active() && (mask < sme_dma_mask())) > + dev_warn(dev, "SME is active, device will require DMA bounce buffers\n"); Something looks strange here: you're checking sme_active() before calling sme_dma_mask() and yet in it, you're checking !sme_me_mask again. What gives? Why not move the sme_active() check into sme_dma_mask() and thus simplify callers? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.