public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, Xiaoyao Li <xiaoyao.li@intel.com>,
	"Pawan Gupta" <pawan.kumar.gupta@linux.intel.com>
Subject: Re: [PATCH 1/2] KVM: x86: Snapshot host's MSR_IA32_ARCH_CAPABILITIES
Date: Mon, 12 Jun 2023 16:34:56 +0800	[thread overview]
Message-ID: <ZIbYsBv43EcwLavy@chao-email> (raw)
In-Reply-To: <20230607004311.1420507-2-seanjc@google.com>

On Tue, Jun 06, 2023 at 05:43:09PM -0700, Sean Christopherson wrote:
>Snapshot the host's MSR_IA32_ARCH_CAPABILITIES, if it's supported, instead
>of reading the MSR every time KVM wants to query the host state, e.g. when
>initializing the default value during vCPU creation.  The paths that query
>ARCH_CAPABILITIES aren't particularly performance sensitive, but creating
>vCPUs is a frequent enough operation that burning 8 bytes is a good
>trade-off.
>
>Alternatively, KVM could add a field in kvm_caps and thus skip the
>on-demand calculations entirely, but a pure snapshot isn't possible due to
>the way KVM handles the l1tf_vmx_mitigation module param.  And unlike the
>other "supported" fields in kvm_caps, KVM doesn't enforce the "supported"
>value, i.e. KVM treats ARCH_CAPABILITIES like a CPUID leaf and lets
>userspace advertise whatever it wants.  Those problems are solvable, but
>it's not clear there is real benefit versus snapshotting the host value,
>and grabbing the host value will allow additional cleanup of KVM's
>FB_CLEAR_CTRL code.
>
>Link: https://lore.kernel.org/all/20230524061634.54141-2-chao.gao@intel.com
>Cc: Chao Gao <chao.gao@intel.com>
>Cc: Xiaoyao Li <xiaoyao.li@intel.com>
>Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: Chao Gao <chao.gao@intel.com>

  parent reply	other threads:[~2023-06-12  8:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-07  0:43 [PATCH 0/2] KVM: x86: Snapshot host MSR_IA32_ARCH_CAPABILITIES Sean Christopherson
2023-06-07  0:43 ` [PATCH 1/2] KVM: x86: Snapshot host's MSR_IA32_ARCH_CAPABILITIES Sean Christopherson
2023-06-08  3:12   ` Xiaoyao Li
2023-06-12  8:34   ` Chao Gao [this message]
2023-06-07  0:43 ` [PATCH 2/2] KVM: VMX: Drop unnecessary vmx_fb_clear_ctrl_available "cache" Sean Christopherson
2023-06-07 20:20   ` Pawan Gupta
2023-06-08  3:15   ` Xiaoyao Li
2023-08-03  0:04 ` [PATCH 0/2] KVM: x86: Snapshot host MSR_IA32_ARCH_CAPABILITIES Sean Christopherson

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=ZIbYsBv43EcwLavy@chao-email \
    --to=chao.gao@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=xiaoyao.li@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox