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

[Xin Li <xin@xxxxxxxxx>]

On 4/23/2025 9:05 AM, Jürgen Groß wrote:
> > It's not a major change, but when it is patched to use the immediate 
> > form MSR write instruction, it's straightforwardly streamlined.
> It should be rather easy to switch the current wrmsr/rdmsr paravirt 
> patching
> locations to use the rdmsr/wrmsr instructions instead of doing a call to
> native_*msr().
>
> The case of the new immediate form could be handled the same way.
Actually, that is how we get this patch with the existing alternatives
infrastructure.  And we took a step further to also remove the pv_ops
MSR APIs...

It looks to me that you want to add a new facility to the alternatives
infrastructure first?


> > > Only the "paravirt" term has been eliminated.
> > Yes.
> >
> > But a PV guest doesn't operate at the highest privilege level, which
> > means MSR instructions typically result in a #GP fault.  I actually 
> > think the pv_ops MSR APIs are unnecessary because of this inherent
> > limitation.
> >
> > Looking at the Xen MSR code, except PMU and just a few MSRs, it falls
> > back to executes native MSR instructions.  As MSR instructions trigger
> > #GP, Xen takes control and handles them in 2 ways:
> >
> >    1) emulate (or ignore) a MSR operation and skip the guest instruction.
> >
> >    2) inject the #GP back to guest OS and let its #GP handler handle it.
> >       But Linux MSR exception handler just ignores the MSR instruction
> >       (MCE MSR exception will panic).
> >
> > So why not let Xen handle all the details which it already tries to do?
> Some MSRs are not handled that way, but via a kernel internal emulation.
> And those are handled that way mostly due to performance reasons. And some
> need special treatment.
>
> > (Linux w/ such a change may not be able to run on old Xen hypervisors.)
> Yes, and this is something to avoid.
>
> And remember that Linux isn't the only PV-mode guest existing.
>
> > BTW, if performance is a concern, writes to MSR_KERNEL_GS_BASE and
> > MSR_GS_BASE anyway are hpyercalls into Xen.
> Yes, and some other MSR writes are just NOPs with Xen-PV.
I will do some cleanup and refactor first.

BTW, at least we can merge the safe() APIs into the non-safe() ones.

Thanks!
    Xin