From: Yan Zhao <yan.y.zhao@intel.com>
To: Chao Gao <chao.gao@intel.com>
Cc: <kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<pbonzini@redhat.com>, <seanjc@google.com>, <kai.huang@intel.com>,
<robert.hoo.linux@gmail.com>
Subject: Re: [PATCH v3 07/11] KVM: VMX: drop IPAT in memtype when CD=1 for KVM_X86_QUIRK_CD_NW_CLEARED
Date: Tue, 20 Jun 2023 11:17:10 +0800 [thread overview]
Message-ID: <ZJEaNlDe1jVkYyqz@yzhao56-desk.sh.intel.com> (raw)
In-Reply-To: <ZJESMaG5Thb5LWtt@chao-email>
On Tue, Jun 20, 2023 at 10:42:57AM +0800, Chao Gao wrote:
> >
> >diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> >index 0ecf4be2c6af..c1e93678cea4 100644
> >--- a/arch/x86/kvm/vmx/vmx.c
> >+++ b/arch/x86/kvm/vmx/vmx.c
> >@@ -7548,8 +7548,6 @@ static int vmx_vm_init(struct kvm *kvm)
> >
> > static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> > {
> >- u8 cache;
> >-
> > /* We wanted to honor guest CD/MTRR/PAT, but doing so could result in
> > * memory aliases with conflicting memory types and sometimes MCEs.
> > * We have to be careful as to what are honored and when.
> >@@ -7576,11 +7574,10 @@ static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> >
> > if (kvm_read_cr0_bits(vcpu, X86_CR0_CD)) {
> > if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED))
> >- cache = MTRR_TYPE_WRBACK;
> >+ return MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT;
>
> Shouldn't KVM honor guest MTRRs as well? i.e., as if CR0.CD isn't set.
I proposed to return guest mtrr type when CR0.CD=1.
https://lore.kernel.org/all/ZHDZpHYQhPtkNnQe@google.com/
Sean rejected it because before guest MTRR is first time enabled, we
have to return WB with the quirk, otherwise the VM bootup will be super
slow.
Or maybe we can return WB when guest MTRR is not enabled and guest MTRR
type when guest MTRR is anabled to woraround it. e.g.
if (kvm_read_cr0_bits(vcpu, X86_CR0_CD)) {
if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED))
{
cache = !mtrr_is_enabled(mtrr_state) ? MTRR_TYPE_WRBACK :
kvm_mtrr_get_guest_memory_type(vcpu, gfn);
return cache << VMX_EPT_MT_EPTE_SHIFT;
}
...
}
But Sean does not like piling too much on top of the quirk and I think it is right
to keep the quirk simple.
"In short, I am steadfastly against any change that piles more arbitrary behavior
functional behavior on top of the quirk, especially when that behavior relies on
heuristics to try and guess what the guest is doing."
>
> > else
> >- cache = MTRR_TYPE_UNCACHABLE;
> >-
> >- return (cache << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT;
> >+ return (MTRR_TYPE_UNCACHABLE << VMX_EPT_MT_EPTE_SHIFT) |
> >+ VMX_EPT_IPAT_BIT;
> > }
> >
> > return kvm_mtrr_get_guest_memory_type(vcpu, gfn) << VMX_EPT_MT_EPTE_SHIFT;
> >--
> >2.17.1
> >
next prev parent reply other threads:[~2023-06-20 3:42 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 2:31 [PATCH v3 00/11] KVM: x86/mmu: refine memtype related mmu zap Yan Zhao
2023-06-16 2:32 ` [PATCH v3 01/11] KVM: x86/mmu: helpers to return if KVM honors guest MTRRs Yan Zhao
2023-06-16 2:34 ` [PATCH v3 02/11] KVM: x86/mmu: Use KVM honors guest MTRRs helper in kvm_tdp_page_fault() Yan Zhao
2023-06-16 2:35 ` [PATCH v3 03/11] KVM: x86/mmu: Use KVM honors guest MTRRs helper when CR0.CD toggles Yan Zhao
2023-06-28 21:59 ` Sean Christopherson
2023-06-29 1:42 ` Yan Zhao
2023-06-16 2:36 ` [PATCH v3 04/11] KVM: x86/mmu: Use KVM honors guest MTRRs helper when update mtrr Yan Zhao
2023-06-28 22:08 ` Sean Christopherson
2023-06-16 2:37 ` [PATCH v3 05/11] KVM: x86/mmu: zap KVM TDP when noncoherent DMA assignment starts/stops Yan Zhao
2023-06-16 2:37 ` [PATCH v3 06/11] KVM: x86/mmu: move TDP zaps from guest MTRRs update to CR0.CD toggling Yan Zhao
2023-06-16 2:38 ` [PATCH v3 07/11] KVM: VMX: drop IPAT in memtype when CD=1 for KVM_X86_QUIRK_CD_NW_CLEARED Yan Zhao
2023-06-20 2:42 ` Chao Gao
2023-06-20 2:34 ` Yan Zhao
2023-06-20 3:34 ` Chao Gao
2023-06-20 3:19 ` Yan Zhao
2023-06-25 7:14 ` Xiaoyao Li
2023-06-26 0:08 ` Yan Zhao
2023-06-26 3:40 ` Yuan Yao
2023-06-26 3:38 ` Yan Zhao
2023-06-20 3:17 ` Yan Zhao [this message]
2023-06-16 2:38 ` [PATCH v3 08/11] KVM: x86: move vmx code to get EPT memtype when CR0.CD=1 to x86 common code Yan Zhao
2023-06-28 22:57 ` Sean Christopherson
2023-06-29 0:55 ` Yan Zhao
2023-06-29 20:42 ` Sean Christopherson
2023-06-30 7:49 ` Yan Zhao
2023-07-14 7:00 ` Yan Zhao
2023-06-16 2:39 ` [PATCH v3 09/11] KVM: x86/mmu: serialize vCPUs to zap gfn when guest MTRRs are honored Yan Zhao
2023-06-16 7:45 ` Yuan Yao
2023-06-16 7:37 ` Yan Zhao
2023-06-16 8:09 ` Yuan Yao
2023-06-16 7:50 ` Yan Zhao
2023-06-28 23:00 ` Sean Christopherson
2023-06-29 1:51 ` Yan Zhao
2023-06-16 2:41 ` [PATCH v3 10/11] KVM: x86/mmu: fine-grained gfn zap " Yan Zhao
2023-06-16 2:42 ` [PATCH v3 11/11] KVM: x86/mmu: split a single gfn zap range " Yan Zhao
2023-06-28 23:02 ` [PATCH v3 00/11] KVM: x86/mmu: refine memtype related mmu zap Sean Christopherson
2023-07-14 7:11 ` Yan Zhao
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=ZJEaNlDe1jVkYyqz@yzhao56-desk.sh.intel.com \
--to=yan.y.zhao@intel.com \
--cc=chao.gao@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=robert.hoo.linux@gmail.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®