From: Marcelo Tosatti <marcelo@kvack.org>
To: Andrea Arcangeli <andrea@qumranet.com>
Cc: Marcelo Tosatti <marcelo@kvack.org>,
kvm-devel@lists.sourceforge.net, Avi Kivity <avi@qumranet.com>
Subject: Re: [PATCH] KVM: MMU: Fix rmap_remove() race
Date: Wed, 26 Mar 2008 16:01:31 -0300 [thread overview]
Message-ID: <20080326190131.GA22963@dmt> (raw)
In-Reply-To: <20080326181225.GA11130@v2.random>
On Wed, Mar 26, 2008 at 07:12:25PM +0100, Andrea Arcangeli wrote:
> On Wed, Mar 26, 2008 at 02:51:28PM -0300, Marcelo Tosatti wrote:
> > Nope. If a physical CPU has page translations cached it _must_ be
> > running in the context of a qemu thread (does not matter if its in
> > userspace or executing guest code). The bit corresponding to such CPU's
> > will be set in mm->vm_cpu_mask and flush_tlb_page() will take care of
> > flushing the TLBs appropriately.
>
> That would require the tlb to lookup any SVM/VMX virtualized address
> that could point to the same physical page that is pointed by the
> invlpg linux virtual address. So it might be feasible if the hardware
> is using a physical tag on each spte translation, but it'd require the
> tlb to do a lot more work than we need it to do, so I hope you're
> wrong on the hardware side of things. That would be an hardware
> complexity or slowdown that would provide no benefit to software.
>
> But regardless, even if this was the case and you're right that
> invalidating a linux userland address invalidates atomically all other
> virtualized addresses in the svm/vmx tlbs (all asn included, not just
> one), the spte is still instantiated when flush_tlb_page runs on all
> cpus.
You're right, there is no guarantee that a full TLB flush will happen,
and invlpg for the qemu task virtual address is not enough.
> So just after the global tlb flush, a guest spte tlb-miss (no page
> fault required, no get_user_pages required) can happen that will
> re-instantiate the spte contents inside the tlb before flush_tlb_page
> returns.
>
> CPU0 CPU 1
> pte_clear() inside ptep_clear_flush
> flush_tlb_page inside ptep_clear_flush inside rmap
> page_count = 1
> guest tlb miss
> tlb entry is back!
> ioctl()
> mark spte nonpresent
> rmap_remove -> put_page
> tlb flush
>
> Any tlb flush happening before clearing the shadow-pte entry is
> totally useless.
>
> Avi patch is great fix, and it will need furtherx changes to properly
> fix this race, because many set_shadow_pte/and pt[i] = nonpresent, are
> executed _after_ rmap_remove (they must be executed first, in case the
> array is full and we have flush tlb and free the page).
One comment on the patch:
+static void kvm_release_page_clean_deferred(struct kvm *kvm,
+ struct page *page)
+{
+ kvm_release_page_deferred(kvm, page, true);
+}
false
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
next prev parent reply other threads:[~2008-03-26 19:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-26 15:02 [PATCH] KVM: MMU: Fix rmap_remove() race Avi Kivity
2008-03-26 15:15 ` Avi Kivity
2008-03-26 17:51 ` Marcelo Tosatti
2008-03-26 18:12 ` Andrea Arcangeli
2008-03-26 19:01 ` Marcelo Tosatti [this message]
2008-03-27 8:01 ` Avi Kivity
2008-03-26 19:22 ` Andrea Arcangeli
2008-03-26 19:27 ` Andrea Arcangeli
2008-03-27 8:06 ` Avi Kivity
2008-03-27 8:11 ` Avi Kivity
2008-03-27 13:52 ` Andrea Arcangeli
2008-03-27 13:56 ` Avi Kivity
2008-03-27 14:26 ` Andrea Arcangeli
2008-03-27 14:35 ` Avi Kivity
2008-03-27 14:50 ` Andrea Arcangeli
2008-03-27 14:56 ` Avi Kivity
2008-03-28 14:01 ` Andrea Arcangeli
2008-03-28 20:07 ` Andrea Arcangeli
2008-03-31 6:35 ` Avi Kivity
2008-03-31 9:25 ` Andrea Arcangeli
2008-03-27 15:26 ` Andi Kleen
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=20080326190131.GA22963@dmt \
--to=marcelo@kvack.org \
--cc=andrea@qumranet.com \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
/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.