From: Paolo Bonzini <pbonzini@redhat.com>
To: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
David Matlack <dmatlack@google.com>
Cc: Gleb Natapov <gleb@kernel.org>, Avi Kivity <avi.kivity@gmail.com>,
mtosatti@redhat.com, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number
Date: Tue, 19 Aug 2014 10:28:20 +0200 [thread overview]
Message-ID: <53F30AA4.4050803@redhat.com> (raw)
In-Reply-To: <53F2C997.6070605@linux.vnet.ibm.com>
Il 19/08/2014 05:50, Xiao Guangrong ha scritto:
>
> Note in the step *, my approach detects the invalid generation-number which
> will invalidate the mmio spte properly .
You are right, in fact my mail included another part: "Another
alternative could be to use the low bit to mark an in-progress change,
*and skip the caching if the low bit is set*."
I think if you always treat the low bit as zero in mmio sptes, you can
do that without losing a bit of the generation.
Something like this (untested/uncompiled):
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 931467881da7..3a56d377c6d7 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -199,16 +199,20 @@ void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask)
EXPORT_SYMBOL_GPL(kvm_mmu_set_mmio_spte_mask);
/*
- * spte bits of bit 3 ~ bit 11 are used as low 9 bits of generation number,
- * the bits of bits 52 ~ bit 61 are used as high 10 bits of generation
- * number.
+ * the low bit of the generation number is always presumed to be zero.
+ * This disables mmio caching during memslot updates. The concept is
+ * similar to a seqcount but instead of retrying the access we just punt
+ * and ignore the cache.
+ *
+ * spte bits 3-11 are used as bits 1-9 of the generation number,
+ * the bits 52-61 are used as bits 10-19 of the generation number.
*/
-#define MMIO_SPTE_GEN_LOW_SHIFT 3
+#define MMIO_SPTE_GEN_LOW_SHIFT 2
#define MMIO_SPTE_GEN_HIGH_SHIFT 52
-#define MMIO_GEN_SHIFT 19
-#define MMIO_GEN_LOW_SHIFT 9
-#define MMIO_GEN_LOW_MASK ((1 << MMIO_GEN_LOW_SHIFT) - 1)
+#define MMIO_GEN_SHIFT 20
+#define MMIO_GEN_LOW_SHIFT 10
+#define MMIO_GEN_LOW_MASK ((1 << MMIO_GEN_LOW_SHIFT) - 2)
#define MMIO_GEN_MASK ((1 << MMIO_GEN_SHIFT) - 1)
#define MMIO_MAX_GEN ((1 << MMIO_GEN_SHIFT) - 1)
@@ -236,12 +240,7 @@ static unsigned int get_mmio_spte_generation(u64 spte)
static unsigned int kvm_current_mmio_generation(struct kvm *kvm)
{
- /*
- * Init kvm generation close to MMIO_MAX_GEN to easily test the
- * code of handling generation number wrap-around.
- */
- return (kvm_memslots(kvm)->generation +
- MMIO_MAX_GEN - 150) & MMIO_GEN_MASK;
+ return kvm_memslots(kvm)->generation & MMIO_GEN_MASK;
}
static void mark_mmio_spte(struct kvm *kvm, u64 *sptep, u64 gfn,
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index a69a623938b8..c7e2800313b8 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -474,6 +476,13 @@ static struct kvm *kvm_create_vm(unsigned long type)
kvm->memslots = kzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
if (!kvm->memslots)
goto out_err_no_srcu;
+
+ /*
+ * Init kvm generation close to MMIO_MAX_GEN to easily test the
+ * code of handling generation number wrap-around.
+ */
+ kvm->memslots->generation = -150;
+
kvm_init_memslots_id(kvm);
if (init_srcu_struct(&kvm->srcu))
goto out_err_no_srcu;
@@ -725,6 +732,8 @@ static struct kvm_memslots *install_new_memslots(struct kvm *kvm,
synchronize_srcu_expedited(&kvm->srcu);
kvm_arch_memslots_updated(kvm);
+ slots->generation++;
+ WARN_ON(slots->generation & 1);
return old_memslots;
}
(modulo the changes to always set the generation in install_new_memslots, which
I'm eliding for clarity).
Moving the initialization to kvm_create_vm ensures that the low bit is untouched
between install_new_memslots and kvm_current_mmio_generation.
next prev parent reply other threads:[~2014-08-19 8:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-14 7:01 [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number Xiao Guangrong
2014-08-14 7:01 ` [PATCH 2/2] kvm: x86: fix stale mmio cache bug Xiao Guangrong
2014-08-14 16:25 ` David Matlack
2014-08-18 21:24 ` Paolo Bonzini
2014-08-14 7:06 ` [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number Xiao Guangrong
2014-08-18 13:57 ` Paolo Bonzini
2014-08-18 16:35 ` Xiao Guangrong
2014-08-18 16:35 ` Xiao Guangrong
2014-08-18 18:20 ` David Matlack
2014-08-18 18:47 ` Paolo Bonzini
2014-08-18 18:47 ` Paolo Bonzini
2014-08-18 19:56 ` Xiao Guangrong
2014-08-18 19:56 ` Xiao Guangrong
2014-08-18 21:15 ` David Matlack
2014-08-18 21:24 ` Paolo Bonzini
2014-08-18 21:33 ` David Matlack
2014-08-19 3:50 ` Xiao Guangrong
2014-08-19 4:31 ` David Matlack
2014-08-19 4:41 ` Xiao Guangrong
2014-08-19 5:00 ` David Matlack
2014-08-19 5:19 ` Xiao Guangrong
2014-08-19 5:40 ` David Matlack
2014-08-19 5:55 ` Xiao Guangrong
2014-08-19 8:28 ` Paolo Bonzini [this message]
2014-08-19 8:50 ` Xiao Guangrong
2014-08-19 9:03 ` Paolo Bonzini
2014-08-20 0:29 ` Xiao Guangrong
2014-08-20 1:03 ` David Matlack
2014-08-20 8:38 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2014-08-12 5:02 Xiao Guangrong
2014-08-12 21:18 ` David Matlack
2014-08-14 5:41 ` Xiao Guangrong
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=53F30AA4.4050803@redhat.com \
--to=pbonzini@redhat.com \
--cc=avi.kivity@gmail.com \
--cc=dmatlack@google.com \
--cc=gleb@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=stable@vger.kernel.org \
--cc=xiaoguangrong@linux.vnet.ibm.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.