From: "Huang, Kai" <kai.huang@intel.com>
To: "pbonzini@redhat.com" <pbonzini@redhat.com>, "Christopherson,,
Sean" <seanjc@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"guoke@uniontech.com" <guoke@uniontech.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"haiwenyao@uniontech.com" <haiwenyao@uniontech.com>
Subject: Re: [PATCH 1/5] KVM: VMX: Open code writing vCPU's PAT in VMX's MSR handler
Date: Wed, 3 May 2023 23:00:53 +0000 [thread overview]
Message-ID: <56fa0da83203b20c9945e7c82a0eed11f3d31ea5.camel@intel.com> (raw)
In-Reply-To: <20230503182852.3431281-2-seanjc@google.com>
On Wed, 2023-05-03 at 11:28 -0700, Sean Christopherson wrote:
> From: Wenyao Hai <haiwenyao@uniontech.com>
>
> Open code setting "vcpu->arch.pat" in vmx_set_msr() instead of bouncing
> through kvm_set_msr_common() to get to the same code in kvm_mtrr_set_msr().
What's the value of doing so, besides saving a function of kvm_set_msr_common()?
PAT change shouldn't be something frequent so shouldn't in a performance
critical path. Given the PAT logic on Intel and AMD are basically the same ,
isn't it better to do in kvm_set_msr_common()?
For instance, given mtrr code is also in common x86, if we ever want to add some
additional logic to, i.e. calculate effective memtype, isn't better to do handle
pat in common code too?
>
> Note, MSR_IA32_CR_PAT is 0x277, and is very subtly handled by
>
> case 0x200 ... MSR_IA32_MC0_CTL2 - 1:
>
> in kvm_set_msr_common().
>
> Signed-off-by: Wenyao Hai <haiwenyao@uniontech.com>
> [sean: massage changelog]
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> arch/x86/kvm/vmx/vmx.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 44fb619803b8..53e249109483 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -2294,12 +2294,10 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> get_vmcs12(vcpu)->vm_exit_controls & VM_EXIT_SAVE_IA32_PAT)
> get_vmcs12(vcpu)->guest_ia32_pat = data;
>
> - if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT) {
> + if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT)
> vmcs_write64(GUEST_IA32_PAT, data);
> - vcpu->arch.pat = data;
> - break;
> - }
> - ret = kvm_set_msr_common(vcpu, msr_info);
> +
> + vcpu->arch.pat = data;
> break;
> case MSR_IA32_MCG_EXT_CTL:
> if ((!msr_info->host_initiated &&
next prev parent reply other threads:[~2023-05-03 23:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 18:28 [PATCH 0/5] KVM: x86: Clean up MSR PAT handling Sean Christopherson
2023-05-03 18:28 ` [PATCH 1/5] KVM: VMX: Open code writing vCPU's PAT in VMX's MSR handler Sean Christopherson
2023-05-03 23:00 ` Huang, Kai [this message]
2023-05-03 23:25 ` Sean Christopherson
2023-05-03 23:41 ` Huang, Kai
2023-05-04 17:23 ` Sean Christopherson
2023-05-03 18:28 ` [PATCH 2/5] KVM: SVM: Use kvm_pat_valid() directly instead of kvm_mtrr_valid() Sean Christopherson
2023-05-03 23:04 ` Huang, Kai
2023-05-04 15:34 ` Sean Christopherson
2023-05-05 11:20 ` Huang, Kai
2023-05-11 23:03 ` Sean Christopherson
2023-05-03 18:28 ` [PATCH 3/5] KVM: x86: Use MTRR macros to define possible MTRR MSR ranges Sean Christopherson
2023-05-03 23:23 ` Huang, Kai
2023-05-03 23:36 ` Sean Christopherson
2023-05-03 23:49 ` Huang, Kai
2023-05-04 9:02 ` Yan Zhao
2023-05-04 15:36 ` Sean Christopherson
2023-05-03 18:28 ` [PATCH 4/5] KVM: x86: WARN if writes to PAT MSR are handled by common KVM code Sean Christopherson
2023-05-03 23:26 ` Huang, Kai
2023-05-03 23:38 ` Sean Christopherson
2023-05-03 18:28 ` [PATCH 5/5] KVM: x86: Move PAT MSR handling out of mtrr.c 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=56fa0da83203b20c9945e7c82a0eed11f3d31ea5.camel@intel.com \
--to=kai.huang@intel.com \
--cc=guoke@uniontech.com \
--cc=haiwenyao@uniontech.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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
all inboxes | Powered by JetHome®