[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXEtW2bAQK4hN-S5C=Po5dk1q14+GJjzEJsjfz9OeOMoCg@mail.gmail.com>
Date: Tue, 6 May 2025 19:52:45 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org, x86@...nel.org,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC PATCH 3/3] x86/boot: Use alternatives based selector for
5-level paging constants
On Tue, 6 May 2025 at 19:44, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, 6 May 2025 at 10:26, Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > In the light of the above, care to comment on the previous approach?
> >
> > https://lore.kernel.org/all/20250504095230.2932860-28-ardb+git@google.com/
>
> I have to say, I find that one much more palatable.
>
> That said, I still think it would be better to get rid of the early
> case *entirely*.
>
> So it would be lovely to have a subsequent patch that just makes the
> "before fixup" case result in an UD2 instead of "read cr4 and check
> the LA57 bit" and then fix the fallout.
>
Pretending the early case does not exist is not going to get us very far.
The very first thing we do when entering the core kernel is populate
the page tables, and this uses all the macros and #define's that are
based on pgtable_l5_enabled(). Alternatives patching occurs *much*
later.
cpu_feature_enabled() is currently built around that ternary logic,
and so we could use it this early as long as we set the bit in
boot_cpu_data. So that might be the best approach.
Powered by blists - more mailing lists