[PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces

[Jürgen Groß]

On 29.06.26 08:52, Arnd Bergmann wrote:
> 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?

Yes. I thought this would be clear from the following:

   - They are based on primitives using 64-bit sized values anyway.

> 
>> 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.

I've discussed how to structure the series with Ingo Molnar before [1]. The
current approach was his preference.


Juergen

[1]: https://lore.kernel.org/lkml/f8d02c78-4681-4043-a5fa-921fa790b1b4@suse.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB0DE9DD628BF132F.asc
Type: application/pgp-keys
Size: 3683 bytes
Desc: OpenPGP public key
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20260629/0ec4979a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20260629/0ec4979a/attachment-0001.sig>