summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorSean Christopherson <sean.j.christopherson@intel.com>2019-02-05 13:01:18 -0800
committerPaolo Bonzini <pbonzini@redhat.com>2019-02-20 22:48:37 +0100
commit164bf7e56c5a73f2f819c39ba7e0f20e0f97dc7b (patch)
treeb64283dd04a5aa6024d6fd6639db781bfe1c613e /Documentation
parent0e32958ec449a9bb63c031ed04ac7a494ea1bc1c (diff)
downloadlinux-164bf7e56c5a73f2f819c39ba7e0f20e0f97dc7b.tar.gz
linux-164bf7e56c5a73f2f819c39ba7e0f20e0f97dc7b.tar.bz2
linux-164bf7e56c5a73f2f819c39ba7e0f20e0f97dc7b.zip
KVM: Move the memslot update in-progress flag to bit 63
...now that KVM won't explode by moving it out of bit 0. Using bit 63 eliminates the need to jump over bit 0, e.g. when calculating a new memslots generation or when propagating the memslots generation to an MMIO spte. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/virtual/kvm/mmu.txt13
1 files changed, 8 insertions, 5 deletions
diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt
index e507a9e0421e..367a952f50ab 100644
--- a/Documentation/virtual/kvm/mmu.txt
+++ b/Documentation/virtual/kvm/mmu.txt
@@ -452,13 +452,16 @@ stored into the MMIO spte. Thus, the MMIO spte might be created based on
out-of-date information, but with an up-to-date generation number.
To avoid this, the generation number is incremented again after synchronize_srcu
-returns; thus, the low bit of kvm_memslots(kvm)->generation is only 1 during a
+returns; thus, bit 63 of kvm_memslots(kvm)->generation set to 1 only during a
memslot update, while some SRCU readers might be using the old copy. We do not
want to use an MMIO sptes created with an odd generation number, and we can do
-this without losing a bit in the MMIO spte. The low bit of the generation
-is not stored in MMIO spte, and presumed zero when it is extracted out of the
-spte. If KVM is unlucky and creates an MMIO spte while the low bit is 1,
-the next access to the spte will always be a cache miss.
+this without losing a bit in the MMIO spte. The "update in-progress" bit of the
+generation is not stored in MMIO spte, and is so is implicitly zero when the
+generation is extracted out of the spte. If KVM is unlucky and creates an MMIO
+spte while an update is in-progress, the next access to the spte will always be
+a cache miss. For example, a subsequent access during the update window will
+miss due to the in-progress flag diverging, while an access after the update
+window closes will have a higher generation number (as compared to the spte).
Further reading