* [PATCH 0/2] arch/x86: Enable MPK feature on AMD
@ 2020-05-06 22:02 Babu Moger
2020-05-06 22:02 ` [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 Babu Moger
2020-05-06 22:02 ` [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD Babu Moger
0 siblings, 2 replies; 15+ messages in thread
From: Babu Moger @ 2020-05-06 22:02 UTC (permalink / raw)
To: corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson
Cc: x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto,
peterz, mchehab+samsung, babu.moger, changbin.du, namit, bigeasy,
yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm,
steven.price, rppt, peterx, dan.j.williams, arjunroy, logang,
thellstrom, aarcange, justin.he, robin.murphy, ira.weiny,
keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu,
vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc,
linux-kernel, kvm
AMD's next generation of EPYC processors support the MPK (Memory
Protection Keys) feature.
AMD documentation for MPK feature is available at "AMD64 Architecture
Programmer’s Manual Volume 2: System Programming, Pub. 24593 Rev. 3.34,
Section 5.6.6 Memory Protection Keys (MPK) Bit".
The documentation can be obtained at the link below:
https://bugzilla.kernel.org/show_bug.cgi?id=206537
This series enables the feature on AMD and updates config parameters
to reflect the MPK support on generic x86 platforms.
---
Babu Moger (2):
arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86
KVM: SVM: Add support for MPK feature on AMD
Documentation/core-api/protection-keys.rst | 3 ++-
arch/x86/Kconfig | 6 +++---
arch/x86/include/asm/disabled-features.h | 4 ++--
arch/x86/include/asm/mmu.h | 2 +-
arch/x86/include/asm/mmu_context.h | 4 ++--
arch/x86/include/asm/pgtable.h | 4 ++--
arch/x86/include/asm/pgtable_types.h | 2 +-
arch/x86/include/asm/special_insns.h | 2 +-
arch/x86/include/uapi/asm/mman.h | 2 +-
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kvm/svm/svm.c | 20 ++++++++++++++++++++
arch/x86/kvm/svm/svm.h | 2 ++
arch/x86/mm/Makefile | 2 +-
arch/x86/mm/pkeys.c | 2 +-
scripts/headers_install.sh | 2 +-
tools/arch/x86/include/asm/disabled-features.h | 4 ++--
16 files changed, 43 insertions(+), 20 deletions(-)
--
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-06 22:02 [PATCH 0/2] arch/x86: Enable MPK feature on AMD Babu Moger @ 2020-05-06 22:02 ` Babu Moger 2020-05-06 22:21 ` Dave Hansen 2020-05-06 22:02 ` [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD Babu Moger 1 sibling, 1 reply; 15+ messages in thread From: Babu Moger @ 2020-05-06 22:02 UTC (permalink / raw) To: corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson Cc: x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, babu.moger, changbin.du, namit, bigeasy, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm AMD's next generation of EPYC processors support the MPK (Memory Protection Keys) feature. So, rename X86_INTEL_MEMORY_PROTECTION_KEYS to X86_MEMORY_PROTECTION_KEYS. No functional changes. Signed-off-by: Babu Moger <babu.moger@amd.com> --- Documentation/core-api/protection-keys.rst | 3 ++- arch/x86/Kconfig | 6 +++--- arch/x86/include/asm/disabled-features.h | 4 ++-- arch/x86/include/asm/mmu.h | 2 +- arch/x86/include/asm/mmu_context.h | 4 ++-- arch/x86/include/asm/pgtable.h | 4 ++-- arch/x86/include/asm/pgtable_types.h | 2 +- arch/x86/include/asm/special_insns.h | 2 +- arch/x86/include/uapi/asm/mman.h | 2 +- arch/x86/kernel/cpu/common.c | 2 +- arch/x86/mm/Makefile | 2 +- arch/x86/mm/pkeys.c | 2 +- scripts/headers_install.sh | 2 +- tools/arch/x86/include/asm/disabled-features.h | 4 ++-- 14 files changed, 21 insertions(+), 20 deletions(-) diff --git a/Documentation/core-api/protection-keys.rst b/Documentation/core-api/protection-keys.rst index 49d9833af871..d25e89e53c59 100644 --- a/Documentation/core-api/protection-keys.rst +++ b/Documentation/core-api/protection-keys.rst @@ -6,7 +6,8 @@ Memory Protection Keys Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature which is found on Intel's Skylake "Scalable Processor" Server CPUs. -It will be avalable in future non-server parts. +It will be available in future non-server parts. Also, AMD64 +Architecture Programmer’s Manual defines PKU feature in AMD processors. For anyone wishing to test or use this feature, it is available in Amazon's EC2 C5 instances and is known to work there using an Ubuntu diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 1197b5596d5a..8630b9fa06f5 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1886,11 +1886,11 @@ config X86_UMIP specific cases in protected and virtual-8086 modes. Emulated results are dummy. -config X86_INTEL_MEMORY_PROTECTION_KEYS - prompt "Intel Memory Protection Keys" +config X86_MEMORY_PROTECTION_KEYS + prompt "Memory Protection Keys" def_bool y # Note: only available in 64-bit mode - depends on CPU_SUP_INTEL && X86_64 + depends on X86_64 && (CPU_SUP_INTEL || CPU_SUP_AMD) select ARCH_USES_HIGH_VMA_FLAGS select ARCH_HAS_PKEYS ---help--- diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h index 4ea8584682f9..52dbdfed8043 100644 --- a/arch/x86/include/asm/disabled-features.h +++ b/arch/x86/include/asm/disabled-features.h @@ -36,13 +36,13 @@ # define DISABLE_PCID (1<<(X86_FEATURE_PCID & 31)) #endif /* CONFIG_X86_64 */ -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS # define DISABLE_PKU 0 # define DISABLE_OSPKE 0 #else # define DISABLE_PKU (1<<(X86_FEATURE_PKU & 31)) # define DISABLE_OSPKE (1<<(X86_FEATURE_OSPKE & 31)) -#endif /* CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS */ +#endif /* CONFIG_X86_MEMORY_PROTECTION_KEYS */ #ifdef CONFIG_X86_5LEVEL # define DISABLE_LA57 0 diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h index bdeae9291e5c..351d22152709 100644 --- a/arch/x86/include/asm/mmu.h +++ b/arch/x86/include/asm/mmu.h @@ -42,7 +42,7 @@ typedef struct { const struct vdso_image *vdso_image; /* vdso image in use */ atomic_t perf_rdpmc_allowed; /* nonzero if rdpmc is allowed */ -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS /* * One bit per protection key says whether userspace can * use it or not. protected by mmap_sem. diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h index 4e55370e48e8..33f4a7ccac5e 100644 --- a/arch/x86/include/asm/mmu_context.h +++ b/arch/x86/include/asm/mmu_context.h @@ -118,7 +118,7 @@ static inline int init_new_context(struct task_struct *tsk, mm->context.ctx_id = atomic64_inc_return(&last_mm_ctx_id); atomic64_set(&mm->context.tlb_gen, 0); -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS if (cpu_feature_enabled(X86_FEATURE_OSPKE)) { /* pkey 0 is the default and allocated implicitly */ mm->context.pkey_allocation_map = 0x1; @@ -163,7 +163,7 @@ do { \ static inline void arch_dup_pkeys(struct mm_struct *oldmm, struct mm_struct *mm) { -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS if (!cpu_feature_enabled(X86_FEATURE_OSPKE)) return; diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index 4d02e64af1b3..4265720d62c2 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -1451,7 +1451,7 @@ static inline pmd_t pmd_swp_clear_uffd_wp(pmd_t pmd) #define PKRU_WD_BIT 0x2 #define PKRU_BITS_PER_PKEY 2 -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS extern u32 init_pkru_value; #else #define init_pkru_value 0 @@ -1475,7 +1475,7 @@ static inline bool __pkru_allows_write(u32 pkru, u16 pkey) static inline u16 pte_flags_pkey(unsigned long pte_flags) { -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS /* ifdef to avoid doing 59-bit shift on 32-bit values */ return (pte_flags & _PAGE_PKEY_MASK) >> _PAGE_BIT_PKEY_BIT0; #else diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index b6606fe6cfdf..c61a1ff71d53 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -56,7 +56,7 @@ #define _PAGE_PAT_LARGE (_AT(pteval_t, 1) << _PAGE_BIT_PAT_LARGE) #define _PAGE_SPECIAL (_AT(pteval_t, 1) << _PAGE_BIT_SPECIAL) #define _PAGE_CPA_TEST (_AT(pteval_t, 1) << _PAGE_BIT_CPA_TEST) -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS #define _PAGE_PKEY_BIT0 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT0) #define _PAGE_PKEY_BIT1 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT1) #define _PAGE_PKEY_BIT2 (_AT(pteval_t, 1) << _PAGE_BIT_PKEY_BIT2) diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h index 6d37b8fcfc77..70eaae7e8f04 100644 --- a/arch/x86/include/asm/special_insns.h +++ b/arch/x86/include/asm/special_insns.h @@ -73,7 +73,7 @@ static inline unsigned long native_read_cr4(void) void native_write_cr4(unsigned long val); -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS static inline u32 rdpkru(void) { u32 ecx = 0; diff --git a/arch/x86/include/uapi/asm/mman.h b/arch/x86/include/uapi/asm/mman.h index d4a8d0424bfb..d4da414a9de2 100644 --- a/arch/x86/include/uapi/asm/mman.h +++ b/arch/x86/include/uapi/asm/mman.h @@ -4,7 +4,7 @@ #define MAP_32BIT 0x40 /* only give out 32bit addresses */ -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS /* * Take the 4 protection key bits out of the vma->vm_flags * value and turn them in to the bits that we can put in diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index bed0cb83fe24..e5fb9955214c 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -448,7 +448,7 @@ static __always_inline void setup_pku(struct cpuinfo_x86 *c) set_cpu_cap(c, X86_FEATURE_OSPKE); } -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS static __init int setup_disable_pku(char *arg) { /* diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index 98f7c6fa2eaa..17ebf12ba8ff 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -45,7 +45,7 @@ obj-$(CONFIG_AMD_NUMA) += amdtopology.o obj-$(CONFIG_ACPI_NUMA) += srat.o obj-$(CONFIG_NUMA_EMU) += numa_emulation.o -obj-$(CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS) += pkeys.o +obj-$(CONFIG_X86_MEMORY_PROTECTION_KEYS) += pkeys.o obj-$(CONFIG_RANDOMIZE_MEMORY) += kaslr.o obj-$(CONFIG_PAGE_TABLE_ISOLATION) += pti.o diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c index 8873ed1438a9..a77497e8d58c 100644 --- a/arch/x86/mm/pkeys.c +++ b/arch/x86/mm/pkeys.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-only /* - * Intel Memory Protection Keys management + * Memory Protection Keys management * Copyright (c) 2015, Intel Corporation. */ #include <linux/debugfs.h> /* debugfs_create_u32() */ diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh index a07668a5c36b..6e60e5362d3e 100755 --- a/scripts/headers_install.sh +++ b/scripts/headers_install.sh @@ -86,7 +86,7 @@ arch/sh/include/uapi/asm/sigcontext.h:CONFIG_CPU_SH5 arch/sh/include/uapi/asm/stat.h:CONFIG_CPU_SH5 arch/x86/include/uapi/asm/auxvec.h:CONFIG_IA32_EMULATION arch/x86/include/uapi/asm/auxvec.h:CONFIG_X86_64 -arch/x86/include/uapi/asm/mman.h:CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +arch/x86/include/uapi/asm/mman.h:CONFIG_X86_MEMORY_PROTECTION_KEYS include/uapi/asm-generic/fcntl.h:CONFIG_64BIT include/uapi/linux/atmdev.h:CONFIG_COMPAT include/uapi/linux/elfcore.h:CONFIG_BINFMT_ELF_FDPIC diff --git a/tools/arch/x86/include/asm/disabled-features.h b/tools/arch/x86/include/asm/disabled-features.h index 4ea8584682f9..52dbdfed8043 100644 --- a/tools/arch/x86/include/asm/disabled-features.h +++ b/tools/arch/x86/include/asm/disabled-features.h @@ -36,13 +36,13 @@ # define DISABLE_PCID (1<<(X86_FEATURE_PCID & 31)) #endif /* CONFIG_X86_64 */ -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS # define DISABLE_PKU 0 # define DISABLE_OSPKE 0 #else # define DISABLE_PKU (1<<(X86_FEATURE_PKU & 31)) # define DISABLE_OSPKE (1<<(X86_FEATURE_OSPKE & 31)) -#endif /* CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS */ +#endif /* CONFIG_X86_MEMORY_PROTECTION_KEYS */ #ifdef CONFIG_X86_5LEVEL # define DISABLE_LA57 0 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-06 22:02 ` [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 Babu Moger @ 2020-05-06 22:21 ` Dave Hansen 2020-05-06 22:28 ` Dave Hansen ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Dave Hansen @ 2020-05-06 22:21 UTC (permalink / raw) To: Babu Moger, corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson Cc: x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, bigeasy, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 1197b5596d5a..8630b9fa06f5 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1886,11 +1886,11 @@ config X86_UMIP > specific cases in protected and virtual-8086 modes. Emulated > results are dummy. > > -config X86_INTEL_MEMORY_PROTECTION_KEYS > - prompt "Intel Memory Protection Keys" > +config X86_MEMORY_PROTECTION_KEYS > + prompt "Memory Protection Keys" > def_bool y > # Note: only available in 64-bit mode > - depends on CPU_SUP_INTEL && X86_64 > + depends on X86_64 && (CPU_SUP_INTEL || CPU_SUP_AMD) > select ARCH_USES_HIGH_VMA_FLAGS > select ARCH_HAS_PKEYS > ---help--- It's a bit of a bummer that we're going to prompt everybody doing oldconfig's for this new option. But, I don't know any way for Kconfig to suppress it if the name is changed. Also, I guess the def_bool=y means that menuconfig and olddefconfig will tend to do the right thing. Do we *really* need to change the Kconfig name? The text prompt, sure. End users see that and having Intel in there is massively confusing. If I have to put up with seeing 'amd64' all over my Debian package names, you can put up with a Kconfig name. :P I'm really just wondering what the point of the churn is. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-06 22:21 ` Dave Hansen @ 2020-05-06 22:28 ` Dave Hansen 2020-05-06 22:36 ` Logan Gunthorpe 2020-05-07 7:29 ` Sebastian Andrzej Siewior 2 siblings, 0 replies; 15+ messages in thread From: Dave Hansen @ 2020-05-06 22:28 UTC (permalink / raw) To: Babu Moger, corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson Cc: x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, bigeasy, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 5/6/20 3:21 PM, Dave Hansen wrote: > I'm really just wondering what the point of the churn is. The config option is also in the manpages, fwiw: http://man7.org/linux/man-pages/man7/pkeys.7.html By the way, I am regretting ever sticking "INTEL_" in there. Seems like a good best practice would be to leave those things out in the future if there's any credible opportunity for another vendor to add support. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-06 22:21 ` Dave Hansen 2020-05-06 22:28 ` Dave Hansen @ 2020-05-06 22:36 ` Logan Gunthorpe 2020-05-07 7:29 ` Sebastian Andrzej Siewior 2 siblings, 0 replies; 15+ messages in thread From: Logan Gunthorpe @ 2020-05-06 22:36 UTC (permalink / raw) To: Dave Hansen, Babu Moger, corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson Cc: x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, bigeasy, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 2020-05-06 4:21 p.m., Dave Hansen wrote: >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >> index 1197b5596d5a..8630b9fa06f5 100644 >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -1886,11 +1886,11 @@ config X86_UMIP >> specific cases in protected and virtual-8086 modes. Emulated >> results are dummy. >> >> -config X86_INTEL_MEMORY_PROTECTION_KEYS >> - prompt "Intel Memory Protection Keys" >> +config X86_MEMORY_PROTECTION_KEYS >> + prompt "Memory Protection Keys" >> def_bool y >> # Note: only available in 64-bit mode >> - depends on CPU_SUP_INTEL && X86_64 >> + depends on X86_64 && (CPU_SUP_INTEL || CPU_SUP_AMD) >> select ARCH_USES_HIGH_VMA_FLAGS >> select ARCH_HAS_PKEYS >> ---help--- > > It's a bit of a bummer that we're going to prompt everybody doing > oldconfig's for this new option. But, I don't know any way for Kconfig > to suppress it if the name is changed. Also, I guess the def_bool=y > means that menuconfig and olddefconfig will tend to do the right thing. > > Do we *really* need to change the Kconfig name? The text prompt, sure. > End users see that and having Intel in there is massively confusing. > > If I have to put up with seeing 'amd64' all over my Debian package > names, you can put up with a Kconfig name. :P Lol, isn't that just Intel's penance for Itanium? Logan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-06 22:21 ` Dave Hansen 2020-05-06 22:28 ` Dave Hansen 2020-05-06 22:36 ` Logan Gunthorpe @ 2020-05-07 7:29 ` Sebastian Andrzej Siewior 2020-05-07 14:44 ` Dave Hansen 2 siblings, 1 reply; 15+ messages in thread From: Sebastian Andrzej Siewior @ 2020-05-07 7:29 UTC (permalink / raw) To: Dave Hansen Cc: Babu Moger, corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson, x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 2020-05-06 15:21:29 [-0700], Dave Hansen wrote: > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 1197b5596d5a..8630b9fa06f5 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -1886,11 +1886,11 @@ config X86_UMIP > > specific cases in protected and virtual-8086 modes. Emulated > > results are dummy. > > > > -config X86_INTEL_MEMORY_PROTECTION_KEYS > > - prompt "Intel Memory Protection Keys" > > +config X86_MEMORY_PROTECTION_KEYS > > + prompt "Memory Protection Keys" > > def_bool y > > # Note: only available in 64-bit mode > > - depends on CPU_SUP_INTEL && X86_64 > > + depends on X86_64 && (CPU_SUP_INTEL || CPU_SUP_AMD) > > select ARCH_USES_HIGH_VMA_FLAGS > > select ARCH_HAS_PKEYS > > ---help--- > > It's a bit of a bummer that we're going to prompt everybody doing > oldconfig's for this new option. But, I don't know any way for Kconfig > to suppress it if the name is changed. Also, I guess the def_bool=y > means that menuconfig and olddefconfig will tend to do the right thing. You could add a new option (X86_MEMORY_PROTECTION_KEYS) which is def_bool X86_INTEL_MEMORY_PROTECTION_KEYS and avoiding the prompt line. Soo it is selected based on the old option and the user isn't bother. A few cycles later you could remove intel option and add prompt to other. But still little work for… > Do we *really* need to change the Kconfig name? The text prompt, sure. > End users see that and having Intel in there is massively confusing. > > If I have to put up with seeing 'amd64' all over my Debian package > names, you can put up with a Kconfig name. :P :) Right. On AMD you also use the crc32c-intel (if possible) and I haven't seen people complain about this one. > I'm really just wondering what the point of the churn is. Sebastian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-07 7:29 ` Sebastian Andrzej Siewior @ 2020-05-07 14:44 ` Dave Hansen 2020-05-07 15:16 ` Paolo Bonzini 0 siblings, 1 reply; 15+ messages in thread From: Dave Hansen @ 2020-05-07 14:44 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Babu Moger, corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson, x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 5/7/20 12:29 AM, Sebastian Andrzej Siewior wrote: >>> -config X86_INTEL_MEMORY_PROTECTION_KEYS >>> - prompt "Intel Memory Protection Keys" >>> +config X86_MEMORY_PROTECTION_KEYS >>> + prompt "Memory Protection Keys" >>> def_bool y >>> # Note: only available in 64-bit mode >>> - depends on CPU_SUP_INTEL && X86_64 >>> + depends on X86_64 && (CPU_SUP_INTEL || CPU_SUP_AMD) >>> select ARCH_USES_HIGH_VMA_FLAGS >>> select ARCH_HAS_PKEYS >>> ---help--- >> It's a bit of a bummer that we're going to prompt everybody doing >> oldconfig's for this new option. But, I don't know any way for Kconfig >> to suppress it if the name is changed. Also, I guess the def_bool=y >> means that menuconfig and olddefconfig will tend to do the right thing. > You could add a new option (X86_MEMORY_PROTECTION_KEYS) which is > def_bool X86_INTEL_MEMORY_PROTECTION_KEYS and avoiding the prompt line. > Soo it is selected based on the old option and the user isn't bother. A > few cycles later you could remove intel option and add prompt to other. > But still little work for… That does sound viable, if we decide it's all worth it. So, for now my preference would be to change the prompt, but leave the CONFIG_ naming in place. If we decide that transitioning the config is the right thing (I don't feel super strongly either way), let's use Sebastian's trick to avoid the Kconfig prompts. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-07 14:44 ` Dave Hansen @ 2020-05-07 15:16 ` Paolo Bonzini 2020-05-07 16:06 ` Babu Moger 0 siblings, 1 reply; 15+ messages in thread From: Paolo Bonzini @ 2020-05-07 15:16 UTC (permalink / raw) To: Dave Hansen, Sebastian Andrzej Siewior Cc: Babu Moger, corbet, tglx, mingo, bp, hpa, sean.j.christopherson, x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 07/05/20 16:44, Dave Hansen wrote: >> You could add a new option (X86_MEMORY_PROTECTION_KEYS) which is >> def_bool X86_INTEL_MEMORY_PROTECTION_KEYS and avoiding the prompt line. >> Soo it is selected based on the old option and the user isn't bother. A >> few cycles later you could remove intel option and add prompt to other. >> But still little work for… > That does sound viable, if we decide it's all worth it. > > So, for now my preference would be to change the prompt, but leave the > CONFIG_ naming in place. I agree. What's in a name? An Intel rose by any other name would smell as sweet. Oh wait... :) Paolo > If we decide that transitioning the config is > the right thing (I don't feel super strongly either way), let's use > Sebastian's trick to avoid the Kconfig prompts. > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-07 15:16 ` Paolo Bonzini @ 2020-05-07 16:06 ` Babu Moger 2020-05-07 16:07 ` Paolo Bonzini 0 siblings, 1 reply; 15+ messages in thread From: Babu Moger @ 2020-05-07 16:06 UTC (permalink / raw) To: Paolo Bonzini, Dave Hansen, Sebastian Andrzej Siewior Cc: corbet, tglx, mingo, bp, hpa, sean.j.christopherson, x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 5/7/20 10:16 AM, Paolo Bonzini wrote: > On 07/05/20 16:44, Dave Hansen wrote: >>> You could add a new option (X86_MEMORY_PROTECTION_KEYS) which is >>> def_bool X86_INTEL_MEMORY_PROTECTION_KEYS and avoiding the prompt line. >>> Soo it is selected based on the old option and the user isn't bother. A >>> few cycles later you could remove intel option and add prompt to other. >>> But still little work for… >> That does sound viable, if we decide it's all worth it. >> >> So, for now my preference would be to change the prompt, but leave the >> CONFIG_ naming in place. > > I agree. > > What's in a name? An Intel rose by any other name would smell as sweet. How about X86_MPK? Or I will use already proposed name X86_MEMORY_PROTECTION_KEYS. > Oh wait... :) > > Paolo > >> If we decide that transitioning the config is >> the right thing (I don't feel super strongly either way), let's use >> Sebastian's trick to avoid the Kconfig prompts. >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-07 16:06 ` Babu Moger @ 2020-05-07 16:07 ` Paolo Bonzini 2020-05-07 16:11 ` Babu Moger 0 siblings, 1 reply; 15+ messages in thread From: Paolo Bonzini @ 2020-05-07 16:07 UTC (permalink / raw) To: Babu Moger, Dave Hansen, Sebastian Andrzej Siewior Cc: corbet, tglx, mingo, bp, hpa, sean.j.christopherson, x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 07/05/20 18:06, Babu Moger wrote: >>> So, for now my preference would be to change the prompt, but leave the >>> CONFIG_ naming in place. >> I agree. >> >> What's in a name? An Intel rose by any other name would smell as sweet. > > How about X86_MPK? Or I will use already proposed name > X86_MEMORY_PROTECTION_KEYS. Dave is proposing to keep the CONFIG_ as is and only change the prompt. Paolo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 2020-05-07 16:07 ` Paolo Bonzini @ 2020-05-07 16:11 ` Babu Moger 0 siblings, 0 replies; 15+ messages in thread From: Babu Moger @ 2020-05-07 16:11 UTC (permalink / raw) To: Paolo Bonzini, Dave Hansen, Sebastian Andrzej Siewior Cc: corbet, tglx, mingo, bp, hpa, sean.j.christopherson, x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 5/7/20 11:07 AM, Paolo Bonzini wrote: > On 07/05/20 18:06, Babu Moger wrote: >>>> So, for now my preference would be to change the prompt, but leave the >>>> CONFIG_ naming in place. >>> I agree. >>> >>> What's in a name? An Intel rose by any other name would smell as sweet. >> >> How about X86_MPK? Or I will use already proposed name >> X86_MEMORY_PROTECTION_KEYS. > > Dave is proposing to keep the CONFIG_ as is and only change the prompt. Ok. Got it. thanks ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD 2020-05-06 22:02 [PATCH 0/2] arch/x86: Enable MPK feature on AMD Babu Moger 2020-05-06 22:02 ` [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 Babu Moger @ 2020-05-06 22:02 ` Babu Moger 2020-05-06 22:26 ` Sean Christopherson 2020-05-06 22:36 ` Dave Hansen 1 sibling, 2 replies; 15+ messages in thread From: Babu Moger @ 2020-05-06 22:02 UTC (permalink / raw) To: corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson Cc: x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, babu.moger, changbin.du, namit, bigeasy, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm The Memory Protection Key (MPK) feature provides a way for applications to impose page-based data access protections (read/write, read-only or no access), without requiring modification of page tables and subsequent TLB invalidations when the application changes protection domains. This feature is already available in Intel platforms. Now enable the feature on AMD platforms. The host pkru state needs to be saved/restored during the guest/host switches in SVM. Other changes are already taken care by the pkru common code. AMD documentation for MPK feature is available at "AMD64 Architecture Programmer’s Manual Volume 2: System Programming, Pub. 24593 Rev. 3.34, Section 5.6.6 Memory Protection Keys (MPK) Bit". Documentation can be obtained at the link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Signed-off-by: Babu Moger <babu.moger@amd.com> --- arch/x86/kvm/svm/svm.c | 20 ++++++++++++++++++++ arch/x86/kvm/svm/svm.h | 2 ++ 2 files changed, 22 insertions(+) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 2f379bacbb26..de327f02470f 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -818,6 +818,10 @@ static __init void svm_set_cpu_caps(void) if (boot_cpu_has(X86_FEATURE_LS_CFG_SSBD) || boot_cpu_has(X86_FEATURE_AMD_SSBD)) kvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD); + + /* PKU is not yet implemented for shadow paging. */ + if (npt_enabled && boot_cpu_has(X86_FEATURE_OSPKE)) + kvm_cpu_cap_check_and_set(X86_FEATURE_PKU); } static __init int svm_hardware_setup(void) @@ -1300,6 +1304,8 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu) indirect_branch_prediction_barrier(); } avic_vcpu_load(vcpu, cpu); + + svm->host_pkru = read_pkru(); } static void svm_vcpu_put(struct kvm_vcpu *vcpu) @@ -3318,6 +3324,12 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) clgi(); kvm_load_guest_xsave_state(vcpu); + /* Load the guest pkru state */ + if (static_cpu_has(X86_FEATURE_PKU) && + kvm_read_cr4_bits(vcpu, X86_CR4_PKE) && + vcpu->arch.pkru != svm->host_pkru) + __write_pkru(vcpu->arch.pkru); + if (lapic_in_kernel(vcpu) && vcpu->arch.apic->lapic_timer.timer_advance_ns) kvm_wait_lapic_expire(vcpu); @@ -3371,6 +3383,14 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) if (unlikely(svm->vmcb->control.exit_code == SVM_EXIT_NMI)) kvm_before_interrupt(&svm->vcpu); + /* Save the guest pkru state and restore the host pkru state back */ + if (static_cpu_has(X86_FEATURE_PKU) && + kvm_read_cr4_bits(vcpu, X86_CR4_PKE)) { + vcpu->arch.pkru = rdpkru(); + if (vcpu->arch.pkru != svm->host_pkru) + __write_pkru(svm->host_pkru); + } + kvm_load_host_xsave_state(vcpu); stgi(); diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index df3474f4fb02..5d20a28c1b0e 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -158,6 +158,8 @@ struct vcpu_svm { u64 *avic_physical_id_cache; bool avic_is_running; + u32 host_pkru; + /* * Per-vcpu list of struct amd_svm_iommu_ir: * This is used mainly to store interrupt remapping information used ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD 2020-05-06 22:02 ` [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD Babu Moger @ 2020-05-06 22:26 ` Sean Christopherson 2020-05-07 8:07 ` Paolo Bonzini 2020-05-06 22:36 ` Dave Hansen 1 sibling, 1 reply; 15+ messages in thread From: Sean Christopherson @ 2020-05-06 22:26 UTC (permalink / raw) To: Babu Moger Cc: corbet, tglx, mingo, bp, hpa, pbonzini, x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, bigeasy, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On Wed, May 06, 2020 at 05:02:21PM -0500, Babu Moger wrote: > static __init int svm_hardware_setup(void) > @@ -1300,6 +1304,8 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu) > indirect_branch_prediction_barrier(); > } > avic_vcpu_load(vcpu, cpu); > + > + svm->host_pkru = read_pkru(); Move vcpu_vmx's host_prku to kvm_vcpu_arch instead of duplicating it to SVM. And I'm 99% certain "vcpu->arch.host_pkru = read_pkru()" can be moved to kvm_arch_vcpu_load(). The only direct calls to vmx_vcpu_load() are to get the right VMCS loaded. Actually, those calls shouldn't be using vmx_vcpu_load(), especially since that'll trigger IBPB. I'll send a patch for that. > } > > static void svm_vcpu_put(struct kvm_vcpu *vcpu) > @@ -3318,6 +3324,12 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) > clgi(); > kvm_load_guest_xsave_state(vcpu); > > + /* Load the guest pkru state */ > + if (static_cpu_has(X86_FEATURE_PKU) && > + kvm_read_cr4_bits(vcpu, X86_CR4_PKE) && > + vcpu->arch.pkru != svm->host_pkru) > + __write_pkru(vcpu->arch.pkru); This and the restoration should be moved to common x86 helpers, at a glance they look identical. In short, pretty much all of this belongs in common x86. > + > if (lapic_in_kernel(vcpu) && > vcpu->arch.apic->lapic_timer.timer_advance_ns) > kvm_wait_lapic_expire(vcpu); > @@ -3371,6 +3383,14 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) > if (unlikely(svm->vmcb->control.exit_code == SVM_EXIT_NMI)) > kvm_before_interrupt(&svm->vcpu); > > + /* Save the guest pkru state and restore the host pkru state back */ > + if (static_cpu_has(X86_FEATURE_PKU) && > + kvm_read_cr4_bits(vcpu, X86_CR4_PKE)) { > + vcpu->arch.pkru = rdpkru(); > + if (vcpu->arch.pkru != svm->host_pkru) > + __write_pkru(svm->host_pkru); > + } > + > kvm_load_host_xsave_state(vcpu); > stgi(); > > diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h > index df3474f4fb02..5d20a28c1b0e 100644 > --- a/arch/x86/kvm/svm/svm.h > +++ b/arch/x86/kvm/svm/svm.h > @@ -158,6 +158,8 @@ struct vcpu_svm { > u64 *avic_physical_id_cache; > bool avic_is_running; > > + u32 host_pkru; > + > /* > * Per-vcpu list of struct amd_svm_iommu_ir: > * This is used mainly to store interrupt remapping information used > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD 2020-05-06 22:26 ` Sean Christopherson @ 2020-05-07 8:07 ` Paolo Bonzini 0 siblings, 0 replies; 15+ messages in thread From: Paolo Bonzini @ 2020-05-07 8:07 UTC (permalink / raw) To: Sean Christopherson, Babu Moger Cc: corbet, tglx, mingo, bp, hpa, x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, bigeasy, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 07/05/20 00:26, Sean Christopherson wrote: >> + /* Load the guest pkru state */ >> + if (static_cpu_has(X86_FEATURE_PKU) && >> + kvm_read_cr4_bits(vcpu, X86_CR4_PKE) && >> + vcpu->arch.pkru != svm->host_pkru) >> + __write_pkru(vcpu->arch.pkru); > This and the restoration should be moved to common x86 helpers, at a glance > they look identical. > > In short, pretty much all of this belongs in common x86. > We could stick this in kvm_load_guest_xsave_state kvm_load_host_xsave_state. It's not a perfect match, after all the code itself proves that PKRU can be loaded without XSAVE; but it's close enough and it's exactly in the right point of vmx_vcpu_run and svm_vcpu_run. Paolo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD 2020-05-06 22:02 ` [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD Babu Moger 2020-05-06 22:26 ` Sean Christopherson @ 2020-05-06 22:36 ` Dave Hansen 1 sibling, 0 replies; 15+ messages in thread From: Dave Hansen @ 2020-05-06 22:36 UTC (permalink / raw) To: Babu Moger, corbet, tglx, mingo, bp, hpa, pbonzini, sean.j.christopherson Cc: x86, vkuznets, wanpengli, jmattson, joro, dave.hansen, luto, peterz, mchehab+samsung, changbin.du, namit, bigeasy, yang.shi, asteinhauser, anshuman.khandual, jan.kiszka, akpm, steven.price, rppt, peterx, dan.j.williams, arjunroy, logang, thellstrom, aarcange, justin.he, robin.murphy, ira.weiny, keescook, jgross, andrew.cooper3, pawan.kumar.gupta, fenghua.yu, vineela.tummalapalli, yamada.masahiro, sam, acme, linux-doc, linux-kernel, kvm On 5/6/20 3:02 PM, Babu Moger wrote: > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -818,6 +818,10 @@ static __init void svm_set_cpu_caps(void) > if (boot_cpu_has(X86_FEATURE_LS_CFG_SSBD) || > boot_cpu_has(X86_FEATURE_AMD_SSBD)) > kvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD); > + > + /* PKU is not yet implemented for shadow paging. */ > + if (npt_enabled && boot_cpu_has(X86_FEATURE_OSPKE)) > + kvm_cpu_cap_check_and_set(X86_FEATURE_PKU); > } Reviewed-by: Dave Hansen <dave.hansen@intel.com> But, I'll also say that we probably shouldn't have put the other code into arch/x86/kvm/vmx/vmx.c in the first place. It would be much nicer if this refactored the current code into a common spot rather than copying. But, I do understand the impulse to do it the way it was done. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-05-07 16:11 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-06 22:02 [PATCH 0/2] arch/x86: Enable MPK feature on AMD Babu Moger 2020-05-06 22:02 ` [PATCH 1/2] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 Babu Moger 2020-05-06 22:21 ` Dave Hansen 2020-05-06 22:28 ` Dave Hansen 2020-05-06 22:36 ` Logan Gunthorpe 2020-05-07 7:29 ` Sebastian Andrzej Siewior 2020-05-07 14:44 ` Dave Hansen 2020-05-07 15:16 ` Paolo Bonzini 2020-05-07 16:06 ` Babu Moger 2020-05-07 16:07 ` Paolo Bonzini 2020-05-07 16:11 ` Babu Moger 2020-05-06 22:02 ` [PATCH 2/2] KVM: SVM: Add support for MPK feature on AMD Babu Moger 2020-05-06 22:26 ` Sean Christopherson 2020-05-07 8:07 ` Paolo Bonzini 2020-05-06 22:36 ` Dave Hansen
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).