* [PATCH 0/2] Fixups to hide our goofs @ 2021-03-09 2:18 Sean Christopherson 2021-03-09 2:18 ` [PATCH 1/2] KVM: x86: Fixup "Get active PCID only when writing a CR3 value" Sean Christopherson 2021-03-09 2:19 ` [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation Sean Christopherson 0 siblings, 2 replies; 8+ messages in thread From: Sean Christopherson @ 2021-03-09 2:18 UTC (permalink / raw) To: Paolo Bonzini Cc: Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, linux-kernel, Tom Lendacky Please squash away our mistakes and hide them from the world. :-) Stuffed the MMIO generation to start at 0x3ffffffffffffff0 (bits 61:4 set) and role over into bit 62. Bit 63 is used for the "update in-progress" so I'm fairly confident there are no more collisions with other SPTE bits. For the PCID thing, note that there are two patches with the same changelog. Not sure what's intended there... Also, I forgot about adding the PAE root helpers until I tried testing and PAE didn't work with SME. I'll get those to you tomorrow. Sean Christopherson (2): KVM: x86: Fixup "Get active PCID only when writing a CR3 value" KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation arch/x86/kvm/mmu/spte.h | 12 +++++++----- arch/x86/kvm/svm/svm.c | 9 +++++++-- 2 files changed, 14 insertions(+), 7 deletions(-) -- 2.30.1.766.gb4fecdf3b7-goog ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] KVM: x86: Fixup "Get active PCID only when writing a CR3 value" 2021-03-09 2:18 [PATCH 0/2] Fixups to hide our goofs Sean Christopherson @ 2021-03-09 2:18 ` Sean Christopherson 2021-03-09 17:26 ` Sean Christopherson 2021-03-09 2:19 ` [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation Sean Christopherson 1 sibling, 1 reply; 8+ messages in thread From: Sean Christopherson @ 2021-03-09 2:18 UTC (permalink / raw) To: Paolo Bonzini Cc: Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, linux-kernel, Tom Lendacky From: Sean Christopherson <sean.j.christopherson@intel.com> Fix SME and PCID, which got horribly mangled on application. Fixes: a16241ae56fa ("KVM: x86: Get active PCID only when writing a CR3 value") Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/kvm/svm/svm.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 7876ddf896b8..271196400495 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3907,15 +3907,20 @@ static void svm_load_mmu_pgd(struct kvm_vcpu *vcpu, hpa_t root_hpa, struct vcpu_svm *svm = to_svm(vcpu); unsigned long cr3; - cr3 = __sme_set(root_hpa); if (npt_enabled) { - svm->vmcb->control.nested_cr3 = root_hpa; + svm->vmcb->control.nested_cr3 = __sme_set(root_hpa); vmcb_mark_dirty(svm->vmcb, VMCB_NPT); /* Loading L2's CR3 is handled by enter_svm_guest_mode. */ if (!test_bit(VCPU_EXREG_CR3, (ulong *)&vcpu->arch.regs_avail)) return; cr3 = vcpu->arch.cr3; + } else if (vcpu->arch.mmu->shadow_root_level >= PT64_ROOT_4LEVEL) { + cr3 = __sme_set(root_hpa) | kvm_get_active_pcid(vcpu); + } else { + /* PCID in the guest should be impossible with a 32-bit MMU. */ + WARN_ON_ONCE(kvm_get_active_pcid(vcpu)); + cr3 = root_hpa; } svm->vmcb->save.cr3 = cr3; -- 2.30.1.766.gb4fecdf3b7-goog ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] KVM: x86: Fixup "Get active PCID only when writing a CR3 value" 2021-03-09 2:18 ` [PATCH 1/2] KVM: x86: Fixup "Get active PCID only when writing a CR3 value" Sean Christopherson @ 2021-03-09 17:26 ` Sean Christopherson 0 siblings, 0 replies; 8+ messages in thread From: Sean Christopherson @ 2021-03-09 17:26 UTC (permalink / raw) To: Paolo Bonzini, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, linux-kernel, Tom Lendacky On Mon, Mar 08, 2021, Sean Christopherson wrote: > From: Sean Christopherson <sean.j.christopherson@intel.com> > > Fix SME and PCID, which got horribly mangled on application. Gah, the SME changes are supposed to be in "KVM: x86/mmu: Mark the PAE roots as decrypted for shadow paging", which has not yet been merged. Stuffing them here doesn't make things work, but it does break git blame. I'll send you a v2 with more appropriate fixup, and the PAE changes on top. > Fixes: a16241ae56fa ("KVM: x86: Get active PCID only when writing a CR3 value") > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/svm/svm.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 7876ddf896b8..271196400495 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -3907,15 +3907,20 @@ static void svm_load_mmu_pgd(struct kvm_vcpu *vcpu, hpa_t root_hpa, > struct vcpu_svm *svm = to_svm(vcpu); > unsigned long cr3; > > - cr3 = __sme_set(root_hpa); > if (npt_enabled) { > - svm->vmcb->control.nested_cr3 = root_hpa; > + svm->vmcb->control.nested_cr3 = __sme_set(root_hpa); > vmcb_mark_dirty(svm->vmcb, VMCB_NPT); > > /* Loading L2's CR3 is handled by enter_svm_guest_mode. */ > if (!test_bit(VCPU_EXREG_CR3, (ulong *)&vcpu->arch.regs_avail)) > return; > cr3 = vcpu->arch.cr3; > + } else if (vcpu->arch.mmu->shadow_root_level >= PT64_ROOT_4LEVEL) { > + cr3 = __sme_set(root_hpa) | kvm_get_active_pcid(vcpu); > + } else { > + /* PCID in the guest should be impossible with a 32-bit MMU. */ > + WARN_ON_ONCE(kvm_get_active_pcid(vcpu)); > + cr3 = root_hpa; > } > > svm->vmcb->save.cr3 = cr3; > -- > 2.30.1.766.gb4fecdf3b7-goog > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation 2021-03-09 2:18 [PATCH 0/2] Fixups to hide our goofs Sean Christopherson 2021-03-09 2:18 ` [PATCH 1/2] KVM: x86: Fixup "Get active PCID only when writing a CR3 value" Sean Christopherson @ 2021-03-09 2:19 ` Sean Christopherson 2021-03-09 10:09 ` Maxim Levitsky 2021-03-09 16:39 ` Tom Lendacky 1 sibling, 2 replies; 8+ messages in thread From: Sean Christopherson @ 2021-03-09 2:19 UTC (permalink / raw) To: Paolo Bonzini Cc: Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, linux-kernel, Tom Lendacky Drop bit 11, used for the MMU_PRESENT flag, from the set of bits used to store the generation number in MMIO SPTEs. MMIO SPTEs with bit 11 set, which occurs when userspace creates 128+ memslots in an address space, get false positives for is_shadow_present_spte(), which lead to a variety of fireworks, crashes KVM, and likely hangs the host kernel. Fixes: b14e28f37e9b ("KVM: x86/mmu: Use a dedicated bit to track shadow/MMU-present SPTEs") Reported-by: Tom Lendacky <thomas.lendacky@amd.com> Reported-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/kvm/mmu/spte.h | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h index b53036d9ddf3..bca0ba11cccf 100644 --- a/arch/x86/kvm/mmu/spte.h +++ b/arch/x86/kvm/mmu/spte.h @@ -101,11 +101,11 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); #undef SHADOW_ACC_TRACK_SAVED_MASK /* - * Due to limited space in PTEs, the MMIO generation is a 20 bit subset of + * Due to limited space in PTEs, the MMIO generation is a 19 bit subset of * the memslots generation and is derived as follows: * - * Bits 0-8 of the MMIO generation are propagated to spte bits 3-11 - * Bits 9-19 of the MMIO generation are propagated to spte bits 52-62 + * Bits 0-7 of the MMIO generation are propagated to spte bits 3-10 + * Bits 8-18 of the MMIO generation are propagated to spte bits 52-62 * * The KVM_MEMSLOT_GEN_UPDATE_IN_PROGRESS flag is intentionally not included in * the MMIO generation number, as doing so would require stealing a bit from @@ -116,7 +116,7 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); */ #define MMIO_SPTE_GEN_LOW_START 3 -#define MMIO_SPTE_GEN_LOW_END 11 +#define MMIO_SPTE_GEN_LOW_END 10 #define MMIO_SPTE_GEN_HIGH_START 52 #define MMIO_SPTE_GEN_HIGH_END 62 @@ -125,12 +125,14 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); MMIO_SPTE_GEN_LOW_START) #define MMIO_SPTE_GEN_HIGH_MASK GENMASK_ULL(MMIO_SPTE_GEN_HIGH_END, \ MMIO_SPTE_GEN_HIGH_START) +static_assert(!(SPTE_MMU_PRESENT_MASK & + (MMIO_SPTE_GEN_LOW_MASK | MMIO_SPTE_GEN_HIGH_MASK))); #define MMIO_SPTE_GEN_LOW_BITS (MMIO_SPTE_GEN_LOW_END - MMIO_SPTE_GEN_LOW_START + 1) #define MMIO_SPTE_GEN_HIGH_BITS (MMIO_SPTE_GEN_HIGH_END - MMIO_SPTE_GEN_HIGH_START + 1) /* remember to adjust the comment above as well if you change these */ -static_assert(MMIO_SPTE_GEN_LOW_BITS == 9 && MMIO_SPTE_GEN_HIGH_BITS == 11); +static_assert(MMIO_SPTE_GEN_LOW_BITS == 8 && MMIO_SPTE_GEN_HIGH_BITS == 11); #define MMIO_SPTE_GEN_LOW_SHIFT (MMIO_SPTE_GEN_LOW_START - 0) #define MMIO_SPTE_GEN_HIGH_SHIFT (MMIO_SPTE_GEN_HIGH_START - MMIO_SPTE_GEN_LOW_BITS) -- 2.30.1.766.gb4fecdf3b7-goog ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation 2021-03-09 2:19 ` [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation Sean Christopherson @ 2021-03-09 10:09 ` Maxim Levitsky 2021-03-09 13:12 ` Paolo Bonzini 2021-03-09 16:39 ` Tom Lendacky 1 sibling, 1 reply; 8+ messages in thread From: Maxim Levitsky @ 2021-03-09 10:09 UTC (permalink / raw) To: Sean Christopherson, Paolo Bonzini Cc: Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, linux-kernel, Tom Lendacky On Mon, 2021-03-08 at 18:19 -0800, Sean Christopherson wrote: > Drop bit 11, used for the MMU_PRESENT flag, from the set of bits used to > store the generation number in MMIO SPTEs. MMIO SPTEs with bit 11 set, > which occurs when userspace creates 128+ memslots in an address space, > get false positives for is_shadow_present_spte(), which lead to a variety > of fireworks, crashes KVM, and likely hangs the host kernel. > > Fixes: b14e28f37e9b ("KVM: x86/mmu: Use a dedicated bit to track shadow/MMU-present SPTEs") > Reported-by: Tom Lendacky <thomas.lendacky@amd.com> > Reported-by: Paolo Bonzini <pbonzini@redhat.com> > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/mmu/spte.h | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h > index b53036d9ddf3..bca0ba11cccf 100644 > --- a/arch/x86/kvm/mmu/spte.h > +++ b/arch/x86/kvm/mmu/spte.h > @@ -101,11 +101,11 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); > #undef SHADOW_ACC_TRACK_SAVED_MASK > > /* > - * Due to limited space in PTEs, the MMIO generation is a 20 bit subset of > + * Due to limited space in PTEs, the MMIO generation is a 19 bit subset of > * the memslots generation and is derived as follows: > * > - * Bits 0-8 of the MMIO generation are propagated to spte bits 3-11 > - * Bits 9-19 of the MMIO generation are propagated to spte bits 52-62 > + * Bits 0-7 of the MMIO generation are propagated to spte bits 3-10 > + * Bits 8-18 of the MMIO generation are propagated to spte bits 52-62 > * > * The KVM_MEMSLOT_GEN_UPDATE_IN_PROGRESS flag is intentionally not included in > * the MMIO generation number, as doing so would require stealing a bit from > @@ -116,7 +116,7 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); > */ > > #define MMIO_SPTE_GEN_LOW_START 3 > -#define MMIO_SPTE_GEN_LOW_END 11 > +#define MMIO_SPTE_GEN_LOW_END 10 > > #define MMIO_SPTE_GEN_HIGH_START 52 > #define MMIO_SPTE_GEN_HIGH_END 62 > @@ -125,12 +125,14 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); > MMIO_SPTE_GEN_LOW_START) > #define MMIO_SPTE_GEN_HIGH_MASK GENMASK_ULL(MMIO_SPTE_GEN_HIGH_END, \ > MMIO_SPTE_GEN_HIGH_START) > +static_assert(!(SPTE_MMU_PRESENT_MASK & > + (MMIO_SPTE_GEN_LOW_MASK | MMIO_SPTE_GEN_HIGH_MASK))); > > #define MMIO_SPTE_GEN_LOW_BITS (MMIO_SPTE_GEN_LOW_END - MMIO_SPTE_GEN_LOW_START + 1) > #define MMIO_SPTE_GEN_HIGH_BITS (MMIO_SPTE_GEN_HIGH_END - MMIO_SPTE_GEN_HIGH_START + 1) > > /* remember to adjust the comment above as well if you change these */ > -static_assert(MMIO_SPTE_GEN_LOW_BITS == 9 && MMIO_SPTE_GEN_HIGH_BITS == 11); > +static_assert(MMIO_SPTE_GEN_LOW_BITS == 8 && MMIO_SPTE_GEN_HIGH_BITS == 11); > > #define MMIO_SPTE_GEN_LOW_SHIFT (MMIO_SPTE_GEN_LOW_START - 0) > #define MMIO_SPTE_GEN_HIGH_SHIFT (MMIO_SPTE_GEN_HIGH_START - MMIO_SPTE_GEN_LOW_BITS) I bisected this and I reached the same conclusion that bit 11 has to be removed from mmio generation mask. Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> I do wonder, why do we need 19 (and now 18 bits) for the mmio generation: What happens if mmio generation overflows (e.g if userspace keeps on updating the memslots)? In theory if we have a SPTE with a stale generation, it can became valid, no? I think that we should in the case of the overflow zap all mmio sptes. What do you think? Best regards, Maxim Levitsky ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation 2021-03-09 10:09 ` Maxim Levitsky @ 2021-03-09 13:12 ` Paolo Bonzini 2021-03-09 13:31 ` Maxim Levitsky 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2021-03-09 13:12 UTC (permalink / raw) To: Maxim Levitsky, Sean Christopherson Cc: Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, linux-kernel, Tom Lendacky On 09/03/21 11:09, Maxim Levitsky wrote: > What happens if mmio generation overflows (e.g if userspace keeps on updating the memslots)? > In theory if we have a SPTE with a stale generation, it can became valid, no? > > I think that we should in the case of the overflow zap all mmio sptes. > What do you think? Zapping all MMIO SPTEs is done by updating the generation count. When it overflows, all SPs are zapped: /* * The very rare case: if the MMIO generation number has wrapped, * zap all shadow pages. */ if (unlikely(gen == 0)) { kvm_debug_ratelimited("kvm: zapping shadow pages for mmio generation wraparound\n"); kvm_mmu_zap_all_fast(kvm); } So giving it more bits make this more rare, at the same time having to remove one or two bits is not the end of the world. Paolo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation 2021-03-09 13:12 ` Paolo Bonzini @ 2021-03-09 13:31 ` Maxim Levitsky 0 siblings, 0 replies; 8+ messages in thread From: Maxim Levitsky @ 2021-03-09 13:31 UTC (permalink / raw) To: Paolo Bonzini, Sean Christopherson Cc: Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, linux-kernel, Tom Lendacky On Tue, 2021-03-09 at 14:12 +0100, Paolo Bonzini wrote: > On 09/03/21 11:09, Maxim Levitsky wrote: > > What happens if mmio generation overflows (e.g if userspace keeps on updating the memslots)? > > In theory if we have a SPTE with a stale generation, it can became valid, no? > > > > I think that we should in the case of the overflow zap all mmio sptes. > > What do you think? > > Zapping all MMIO SPTEs is done by updating the generation count. When > it overflows, all SPs are zapped: > > /* > * The very rare case: if the MMIO generation number has wrapped, > * zap all shadow pages. > */ > if (unlikely(gen == 0)) { > kvm_debug_ratelimited("kvm: zapping shadow pages for > mmio generation wraparound\n"); > kvm_mmu_zap_all_fast(kvm); > } > > So giving it more bits make this more rare, at the same time having to > remove one or two bits is not the end of the world. This is exactly what I expected to happen, I just didn't find that code. Thanks for explanation, and it shows that I didn't study the mmio spte code much. Best regards, Maxim Levitsky > > Paolo > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation 2021-03-09 2:19 ` [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation Sean Christopherson 2021-03-09 10:09 ` Maxim Levitsky @ 2021-03-09 16:39 ` Tom Lendacky 1 sibling, 0 replies; 8+ messages in thread From: Tom Lendacky @ 2021-03-09 16:39 UTC (permalink / raw) To: Sean Christopherson, Paolo Bonzini Cc: Vitaly Kuznetsov, Wanpeng Li, Jim Mattson, Joerg Roedel, kvm, linux-kernel On 3/8/21 8:19 PM, Sean Christopherson wrote: > Drop bit 11, used for the MMU_PRESENT flag, from the set of bits used to > store the generation number in MMIO SPTEs. MMIO SPTEs with bit 11 set, > which occurs when userspace creates 128+ memslots in an address space, > get false positives for is_shadow_present_spte(), which lead to a variety > of fireworks, crashes KVM, and likely hangs the host kernel. > > Fixes: b14e28f37e9b ("KVM: x86/mmu: Use a dedicated bit to track shadow/MMU-present SPTEs") > Reported-by: Tom Lendacky <thomas.lendacky@amd.com> Fixes the issue for me. Thanks, Sean. Tested-by: Tom Lendacky <thomas.lendacky@amd.com> > Reported-by: Paolo Bonzini <pbonzini@redhat.com> > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/mmu/spte.h | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h > index b53036d9ddf3..bca0ba11cccf 100644 > --- a/arch/x86/kvm/mmu/spte.h > +++ b/arch/x86/kvm/mmu/spte.h > @@ -101,11 +101,11 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); > #undef SHADOW_ACC_TRACK_SAVED_MASK > > /* > - * Due to limited space in PTEs, the MMIO generation is a 20 bit subset of > + * Due to limited space in PTEs, the MMIO generation is a 19 bit subset of > * the memslots generation and is derived as follows: > * > - * Bits 0-8 of the MMIO generation are propagated to spte bits 3-11 > - * Bits 9-19 of the MMIO generation are propagated to spte bits 52-62 > + * Bits 0-7 of the MMIO generation are propagated to spte bits 3-10 > + * Bits 8-18 of the MMIO generation are propagated to spte bits 52-62 > * > * The KVM_MEMSLOT_GEN_UPDATE_IN_PROGRESS flag is intentionally not included in > * the MMIO generation number, as doing so would require stealing a bit from > @@ -116,7 +116,7 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); > */ > > #define MMIO_SPTE_GEN_LOW_START 3 > -#define MMIO_SPTE_GEN_LOW_END 11 > +#define MMIO_SPTE_GEN_LOW_END 10 > > #define MMIO_SPTE_GEN_HIGH_START 52 > #define MMIO_SPTE_GEN_HIGH_END 62 > @@ -125,12 +125,14 @@ static_assert(!(EPT_SPTE_MMU_WRITABLE & SHADOW_ACC_TRACK_SAVED_MASK)); > MMIO_SPTE_GEN_LOW_START) > #define MMIO_SPTE_GEN_HIGH_MASK GENMASK_ULL(MMIO_SPTE_GEN_HIGH_END, \ > MMIO_SPTE_GEN_HIGH_START) > +static_assert(!(SPTE_MMU_PRESENT_MASK & > + (MMIO_SPTE_GEN_LOW_MASK | MMIO_SPTE_GEN_HIGH_MASK))); > > #define MMIO_SPTE_GEN_LOW_BITS (MMIO_SPTE_GEN_LOW_END - MMIO_SPTE_GEN_LOW_START + 1) > #define MMIO_SPTE_GEN_HIGH_BITS (MMIO_SPTE_GEN_HIGH_END - MMIO_SPTE_GEN_HIGH_START + 1) > > /* remember to adjust the comment above as well if you change these */ > -static_assert(MMIO_SPTE_GEN_LOW_BITS == 9 && MMIO_SPTE_GEN_HIGH_BITS == 11); > +static_assert(MMIO_SPTE_GEN_LOW_BITS == 8 && MMIO_SPTE_GEN_HIGH_BITS == 11); > > #define MMIO_SPTE_GEN_LOW_SHIFT (MMIO_SPTE_GEN_LOW_START - 0) > #define MMIO_SPTE_GEN_HIGH_SHIFT (MMIO_SPTE_GEN_HIGH_START - MMIO_SPTE_GEN_LOW_BITS) > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-03-09 17:27 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-09 2:18 [PATCH 0/2] Fixups to hide our goofs Sean Christopherson 2021-03-09 2:18 ` [PATCH 1/2] KVM: x86: Fixup "Get active PCID only when writing a CR3 value" Sean Christopherson 2021-03-09 17:26 ` Sean Christopherson 2021-03-09 2:19 ` [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation Sean Christopherson 2021-03-09 10:09 ` Maxim Levitsky 2021-03-09 13:12 ` Paolo Bonzini 2021-03-09 13:31 ` Maxim Levitsky 2021-03-09 16:39 ` Tom Lendacky
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).