On 25.04.25 03:15, H. Peter Anvin wrote:

On 4/24/25 01:14, Jürgen Groß wrote:

quoted

quoted

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.

quoted

quoted

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