From: Chia-I Wu <olvaffe@gmail.com>
To: kvm@vger.kernel.org
Cc: wanpengli@tencent.com, joro@8bytes.org,
dri-devel@lists.freedesktop.org, gurchetansingh@chromium.org,
kraxel@redhat.com, pbonzini@redhat.com, vkuznets@redhat.com,
jmattson@google.com
Subject: [RFC PATCH 1/3] KVM: vmx: rewrite the comment in vmx_get_mt_mask
Date: Thu, 13 Feb 2020 13:30:34 -0800 [thread overview]
Message-ID: <20200213213036.207625-2-olvaffe@gmail.com> (raw)
In-Reply-To: <20200213213036.207625-1-olvaffe@gmail.com>
Better reflect the structure of the code and metion why we could not
always honor the guest.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Cc: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
---
arch/x86/kvm/vmx/vmx.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 3be25ecae145..266ef87042da 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6854,17 +6854,24 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
u8 cache;
u64 ipat = 0;
- /* For VT-d and EPT combination
- * 1. MMIO: always map as UC
- * 2. EPT with VT-d:
- * a. VT-d without snooping control feature: can't guarantee the
- * result, try to trust guest.
- * b. VT-d with snooping control feature: snooping control feature of
- * VT-d engine can guarantee the cache correctness. Just set it
- * to WB to keep consistent with host. So the same as item 3.
- * 3. EPT without VT-d: always map as WB and set IPAT=1 to keep
- * consistent with host MTRR
+ /* 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.
+ *
+ * For MMIO, guest CD/MTRR are ignored. The EPT memory type is set to
+ * UC. The effective memory type is UC or WC depending on guest PAT.
+ * This was historically the source of MCEs and we want to be
+ * conservative.
+ *
+ * When there is no need to deal with noncoherent DMA (e.g., no VT-d
+ * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored. The
+ * EPT memory type is set to WB. The effective memory type is forced
+ * WB.
+ *
+ * Otherwise, we trust guest. Guest CD/MTRR/PAT are all honored. The
+ * EPT memory type is used to emulate guest CD/MTRR.
*/
+
if (is_mmio) {
cache = MTRR_TYPE_UNCACHABLE;
goto exit;
--
2.25.0.265.gbab2e86ba0-goog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Chia-I Wu <olvaffe@gmail.com>
To: kvm@vger.kernel.org
Cc: pbonzini@redhat.com, vkuznets@redhat.com, wanpengli@tencent.com,
jmattson@google.com, joro@8bytes.org,
gurchetansingh@chromium.org, kraxel@redhat.com,
dri-devel@lists.freedesktop.org
Subject: [RFC PATCH 1/3] KVM: vmx: rewrite the comment in vmx_get_mt_mask
Date: Thu, 13 Feb 2020 13:30:34 -0800 [thread overview]
Message-ID: <20200213213036.207625-2-olvaffe@gmail.com> (raw)
In-Reply-To: <20200213213036.207625-1-olvaffe@gmail.com>
Better reflect the structure of the code and metion why we could not
always honor the guest.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Cc: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
---
arch/x86/kvm/vmx/vmx.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 3be25ecae145..266ef87042da 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6854,17 +6854,24 @@ static u64 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
u8 cache;
u64 ipat = 0;
- /* For VT-d and EPT combination
- * 1. MMIO: always map as UC
- * 2. EPT with VT-d:
- * a. VT-d without snooping control feature: can't guarantee the
- * result, try to trust guest.
- * b. VT-d with snooping control feature: snooping control feature of
- * VT-d engine can guarantee the cache correctness. Just set it
- * to WB to keep consistent with host. So the same as item 3.
- * 3. EPT without VT-d: always map as WB and set IPAT=1 to keep
- * consistent with host MTRR
+ /* 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.
+ *
+ * For MMIO, guest CD/MTRR are ignored. The EPT memory type is set to
+ * UC. The effective memory type is UC or WC depending on guest PAT.
+ * This was historically the source of MCEs and we want to be
+ * conservative.
+ *
+ * When there is no need to deal with noncoherent DMA (e.g., no VT-d
+ * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored. The
+ * EPT memory type is set to WB. The effective memory type is forced
+ * WB.
+ *
+ * Otherwise, we trust guest. Guest CD/MTRR/PAT are all honored. The
+ * EPT memory type is used to emulate guest CD/MTRR.
*/
+
if (is_mmio) {
cache = MTRR_TYPE_UNCACHABLE;
goto exit;
--
2.25.0.265.gbab2e86ba0-goog
next prev parent reply other threads:[~2020-02-13 21:30 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 21:30 [RFC PATCH 0/3] KVM: x86: honor guest memory type Chia-I Wu
2020-02-13 21:30 ` Chia-I Wu
2020-02-13 21:30 ` Chia-I Wu [this message]
2020-02-13 21:30 ` [RFC PATCH 1/3] KVM: vmx: rewrite the comment in vmx_get_mt_mask Chia-I Wu
2020-02-14 9:36 ` Paolo Bonzini
2020-02-14 9:36 ` Paolo Bonzini
2020-02-13 21:30 ` [RFC PATCH 2/3] RFC: KVM: add KVM_MEM_DMA Chia-I Wu
2020-02-13 21:30 ` Chia-I Wu
2020-02-13 21:30 ` [RFC PATCH 3/3] RFC: KVM: x86: support KVM_CAP_DMA_MEM Chia-I Wu
2020-02-13 21:30 ` Chia-I Wu
2020-02-13 21:41 ` [RFC PATCH 0/3] KVM: x86: honor guest memory type Paolo Bonzini
2020-02-13 21:41 ` Paolo Bonzini
2020-02-13 22:18 ` Chia-I Wu
2020-02-13 22:18 ` Chia-I Wu
2020-02-14 10:26 ` Paolo Bonzini
2020-02-14 10:26 ` Paolo Bonzini
2020-02-14 19:52 ` Sean Christopherson
2020-02-14 19:52 ` Sean Christopherson
2020-02-14 21:47 ` Chia-I Wu
2020-02-14 21:47 ` Chia-I Wu
2020-02-14 21:56 ` Jim Mattson
2020-02-14 21:56 ` Jim Mattson
2020-02-14 22:03 ` Sean Christopherson
2020-02-14 22:03 ` Sean Christopherson
2020-02-18 16:28 ` Paolo Bonzini
2020-02-18 16:28 ` Paolo Bonzini
2020-02-18 22:58 ` Sean Christopherson
2020-02-18 22:58 ` Sean Christopherson
2020-02-19 9:52 ` Tian, Kevin
2020-02-19 9:52 ` Tian, Kevin
2020-02-19 19:36 ` Chia-I Wu
2020-02-19 19:36 ` Chia-I Wu
2020-02-20 2:04 ` Tian, Kevin
2020-02-20 2:04 ` Tian, Kevin
2020-02-20 2:38 ` Tian, Kevin
2020-02-20 2:38 ` Tian, Kevin
2020-02-20 22:23 ` Chia-I Wu
2020-02-20 22:23 ` Chia-I Wu
2020-02-21 0:23 ` Tian, Kevin
2020-02-21 0:23 ` Tian, Kevin
2020-02-21 4:45 ` Chia-I Wu
2020-02-21 4:51 ` Chia-I Wu
2020-02-21 4:51 ` Chia-I Wu
2020-02-21 5:39 ` Tian, Kevin
2020-02-21 5:39 ` Tian, Kevin
2020-02-21 15:59 ` Sean Christopherson
2020-02-21 15:59 ` Sean Christopherson
2020-02-21 18:21 ` Chia-I Wu
2020-02-21 18:21 ` Chia-I Wu
2020-02-25 1:29 ` Tian, Kevin
2020-02-25 1:29 ` Tian, Kevin
2020-02-14 21:15 ` Chia-I Wu
2020-02-14 21:15 ` Chia-I Wu
2020-02-19 10:00 ` Tian, Kevin
2020-02-19 10:00 ` Tian, Kevin
2020-02-19 19:18 ` Chia-I Wu
2020-02-19 19:18 ` Chia-I Wu
2020-02-20 2:13 ` Tian, Kevin
2020-02-20 2:13 ` Tian, Kevin
2020-02-20 23:02 ` Chia-I Wu
2020-02-20 23:02 ` Chia-I Wu
2020-02-24 10:57 ` Gerd Hoffmann
2020-02-24 10:57 ` Gerd Hoffmann
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=20200213213036.207625-2-olvaffe@gmail.com \
--to=olvaffe@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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.