[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <293e8808-e239-412e-90bc-d13f671c6061@suse.com>
Date: Wed, 1 Oct 2025 13:16:38 +0200
From: Jürgen Groß <jgross@...e.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, llvm@...ts.linux.dev,
xin@...or.com, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>
Subject: Re: [PATCH v2 09/12] x86/msr: Use the alternatives mechanism for
WRMSR
On 01.10.25 12:50, Peter Zijlstra wrote:
> On Wed, Oct 01, 2025 at 10:49:31AM +0200, Juergen Gross wrote:
>
>> Thinking more about that I believe there are additional problems:
>>
>> Having overlapping alternatives not starting at the same address will result
>> in problems with length padding of the outer alternative in case the inner
>> one starting later is extending past the end of the outer one. This might be
>> possible to handle, but it will be tedious.
>
> Yes, this must not happen.
>
>> Using your idea with pv_ops could result in the inner alternative not being
>> at the start of the outer alternative AND being not the initial code. This
>> would result in patching in the .altinstructions area instead of the normal
>> .text site, resulting in possible loss of a patching action if the patched
>> area would have been used as a replacement before.
>
> Not quite, the nested alternative was in the orig_insn part. So it would
> result in patching the orig text twice, once from the inner (which comes
> first in the patch list) and then once again from the outer (which comes
> later).
Yes, but that was the native case only.
With pv_ops this would mean the original instruction would be the
paravirt-call, resulting in your construct becoming an inner nesting level.
>
>> So in my opinion allowing alternatives to nest without all inner levels
>> starting at the same location as the outermost level would be a receipt for
>> failure.
>
> Certainly tricky, no argument there.
>
>> I think I'll write another patch to BUG() in case such a situation is being
>> detected.
>
> Fair enough; we should not currently have any such cases. And going by
> my attempt to make it work, its going to be really tricky in any case.
>
> But please put on a comment on why, which explains the constraints.
Agreed.
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists