Andrea Arcangeli wrote:
From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
While looking at invlpg out of sync code with Izik I think I noticed a
missing smp tlb flush here. Without this the other cpu can still write
to a freed host physical page. tlb smp flush must happen if
rmap_remove is called always before mmu_lock is released because the
VM will take the mmu_lock before it can finally add the page to the
freelist after swapout. mmu notifier makes it safe to flush the tlb
after freeing the page (otherwise it would never be safe) so we can do
a single flush for multiple sptes invalidated.
Izik pointed out that for invlpg, the guest is responsible for smp tlb
flushes, and mmu notifiers will protect against pageout.
We still have a couple of holes, though, with the current code:
- tlb loaded with an entry
- guest invlpg
- invlpg code drops the spte and rmap entry
- pageout
- mmu notifiers don't find an rmap entry, so tlb is not flushed
The second hole is much simpler, we need a local invlpg at least. This
doesn't show up on Intel since a vmexit will flush the entire tlb (and
most AMDs have NPT by now).
I think we can fix this without taking the hit of the IPI by
- running a local invlpg()
- making need_flush a vm flag instead of a local
- clearing need_flush whenever remote tlbs are flushed
- flushing remote tlbs on an mmu_notifier call when need_flush is set
Since mmu notifier calls are rare, this would collapse many remote tlb
flushes into one.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
