From: Paolo Bonzini <pbonzini@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>,
Sean Christopherson <seanjc@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH 2/2] KVM: x86/mmu: Exclude the MMU_PRESENT bit from MMIO SPTE's generation
Date: Tue, 9 Mar 2021 14:12:26 +0100 [thread overview]
Message-ID: <d72993d9-c11c-a5f4-0452-b2bed730938c@redhat.com> (raw)
In-Reply-To: <785c17c307e66b9d7b422cc577499d284cfb6e7b.camel@redhat.com>
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
next prev parent reply other threads:[~2021-03-09 13:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2021-03-09 13:31 ` Maxim Levitsky
2021-03-09 16:39 ` Tom Lendacky
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=d72993d9-c11c-a5f4-0452-b2bed730938c@redhat.com \
--to=pbonzini@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.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 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).