MSR access API uses in KVM x86

MSR access API uses in KVM x86

[Xin Li]

It looks to me that MSR access API uses in KVM x86 are NOT consistent;
sometimes {wr,rd}msrl() are used and sometimes native_{wr,rd}msrl() are
used.

Was there a reason that how a generic or native MSR API was chosen?

In my opinion KVM should use the native MSR APIs, which can streamline
operations and potentially improve performance by avoiding the overhead
associated with generic MSR API indirect calls when CONFIG_XEN_PV=y.

No?

Thanks!
     Xin

Re: MSR access API uses in KVM x86

[Sean Christopherson]

On Mon, Apr 21, 2025, Xin Li wrote:
> It looks to me that MSR access API uses in KVM x86 are NOT consistent;
> sometimes {wr,rd}msrl() are used and sometimes native_{wr,rd}msrl() are
> used.
> 
> Was there a reason that how a generic or native MSR API was chosen?

I doubt anyone knows for sure; that'd likely require a time travelling device
and/or telepathic abilities :-)

> In my opinion KVM should use the native MSR APIs, which can streamline
> operations and potentially improve performance by avoiding the overhead
> associated with generic MSR API indirect calls when CONFIG_XEN_PV=y.

As Jürgen pointed out, they aren't indirect calls.  Though IIUC, there is still
a direct CALL and thus a RET when PARAVIRT_XXL=Y.

I agree that using PV APIs in KVM doesn't make much sense, as running KVM in a
XEN PV guest doesn't seem like something we should optimize for, if it's even
supported.  So if we end up churning all of the rdmsr/wrmsr macros, I have no
objection to switching to native variants.

Though if we do that, it would be nice if there's a way to avoid the "native_"
prefix everywhere, for the sake of readability.

Re: MSR access API uses in KVM x86

[Juergen Gross]

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

On 22.04.25 16:40, Sean Christopherson wrote:
> On Mon, Apr 21, 2025, Xin Li wrote:
>> It looks to me that MSR access API uses in KVM x86 are NOT consistent;
>> sometimes {wr,rd}msrl() are used and sometimes native_{wr,rd}msrl() are
>> used.
>>
>> Was there a reason that how a generic or native MSR API was chosen?
> 
> I doubt anyone knows for sure; that'd likely require a time travelling device
> and/or telepathic abilities :-)
> 
>> In my opinion KVM should use the native MSR APIs, which can streamline
>> operations and potentially improve performance by avoiding the overhead
>> associated with generic MSR API indirect calls when CONFIG_XEN_PV=y.
> 
> As Jürgen pointed out, they aren't indirect calls.  Though IIUC, there is still
> a direct CALL and thus a RET when PARAVIRT_XXL=Y.
> 
> I agree that using PV APIs in KVM doesn't make much sense, as running KVM in a
> XEN PV guest doesn't seem like something we should optimize for, if it's even
> supported.

Shudder. :-D

No, definitely not supported.


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 --]

Re: MSR access API uses in KVM x86

[Xin Li]

On 4/22/2025 7:40 AM, Sean Christopherson wrote:
> On Mon, Apr 21, 2025, Xin Li wrote:
>> It looks to me that MSR access API uses in KVM x86 are NOT consistent;
>> sometimes {wr,rd}msrl() are used and sometimes native_{wr,rd}msrl() are
>> used.
>>
>> Was there a reason that how a generic or native MSR API was chosen?
> 
> I doubt anyone knows for sure; that'd likely require a time travelling device
> and/or telepathic abilities :-)
> 
>> In my opinion KVM should use the native MSR APIs, which can streamline
>> operations and potentially improve performance by avoiding the overhead
>> associated with generic MSR API indirect calls when CONFIG_XEN_PV=y.
> 
> As Jürgen pointed out, they aren't indirect calls.  Though IIUC, there is still

Right, I didn't notice such an optimization went in.

> a direct CALL and thus a RET when PARAVIRT_XXL=Y.

Correct.

> 
> I agree that using PV APIs in KVM doesn't make much sense, as running KVM in a
> XEN PV guest doesn't seem like something we should optimize for, if it's even
> supported.  So if we end up churning all of the rdmsr/wrmsr macros, I have no
> objection to switching to native variants.

Thanks for the confirmation.

> 
> Though if we do that, it would be nice if there's a way to avoid the "native_"
> prefix everywhere, for the sake of readability.
> 

Yeah, I will think about better naming them.