[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 22.04.25 11:20, Xin Li wrote:
On 4/22/2025 1:59 AM, Jürgen Groß wrote:
On 22.04.25 10:22, Xin Li (Intel) wrote:
To eliminate the indirect call overhead introduced by the pv_ops API,
utilize the alternatives mechanism to read MSR:

     1) When built with !CONFIG_XEN_PV, X86_FEATURE_XENPV becomes a
        disabled feature, preventing the Xen code from being built
        and ensuring the native code is executed unconditionally.

     2) When built with CONFIG_XEN_PV:

        2.1) If not running on the Xen hypervisor (!X86_FEATURE_XENPV),
             the kernel runtime binary is patched to unconditionally
             jump to the native MSR read code.

        2.2) If running on the Xen hypervisor (X86_FEATURE_XENPV), the
             kernel runtime binary is patched to unconditionally jump
             to the Xen MSR read code.

The alternatives mechanism is also used to choose the new immediate
form MSR read instruction when it's available.

Consequently, remove the pv_ops MSR read APIs and the Xen callbacks.

Same as the comment to patch 5: there is no indirect call overhead after
the system has come up.


Please check https://lore.kernel.org/lkml/87y1h81ht4.ffs@tglx/.

And it's was also mentioned in the previous patch:

https://lore.kernel.org/lkml/20250422082216.1954310-22-xin@xxxxxxxxx/

Please let me know what I have missed.

Please see my response to the previous patch.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.