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

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

On 25.04.25 05:44, H. Peter Anvin wrote:
> On 4/24/25 18: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...
> > > > 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.
> Note that to support the immediate forms, we *must* do these inline, or the 
> const-ness of the MSR index -- which applies to by far the vast majority of MSR 
> references -- gets lost. pvops does exactly that.
> Furthermore, the MSR immediate instructions take a 64-bit number in a single 
> register; as these instructions are by necessity relatively long, it makes sense 
> for the alternative sequence to accept a 64-bit input register and do the %eax/ 
> %edx shuffle in the legacy fallback code... we did a bunch of experiments to see 
> what made most sense.
Yes, I understand that.

And I'm totally in favor of Xin's rework of the MSR low level functions.

Inlining the MSR access instructions with pv_ops should not be very
complicated. We do that with other instructions (STI/CLI, PTE accesses)
today, so this is no new kind of functionality.

I could have a try writing a patch achieving that, but I would only start
that work in case you might consider taking it instead of Xin's patch
removing the pv_ops usage for rdmsr/wrmsr. In case it turns out that my
version results in more code changes than Xin's patch, I'd be fine to drop
my patch, of course.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature