From: Andrea Arcangeli <andrea@qumranet.com>
To: Marcelo Tosatti <marcelo@kvack.org>
Cc: kvm-devel@lists.sourceforge.net, Avi Kivity <avi@qumranet.com>
Subject: Re: [PATCH] KVM: MMU: Fix rmap_remove() race
Date: Wed, 26 Mar 2008 19:12:25 +0100 [thread overview]
Message-ID: <20080326181225.GA11130@v2.random> (raw)
In-Reply-To: <20080326175128.GA21800@dmt>
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. 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).
-------------------------------------------------------------------------
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 18:12 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 [this message]
2008-03-26 19:01 ` Marcelo Tosatti
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=20080326181225.GA11130@v2.random \
--to=andrea@qumranet.com \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=marcelo@kvack.org \
/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