On 06/12/2018 07:39 AM, Kirill A. Shutemov wrote: > Add new config option to enabled/disable Multi-Key Total Memory > Encryption support. > > MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID > direct mappings for memory hotplug. Isn't it really *the* direct mapping primarily? We make all of them larger, but the direct mapping is impacted too. This makes it sound like it applies only to the MKTME mappings. > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 4fa2cf807321..d013495bb4ae 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1513,6 +1513,23 @@ config ARCH_USE_MEMREMAP_PROT > def_bool y > depends on AMD_MEM_ENCRYPT > > +config X86_INTEL_MKTME > + bool "Intel Multi-Key Total Memory Encryption" > + select DYNAMIC_PHYSICAL_MASK > + select PAGE_EXTENSION > + depends on X86_64 && CPU_SUP_INTEL > + ---help--- > + Say yes to enable support for Multi-Key Total Memory Encryption. > + This requires Intel processor that has support of the feature. "requires an Intel processor"... > + Multikey Total Memory Encryption (MKTME) is a technology that allows > + transparent memory encryption in upcoming Intel platforms. "in an upcoming" > + MKTME is built on top of TME. TME allows encryption of the entirety > + of system memory using a single key. MKTME allows to have multiple "allows having multiple"... > + encryption domains, each having own key -- different memory pages can > + be encrypted with different keys. > + > # Common NUMA Features > config NUMA > bool "Numa Memory Allocation and Scheduler Support" > @@ -2189,7 +2206,7 @@ config RANDOMIZE_MEMORY > > config MEMORY_PHYSICAL_PADDING > hex "Physical memory mapping padding" if EXPERT > - depends on RANDOMIZE_MEMORY > + depends on RANDOMIZE_MEMORY || X86_INTEL_MKTME > default "0xa" if MEMORY_HOTPLUG > default "0x0" > range 0x1 0x40 if MEMORY_HOTPLUG >
