Re: [RFC PATCH v2 22/34] x86/msr: Utilize the alternatives mechanism to read MSR

Jürgen Groß
2025-04-23T16:11:13Z

[-- Attachment #1.1.1: Type: text/plain, Size: 1295 bytes --]

On 23.04.25 11:03, Xin Li wrote:
> On 4/22/2025 4:12 AM, Jürgen Groß wrote:
>>> +
>>> +static __always_inline bool __rdmsrq(u32 msr, u64 *val, int type)
>>> +{
>>> +    bool ret;
>>> +
>>> +#ifdef CONFIG_XEN_PV
>>> +    if (cpu_feature_enabled(X86_FEATURE_XENPV))
>>> +        return __xenpv_rdmsrq(msr, val, type);
>>
>> I don't think this will work for the Xen PV case.
>
> Well, I have been testing the code on xen-4.17 coming with Ubuntu
> 24.04.2 LTS :)

Hmm, seems that the accessed MSR(s) are the ones falling back to the
native_rdmsr() calls. At least on the hardware you tested on.

>> X86_FEATURE_XENPV is set only after the first MSR is being read.
>
> No matter whether the code works or not, good catch!
>
>>
>> This can be fixed by setting the feature earlier, but it shows that the
>> paravirt feature has its benefits in such cases.
>
> See my other reply to let Xen handle all the details.
>
> Plus the code actually works, I would actually argue the opposite :-P

BTW, it was in kernel 6.12 I had to change the MSR read emulation for
Xen-PV the last time (fix some problems with changed x86 topology
detection). Things like that won't be easily put into the hypervisor,
which needs to serve other OS-es, too.

Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]