On 09/02/2016 01:14 PM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: >> Adding general kernel support for memory encryption includes: >> - Modify and create some page table macros to include the Secure Memory >> Encryption (SME) memory encryption mask >> - Update kernel boot support to call an SME routine that checks for and >> sets the SME capability (the SME routine will grow later and for now >> is just a stub routine) >> - Update kernel boot support to call an SME routine that encrypts the >> kernel (the SME routine will grow later and for now is just a stub >> routine) >> - Provide an SME initialization routine to update the protection map with >> the memory encryption mask so that it is used by default >> >> Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> >> --- > > ... > >> diff --git a/arch/x86/include/asm/mem_encrypt.h >> b/arch/x86/include/asm/mem_encrypt.h >> index 747fc52..9f3e762 100644 >> --- a/arch/x86/include/asm/mem_encrypt.h >> +++ b/arch/x86/include/asm/mem_encrypt.h >> @@ -15,12 +15,21 @@ >> >> #ifndef __ASSEMBLY__ >> >> +#include <linux/init.h> >> + >> #ifdef CONFIG_AMD_MEM_ENCRYPT >> >> extern unsigned long sme_me_mask; >> >> u8 sme_get_me_loss(void); >> >> +void __init sme_early_init(void); >> + >> +#define __sme_pa(x) (__pa((x)) | sme_me_mask) >> +#define __sme_pa_nodebug(x) (__pa_nodebug((x)) | sme_me_mask) >> + >> +#define __sme_va(x) (__va((x) & ~sme_me_mask)) > > So I'm wondering: why not push the masking off of the SME mask into the > __va() macro instead of defining a specific __sme_va() one? > > I mean, do you even see cases where __va() would need to have to > sme_mask left in the virtual address? > > Because if not, you could mask it out in __va() so that all __va() users > get the "clean" va, without the enc bits.
That's a good point, yes, it could go in __va(). I'll make that change. > > Hmmm. > > Btw, this patch is huuuge. It would be nice if you could split it, if > possible... Ok, I'll look at how to make this a bit more manageable. Thanks, Tom > > Thanks. > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
