All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Xin Li <xin@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>
Subject: Re: MSR access API uses in KVM x86
Date: Tue, 22 Apr 2025 07:40:06 -0700	[thread overview]
Message-ID: <aAeqRk8fk8mvutw2@google.com> (raw)
In-Reply-To: <a82f4722-478f-4972-a072-80cd13666137@zytor.com>

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.

  reply	other threads:[~2025-04-22 14:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-21 17:21 MSR access API uses in KVM x86 Xin Li
2025-04-22 14:40 ` Sean Christopherson [this message]
2025-04-22 14:59   ` Juergen Gross
2025-04-23  9:07   ` Xin Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aAeqRk8fk8mvutw2@google.com \
    --to=seanjc@google.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=xin@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.