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

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

On 25.04.25 03:15, H. Peter Anvin wrote:
> On 4/24/25 01:14, Jürgen Groß wrote:
> > > 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...
> > And this is what I'm questioning. IMHO this approach is adding more
> > code by removing the pv_ops MSR_APIs just because "pv_ops is bad". And
> > I believe most refusal of pv_ops is based on no longer valid reasoning.
> pvops are a headache because it is effectively a secondary alternatives 
> infrastructure that is incompatible with the alternatives one...
Hu? How can that be, as pv_ops is using only alternatives infrastructure
for doing the patching?

I'd say today pv_ops is a convenience wrapper around alternatives.

> > > It looks to me that you want to add a new facility to the alternatives
> > > infrastructure first?
> > Why would we need a new facility in the alternatives infrastructure?
> I'm not sure what Xin means with "facility", but a key motivation for this is 
> to:
>
> a. Avoid using the pvops for MSRs when on the only remaining user thereof (Xen) 
> is only using it for a very small subset of MSRs and for the rest it is just 
> overhead, even for Xen;
> b. Being able to do wrmsrns immediate/wrmsrns/wrmsr and rdmsr immediate/rdmsr 
> alternatives.
> Of these, (b) is by far the biggest motivation. The architectural direction for 
> supervisor states is to avoid ad hoc and XSAVES ISA and instead use MSRs. The 
> immediate forms are expected to be significantly faster, because they make the 
> MSR index available at the very beginning of the pipeline instead of at a 
> relatively late stage.
I understand the motivation for b), but I think this could be achieved without
a) rather easily. And I continue to believe that your reasoning for a) is based
on old facts. But may be I'm just not understanding your concerns with today's
pv_ops implementation.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature