From: Ard Biesheuvel <ardb+git@google.com>
To: linux-kernel@vger.kernel.org
Cc: x86@kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Brian Gerst <brgerst@gmail.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>
Subject: [PATCH v4 0/6] x86: Robustify pgtable_l5_enabled()
Date: Sat, 17 May 2025 11:16:40 +0200 [thread overview]
Message-ID: <20250517091639.3807875-8-ardb+git@google.com> (raw)
From: Ard Biesheuvel <ardb@kernel.org>
This is a follow-up to the discussion at [0], broken out of that series
so we can progress while the SEV changes are being reviewed and tested.
The current implementation of pgtable_l5_enabled() is problematic
because it has two implementations, and source files need to opt into
the correct one if they contain code that might be called very early.
Other related global pseudo-constants exist that assume different values
based on the number of paging levels, and it is hard to reason about
whether or not all memory mapping and page table code is guaranteed to
observe consistent values of all of these at all times during the boot.
Case in point: currently, KASAN needs to be disabled during alternatives
patching because otherwise, it will reliably produce false positive
reports due to such inconsistencies.
This series drops the early variant entirely, and makes the existing
late variant, which is based on cpu_feature_enabled(), work as expected
in all cases by tweaking the CPU capability code so that it permits
setting the 5-level paging capability from assembler before calling the
C entrypoint of the core kernel.
Runtime constants were considered for PGDIR_SHIFT and PTRS_PER_P4D but
were found unsuitable as they do not support loadable modules, and so
they are replaced with expressions based on pgtable_l5_enabled(). Earlier
patching of alternatives based on CPU capabilities may be feasible, but
whether or not this improves performance is TBD. In any case, doing so
from the startup code is unlikely to be worth the added complexity.
Build and boot tested using QEMU with LA57 emulation.
Changes since v3:
- Drop asm-offsets patch which has been merged already
- Rebase onto tip/x86/core which now carries some related changes by
Kirill
- Avoid adding new instances of '#ifdef CONFIG_X86_5LEVEL' where
possible, as it is going to be removed soon
- Move cap override arrays straight to __ro_after_init
- Drop KVM changes entirely - they were wrong and unnecessary
- Drop the new "la57_hw" capability flag for now - we can always add it
later if there is a need.
Changes since v2:
- Drop first patch which has been merged
- Rename existing "la57" CPU flag to "la57_hw" and use "la57" to
indicate that 5 level paging is being used
- Move memset() out of identify_cpu()
- Make set/clear cap override arrays ro_after_init
- Split off asm-offsets update
[0] https://lore.kernel.org/all/20250504095230.2932860-28-ardb+git@google.com/
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Ard Biesheuvel (6):
x86/cpu: Use a new feature flag for 5 level paging
x86/cpu: Move CPU capability override arrays from BSS to
__ro_after_init
x86/cpu: Allow caps to be set arbitrarily early
x86/boot: Set 5-level paging CPU cap before entering C code
x86/boot: Drop the early variant of pgtable_l5_enabled()
x86/boot: Drop 5-level paging related variables and early updates
arch/x86/boot/compressed/misc.h | 6 ++--
arch/x86/boot/compressed/pgtable_64.c | 12 --------
arch/x86/boot/startup/map_kernel.c | 21 +------------
arch/x86/boot/startup/sme.c | 9 ------
arch/x86/include/asm/cpufeature.h | 12 ++++++--
arch/x86/include/asm/cpufeatures.h | 3 +-
arch/x86/include/asm/page_64.h | 2 +-
arch/x86/include/asm/pgtable_64_types.h | 31 ++++----------------
arch/x86/kernel/alternative.c | 12 --------
arch/x86/kernel/cpu/common.c | 26 ++--------------
arch/x86/kernel/head64.c | 11 -------
arch/x86/kernel/head_64.S | 13 ++++++++
arch/x86/mm/kasan_init_64.c | 3 --
drivers/iommu/amd/init.c | 4 +--
drivers/iommu/intel/svm.c | 4 +--
15 files changed, 41 insertions(+), 128 deletions(-)
base-commit: 4375decf50f74878e73c29c9dcd8af51dd3f7376
--
2.49.0.1101.gccaa498523-goog
next reply other threads:[~2025-05-17 9:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-17 9:16 Ard Biesheuvel [this message]
2025-05-17 9:16 ` [PATCH v4 1/6] x86/cpu: Use a new feature flag for 5 level paging Ard Biesheuvel
2025-05-17 14:28 ` Ard Biesheuvel
2025-05-19 8:35 ` Ingo Molnar
2025-05-19 9:40 ` Borislav Petkov
2025-05-19 9:46 ` Ard Biesheuvel
2025-05-19 12:15 ` Borislav Petkov
2025-05-19 12:24 ` Borislav Petkov
2025-05-19 12:25 ` Ard Biesheuvel
2025-05-19 13:08 ` Ingo Molnar
2025-05-19 13:19 ` Borislav Petkov
2025-05-21 15:23 ` Thomas Gleixner
2025-05-21 18:11 ` Borislav Petkov
2025-05-21 18:56 ` Thomas Gleixner
2025-05-21 19:29 ` Borislav Petkov
2025-05-21 19:41 ` Thomas Gleixner
2025-05-21 19:48 ` Borislav Petkov
2025-05-21 20:07 ` Thomas Gleixner
2025-05-22 7:55 ` Peter Zijlstra
2025-05-22 15:08 ` Sean Christopherson
2025-05-22 19:58 ` Thomas Gleixner
2025-05-22 22:15 ` Sean Christopherson
2025-05-19 12:55 ` [tip: x86/core] x86/cpu: Use a new feature flag for 5-level paging tip-bot2 for Ard Biesheuvel
2025-05-19 13:12 ` Ingo Molnar
2025-05-17 9:16 ` [PATCH v4 2/6] x86/cpu: Move CPU capability override arrays from BSS to __ro_after_init Ard Biesheuvel
2025-05-19 12:01 ` Brian Gerst
2025-05-17 9:16 ` [PATCH v4 3/6] x86/cpu: Allow caps to be set arbitrarily early Ard Biesheuvel
2025-05-17 9:16 ` [PATCH v4 4/6] x86/boot: Set 5-level paging CPU cap before entering C code Ard Biesheuvel
2025-05-17 9:16 ` [PATCH v4 5/6] x86/boot: Drop the early variant of pgtable_l5_enabled() Ard Biesheuvel
2025-05-17 9:16 ` [PATCH v4 6/6] x86/boot: Drop 5-level paging related variables and early updates Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250517091639.3807875-8-ardb+git@google.com \
--to=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=brgerst@gmail.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®