On Mon, Jun 29, 2026, at 08:04, Juergen Gross wrote:
> For accessing the MSR registers on the local CPU, there are 2 types of
> interfaces: the "modern" 64-bit ones (rdmsrq() etc.) and the 32-bit
> ones (rdmsr() etc.) which are using the upper and lower 32-bit halves
> of the 64-bit wide MSR register values.
>
> The 32-bit interfaces are not optimal for 3 reasons:
>
> - They are based on primitives using 64-bit sized values anyway.
>
> - Modern x86 CPUs have added support for MSR access instructions using
> an immediate value instead of a register for addressing the MSR,
> while the value is in a 64-bit register.
>
> - rdmsr() is a macro storing the upper and lower 32-bit halves in
> variables specified as macro parameters. This is obscuring variable
> assignment through a macro. Additionally rdmsrq() is mimicking this
> pattern by being a macro, too, with the target variable specified as
> a parameter as well.
>
> For those reasons drop the 32-bit interfaces for accessing the x86 MSR
> registers completely and only use the 64-bit variants.
Hi Jürgen,
I assume this is fine, but since you don't mention it explicitly here,
please clarify what this means for 32-bit CPUs without the rdmsrq
instruction. Those will continue using the same instructions as before
and just change the calling conventions, right?
> Note that most patches of this series are independent from each other.
> Only the patches removing a specific interface (patches 7, 15, 26 and
> 30) and the last two patches of the series depend on all previous
> patches.
It looks like you are touching most files twice or more here, to
first convert from rdmsr to rdmsrq and then to change the
two-argument rdmsrq() macro to a single-argument inline. If you
introduce the inline version of rdmsrq() first, you should be
able to skip the second step (patch 31) as they could be able
to coexist.
Arnd
