From: Avi Kivity <avi@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm <kvm@vger.kernel.org>, Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: KVM: MMU: always invalidate and flush on spte page size change
Date: Sun, 30 May 2010 13:28:19 +0300 [thread overview]
Message-ID: <4C023DC3.1090406@redhat.com> (raw)
In-Reply-To: <20100528124459.GA3734@amt.cnet>
On 05/28/2010 03:44 PM, Marcelo Tosatti wrote:
> Always invalidate spte and flush TLBs when changing page size, to make
> sure different sized translations for the same address are never cached
> in a CPU's TLB.
>
> The first case where this occurs is when a non-leaf spte pointer is
> overwritten by a leaf, large spte entry. This can happen after dirty
> logging is disabled on a memslot, for example.
>
> The second case is a leaf, large spte entry is overwritten with a
> non-leaf spte pointer, in __direct_map. Note this cannot happen now
> because the only potential source of such overwrite is dirty logging
> being enabled, which zaps all MMU pages. But this might change
> in the future, so better be robust against it.
>
> Noticed by Andrea.
>
> KVM-Stable-Tag
> Signed-off-by: Marcelo Tosatti<mtosatti@redhat.com>
>
> Index: kvm/arch/x86/kvm/mmu.c
> ===================================================================
> --- kvm.orig/arch/x86/kvm/mmu.c
> +++ kvm/arch/x86/kvm/mmu.c
> @@ -1952,6 +1952,8 @@ static void mmu_set_spte(struct kvm_vcpu
>
> child = page_header(pte& PT64_BASE_ADDR_MASK);
> mmu_page_remove_parent_pte(child, sptep);
> + __set_spte(sptep, shadow_trap_nonpresent_pte);
> + kvm_flush_remote_tlbs(vcpu->kvm);
> } else if (pfn != spte_to_pfn(*sptep)) {
> pgprintk("hfn old %lx new %lx\n",
> spte_to_pfn(*sptep), pfn);
>
Applied this bit.
> @@ -2015,6 +2017,16 @@ static int __direct_map(struct kvm_vcpu
> break;
> }
>
> + if (is_shadow_present_pte(*iterator.sptep)&&
> + !is_large_pte(*iterator.sptep))
> + continue;
> +
> + if (is_large_pte(*iterator.sptep)) {
> + rmap_remove(vcpu->kvm, iterator.sptep);
> + __set_spte(iterator.sptep, shadow_trap_nonpresent_pte);
> + kvm_flush_remote_tlbs(vcpu->kvm);
> + }
> +
>
Don't we have exactly the same issue in FNAME(fetch)()?
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-05-30 10:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-28 12:44 KVM: MMU: always invalidate and flush on spte page size change Marcelo Tosatti
2010-05-30 10:28 ` Avi Kivity [this message]
2010-05-30 15:19 ` Marcelo Tosatti
2010-05-31 11:49 ` Avi Kivity
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=4C023DC3.1090406@redhat.com \
--to=avi@redhat.com \
--cc=aarcange@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.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.