From: Ard Biesheuvel <ardb@kernel.org>
Currently, the LA57 CPU feature flag is taken to mean two different
things at once:
- whether the CPU implements the LA57 extension, and is therefore
capable of supporting 5 level paging;
- whether 5 level paging is currently in use.
This means the LA57 capability of the hardware is hidden when a LA57
capable CPU is forced to run with 4 levels of paging. It also means the
the ordinary CPU capability detection code will happily set the LA57
capability and it needs to be cleared explicitly afterwards to avoid
inconsistencies.
Separate the two so that the CPU hardware capability can be identified
unambigously in all cases.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/page_64.h | 2 +-
arch/x86/include/asm/pgtable_64_types.h | 2 +-
arch/x86/kernel/cpu/common.c | 16 ++--------------
arch/x86/kvm/x86.h | 4 ++--
drivers/iommu/amd/init.c | 4 ++--
drivers/iommu/intel/svm.c | 4 ++--
tools/testing/selftests/kvm/x86/set_sregs_test.c | 2 +-
8 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 6c2c152d8a67..13162cac8957 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -481,6 +481,7 @@
#define X86_FEATURE_AMD_HETEROGENEOUS_CORES (21*32 + 6) /* Heterogeneous Core Topology */
#define X86_FEATURE_AMD_WORKLOAD_CLASS (21*32 + 7) /* Workload Classification */
#define X86_FEATURE_PREFER_YMM (21*32 + 8) /* Avoid ZMM registers due to downclocking */
+#define X86_FEATURE_5LEVEL_PAGING (21*32 + 9) /* Whether 5 levels of page tables are in use */
/*
* BUG word(s)
diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h
index d3aab6f4e59a..acfa61ad0725 100644
--- a/arch/x86/include/asm/page_64.h
+++ b/arch/x86/include/asm/page_64.h
@@ -86,7 +86,7 @@ static __always_inline unsigned long task_size_max(void)
unsigned long ret;
alternative_io("movq %[small],%0","movq %[large],%0",
- X86_FEATURE_LA57,
+ X86_FEATURE_5LEVEL_PAGING,
"=r" (ret),
[small] "i" ((1ul << 47)-PAGE_SIZE),
[large] "i" ((1ul << 56)-PAGE_SIZE));
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index 5bb782d856f2..88dc719b7d37 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -34,7 +34,7 @@ static inline bool pgtable_l5_enabled(void)
return __pgtable_l5_enabled;
}
#else
-#define pgtable_l5_enabled() cpu_feature_enabled(X86_FEATURE_LA57)
+#define pgtable_l5_enabled() cpu_feature_enabled(X86_FEATURE_5LEVEL_PAGING)
#endif /* USE_EARLY_PGTABLE_L5 */
#else
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f0f85482a73b..bbec5c4cd8ed 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1675,20 +1675,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
setup_clear_cpu_cap(X86_FEATURE_PCID);
#endif
- /*
- * Later in the boot process pgtable_l5_enabled() relies on
- * cpu_feature_enabled(X86_FEATURE_LA57). If 5-level paging is not
- * enabled by this point we need to clear the feature bit to avoid
- * false-positives at the later stage.
- *
- * pgtable_l5_enabled() can be false here for several reasons:
- * - 5-level paging is disabled compile-time;
- * - it's 32-bit kernel;
- * - machine doesn't support 5-level paging;
- * - user specified 'no5lvl' in kernel command line.
- */
- if (!pgtable_l5_enabled())
- setup_clear_cpu_cap(X86_FEATURE_LA57);
+ if (IS_ENABLED(CONFIG_X86_5LEVEL) && (native_read_cr4() & X86_CR4_LA57))
+ setup_force_cpu_cap(X86_FEATURE_5LEVEL_PAGING);
detect_nopl();
}
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index 9dc32a409076..d2c093f17ae5 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -243,7 +243,7 @@ static inline u8 vcpu_virt_addr_bits(struct kvm_vcpu *vcpu)
static inline u8 max_host_virt_addr_bits(void)
{
- return kvm_cpu_cap_has(X86_FEATURE_LA57) ? 57 : 48;
+ return kvm_cpu_cap_has(X86_FEATURE_5LEVEL_PAGING) ? 57 : 48;
}
/*
@@ -603,7 +603,7 @@ static inline bool __kvm_is_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
__reserved_bits |= X86_CR4_FSGSBASE; \
if (!__cpu_has(__c, X86_FEATURE_PKU)) \
__reserved_bits |= X86_CR4_PKE; \
- if (!__cpu_has(__c, X86_FEATURE_LA57)) \
+ if (!__cpu_has(__c, X86_FEATURE_5LEVEL_PAGING)) \
__reserved_bits |= X86_CR4_LA57; \
if (!__cpu_has(__c, X86_FEATURE_UMIP)) \
__reserved_bits |= X86_CR4_UMIP; \
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index dd9e26b7b718..1d129969c4fd 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -3084,7 +3084,7 @@ static int __init early_amd_iommu_init(void)
goto out;
/* 5 level guest page table */
- if (cpu_feature_enabled(X86_FEATURE_LA57) &&
+ if (cpu_feature_enabled(X86_FEATURE_5LEVEL_PAGING) &&
FIELD_GET(FEATURE_GATS, amd_iommu_efr) == GUEST_PGTABLE_5_LEVEL)
amd_iommu_gpt_level = PAGE_MODE_5_LEVEL;
@@ -3683,7 +3683,7 @@ __setup("ivrs_acpihid", parse_ivrs_acpihid);
bool amd_iommu_pasid_supported(void)
{
/* CPU page table size should match IOMMU guest page table size */
- if (cpu_feature_enabled(X86_FEATURE_LA57) &&
+ if (cpu_feature_enabled(X86_FEATURE_5LEVEL_PAGING) &&
amd_iommu_gpt_level != PAGE_MODE_5_LEVEL)
return false;
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index ba93123cb4eb..1f615e6d06ec 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -37,7 +37,7 @@ void intel_svm_check(struct intel_iommu *iommu)
return;
}
- if (cpu_feature_enabled(X86_FEATURE_LA57) &&
+ if (cpu_feature_enabled(X86_FEATURE_5LEVEL_PAGING) &&
!cap_fl5lp_support(iommu->cap)) {
pr_err("%s SVM disabled, incompatible paging mode\n",
iommu->name);
@@ -165,7 +165,7 @@ static int intel_svm_set_dev_pasid(struct iommu_domain *domain,
return PTR_ERR(dev_pasid);
/* Setup the pasid table: */
- sflags = cpu_feature_enabled(X86_FEATURE_LA57) ? PASID_FLAG_FL5LP : 0;
+ sflags = cpu_feature_enabled(X86_FEATURE_5LEVEL_PAGING) ? PASID_FLAG_FL5LP : 0;
ret = __domain_setup_first_level(iommu, dev, pasid,
FLPT_DEFAULT_DID, mm->pgd,
sflags, old);
diff --git a/tools/testing/selftests/kvm/x86/set_sregs_test.c b/tools/testing/selftests/kvm/x86/set_sregs_test.c
index f4095a3d1278..de78665fa675 100644
--- a/tools/testing/selftests/kvm/x86/set_sregs_test.c
+++ b/tools/testing/selftests/kvm/x86/set_sregs_test.c
@@ -52,7 +52,7 @@ static uint64_t calc_supported_cr4_feature_bits(void)
if (kvm_cpu_has(X86_FEATURE_UMIP))
cr4 |= X86_CR4_UMIP;
- if (kvm_cpu_has(X86_FEATURE_LA57))
+ if (kvm_cpu_has(X86_FEATURE_5LEVEL_PAGING))
cr4 |= X86_CR4_LA57;
if (kvm_cpu_has(X86_FEATURE_VMX))
cr4 |= X86_CR4_VMXE;
--
2.49.0.1045.g170613ef41-googOn Tue, May 13, 2025 at 01:12:00PM +0200, Ard Biesheuvel wrote: > From: Ard Biesheuvel <ardb@kernel.org> > > Currently, the LA57 CPU feature flag is taken to mean two different > things at once: > - whether the CPU implements the LA57 extension, and is therefore > capable of supporting 5 level paging; > - whether 5 level paging is currently in use. > > This means the LA57 capability of the hardware is hidden when a LA57 > capable CPU is forced to run with 4 levels of paging. It also means the > the ordinary CPU capability detection code will happily set the LA57 > capability and it needs to be cleared explicitly afterwards to avoid > inconsistencies. > > Separate the two so that the CPU hardware capability can be identified > unambigously in all cases. Unfortunately, there's already userspace that use la57 flag in /proc/cpuinfo as indication that 5-level paging is active. :/ See va_high_addr_switch.sh in kernel selftests for instance. -- Kiryl Shutsemau / Kirill A. Shutemov
* Kirill A. Shutemov <kirill@shutemov.name> wrote: > On Tue, May 13, 2025 at 01:12:00PM +0200, Ard Biesheuvel wrote: > > From: Ard Biesheuvel <ardb@kernel.org> > > > > Currently, the LA57 CPU feature flag is taken to mean two different > > things at once: > > - whether the CPU implements the LA57 extension, and is therefore > > capable of supporting 5 level paging; > > - whether 5 level paging is currently in use. > > > > This means the LA57 capability of the hardware is hidden when a LA57 > > capable CPU is forced to run with 4 levels of paging. It also means the > > the ordinary CPU capability detection code will happily set the LA57 > > capability and it needs to be cleared explicitly afterwards to avoid > > inconsistencies. > > > > Separate the two so that the CPU hardware capability can be identified > > unambigously in all cases. > > Unfortunately, there's already userspace that use la57 flag in > /proc/cpuinfo as indication that 5-level paging is active. :/ > > See va_high_addr_switch.sh in kernel selftests for instance. Kernel selftests do not really count if that's the only userspace that does this - but they indeed increase the likelihood that some external userspace uses /proc/cpuinfo in that fashion. Does such external user-space code exist? Thanks, Ingo
On Wed, May 14, 2025 at 10:04:05AM +0200, Ingo Molnar wrote: > > * Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > On Tue, May 13, 2025 at 01:12:00PM +0200, Ard Biesheuvel wrote: > > > From: Ard Biesheuvel <ardb@kernel.org> > > > > > > Currently, the LA57 CPU feature flag is taken to mean two different > > > things at once: > > > - whether the CPU implements the LA57 extension, and is therefore > > > capable of supporting 5 level paging; > > > - whether 5 level paging is currently in use. > > > > > > This means the LA57 capability of the hardware is hidden when a LA57 > > > capable CPU is forced to run with 4 levels of paging. It also means the > > > the ordinary CPU capability detection code will happily set the LA57 > > > capability and it needs to be cleared explicitly afterwards to avoid > > > inconsistencies. > > > > > > Separate the two so that the CPU hardware capability can be identified > > > unambigously in all cases. > > > > Unfortunately, there's already userspace that use la57 flag in > > /proc/cpuinfo as indication that 5-level paging is active. :/ > > > > See va_high_addr_switch.sh in kernel selftests for instance. > > Kernel selftests do not really count if that's the only userspace that > does this - but they indeed increase the likelihood that some external > userspace uses /proc/cpuinfo in that fashion. Does such external > user-space code exist? I am not aware of any production code that does this. But changing is risky. Maybe leave "la57" flag in cpuinfo for 5-level paging enabled case and add "la57_enumerated" or "la57_capable" to indicate that the hardware supports 5-level paging? -- Kiryl Shutsemau / Kirill A. Shutemov
* Kirill A. Shutemov <kirill@shutemov.name> wrote: > On Wed, May 14, 2025 at 10:04:05AM +0200, Ingo Molnar wrote: > > > > * Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > On Tue, May 13, 2025 at 01:12:00PM +0200, Ard Biesheuvel wrote: > > > > From: Ard Biesheuvel <ardb@kernel.org> > > > > > > > > Currently, the LA57 CPU feature flag is taken to mean two different > > > > things at once: > > > > - whether the CPU implements the LA57 extension, and is therefore > > > > capable of supporting 5 level paging; > > > > - whether 5 level paging is currently in use. > > > > > > > > This means the LA57 capability of the hardware is hidden when a LA57 > > > > capable CPU is forced to run with 4 levels of paging. It also means the > > > > the ordinary CPU capability detection code will happily set the LA57 > > > > capability and it needs to be cleared explicitly afterwards to avoid > > > > inconsistencies. > > > > > > > > Separate the two so that the CPU hardware capability can be identified > > > > unambigously in all cases. > > > > > > Unfortunately, there's already userspace that use la57 flag in > > > /proc/cpuinfo as indication that 5-level paging is active. :/ > > > > > > See va_high_addr_switch.sh in kernel selftests for instance. > > > > Kernel selftests do not really count if that's the only userspace that > > does this - but they indeed increase the likelihood that some external > > userspace uses /proc/cpuinfo in that fashion. Does such external > > user-space code exist? > > I am not aware of any production code that does this. But changing is > risky. Would production code ever really care about this? > Maybe leave "la57" flag in cpuinfo for 5-level paging enabled case and add > "la57_enumerated" or "la57_capable" to indicate that the hardware supports > 5-level paging? Yeah, see my other mail, I think renaming X86_FEATURE_LA57 to X86_FEATURE_LA57_HW and exposing it as an additional 'la57_hw' flag in /proc/cpuinfo would be the way to go, if this is a compatibility concern. Thanks, Ingo
On Wed, 14 May 2025 at 09:04, Ingo Molnar <mingo@kernel.org> wrote: > > > * Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > On Tue, May 13, 2025 at 01:12:00PM +0200, Ard Biesheuvel wrote: > > > From: Ard Biesheuvel <ardb@kernel.org> > > > > > > Currently, the LA57 CPU feature flag is taken to mean two different > > > things at once: > > > - whether the CPU implements the LA57 extension, and is therefore > > > capable of supporting 5 level paging; > > > - whether 5 level paging is currently in use. > > > > > > This means the LA57 capability of the hardware is hidden when a LA57 > > > capable CPU is forced to run with 4 levels of paging. It also means the > > > the ordinary CPU capability detection code will happily set the LA57 > > > capability and it needs to be cleared explicitly afterwards to avoid > > > inconsistencies. > > > > > > Separate the two so that the CPU hardware capability can be identified > > > unambigously in all cases. > > > > Unfortunately, there's already userspace that use la57 flag in > > /proc/cpuinfo as indication that 5-level paging is active. :/ > > > > See va_high_addr_switch.sh in kernel selftests for instance. > > Kernel selftests do not really count if that's the only userspace that > does this - but they indeed increase the likelihood that some external > userspace uses /proc/cpuinfo in that fashion. Does such external > user-space code exist? > Bah, that seems likely if this is the only way user space is able to infer that the kernel is using 5-level paging.
* Ard Biesheuvel <ardb@kernel.org> wrote: > On Wed, 14 May 2025 at 09:04, Ingo Molnar <mingo@kernel.org> wrote: > > > > > > * Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > On Tue, May 13, 2025 at 01:12:00PM +0200, Ard Biesheuvel wrote: > > > > From: Ard Biesheuvel <ardb@kernel.org> > > > > > > > > Currently, the LA57 CPU feature flag is taken to mean two different > > > > things at once: > > > > - whether the CPU implements the LA57 extension, and is therefore > > > > capable of supporting 5 level paging; > > > > - whether 5 level paging is currently in use. > > > > > > > > This means the LA57 capability of the hardware is hidden when a LA57 > > > > capable CPU is forced to run with 4 levels of paging. It also means the > > > > the ordinary CPU capability detection code will happily set the LA57 > > > > capability and it needs to be cleared explicitly afterwards to avoid > > > > inconsistencies. > > > > > > > > Separate the two so that the CPU hardware capability can be identified > > > > unambigously in all cases. > > > > > > Unfortunately, there's already userspace that use la57 flag in > > > /proc/cpuinfo as indication that 5-level paging is active. :/ > > > > > > See va_high_addr_switch.sh in kernel selftests for instance. > > > > Kernel selftests do not really count if that's the only userspace that > > does this - but they indeed increase the likelihood that some external > > userspace uses /proc/cpuinfo in that fashion. Does such external > > user-space code exist? > > > > Bah, that seems likely if this is the only way user space is able to > infer that the kernel is using 5-level paging. The price of past mistakes. :-/ So, the pragmatic, forward compatible solution would be to: - Keep the 'la57' user-visible flag in /proc/cpuinfo, but map it to the X86_FEATURE_5LEVEL_PAGING flag internally. - Rename X86_FEATURE_LA57 to X86_FEATURE_LA57_HW, and expose it as la57_hw. This way, any LA57-supporting CPUs would always have la57_cpu set, while 'la57' is only set when it's enabled in the kernel. An additional minor bonus would be that by renaming it to X86_FEATURE_LA57_HW, the change in behavior also becomes a bit more obvious at first glance to kernel developers. Thanks, Ingo
* Ingo Molnar <mingo@kernel.org> wrote: > > * Ard Biesheuvel <ardb@kernel.org> wrote: > > > On Wed, 14 May 2025 at 09:04, Ingo Molnar <mingo@kernel.org> wrote: > > > > > > > > > * Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > > > On Tue, May 13, 2025 at 01:12:00PM +0200, Ard Biesheuvel wrote: > > > > > From: Ard Biesheuvel <ardb@kernel.org> > > > > > > > > > > Currently, the LA57 CPU feature flag is taken to mean two different > > > > > things at once: > > > > > - whether the CPU implements the LA57 extension, and is therefore > > > > > capable of supporting 5 level paging; > > > > > - whether 5 level paging is currently in use. > > > > > > > > > > This means the LA57 capability of the hardware is hidden when a LA57 > > > > > capable CPU is forced to run with 4 levels of paging. It also means the > > > > > the ordinary CPU capability detection code will happily set the LA57 > > > > > capability and it needs to be cleared explicitly afterwards to avoid > > > > > inconsistencies. > > > > > > > > > > Separate the two so that the CPU hardware capability can be identified > > > > > unambigously in all cases. > > > > > > > > Unfortunately, there's already userspace that use la57 flag in > > > > /proc/cpuinfo as indication that 5-level paging is active. :/ > > > > > > > > See va_high_addr_switch.sh in kernel selftests for instance. > > > > > > Kernel selftests do not really count if that's the only userspace that > > > does this - but they indeed increase the likelihood that some external > > > userspace uses /proc/cpuinfo in that fashion. Does such external > > > user-space code exist? > > > > > > > Bah, that seems likely if this is the only way user space is able to > > infer that the kernel is using 5-level paging. > > The price of past mistakes. :-/ > > So, the pragmatic, forward compatible solution would be to: > > - Keep the 'la57' user-visible flag in /proc/cpuinfo, but map it to > the X86_FEATURE_5LEVEL_PAGING flag internally. > > - Rename X86_FEATURE_LA57 to X86_FEATURE_LA57_HW, and expose it > as la57_hw. > > This way, any LA57-supporting CPUs would always have la57_cpu set, > while 'la57' is only set when it's enabled in the kernel. s/would always have la57_hw set > > An additional minor bonus would be that by renaming it to > X86_FEATURE_LA57_HW, the change in behavior also becomes a bit more > obvious at first glance to kernel developers. > > Thanks, > > Ingo
On Wed, May 14, 2025 at 09:14:56AM +0100, Ard Biesheuvel wrote: > On Wed, 14 May 2025 at 09:04, Ingo Molnar <mingo@kernel.org> wrote: > > > > > > * Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > On Tue, May 13, 2025 at 01:12:00PM +0200, Ard Biesheuvel wrote: > > > > From: Ard Biesheuvel <ardb@kernel.org> > > > > > > > > Currently, the LA57 CPU feature flag is taken to mean two different > > > > things at once: > > > > - whether the CPU implements the LA57 extension, and is therefore > > > > capable of supporting 5 level paging; > > > > - whether 5 level paging is currently in use. > > > > > > > > This means the LA57 capability of the hardware is hidden when a LA57 > > > > capable CPU is forced to run with 4 levels of paging. It also means the > > > > the ordinary CPU capability detection code will happily set the LA57 > > > > capability and it needs to be cleared explicitly afterwards to avoid > > > > inconsistencies. > > > > > > > > Separate the two so that the CPU hardware capability can be identified > > > > unambigously in all cases. > > > > > > Unfortunately, there's already userspace that use la57 flag in > > > /proc/cpuinfo as indication that 5-level paging is active. :/ > > > > > > See va_high_addr_switch.sh in kernel selftests for instance. > > > > Kernel selftests do not really count if that's the only userspace that > > does this - but they indeed increase the likelihood that some external > > userspace uses /proc/cpuinfo in that fashion. Does such external > > user-space code exist? > > > > Bah, that seems likely if this is the only way user space is able to > infer that the kernel is using 5-level paging. Well, you can also try to map high addresses. lam.c selftest does this. -- Kiryl Shutsemau / Kirill A. Shutemov
On Tue, 13 May 2025 at 04:12, Ard Biesheuvel <ardb+git@google.com> wrote:
>
> Separate the two so that the CPU hardware capability can be identified
> unambiguously in all cases.
Yeah, I like this version of the patch series, it seems much clearer.
Linus
© 2016 - 2026 Red Hat, Inc.