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

Jürgen Groß
2025-04-25T06:52:02Z

[-- Attachment #1.1.1: Type: text/plain, Size: 2019 bytes --]

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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]