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

[Jürgen Groß <jgross@xxxxxxxx>]

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: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature