On 09/14/2009 08:03 AM, Avi Kivity wrote:
Right it will. But this does not stop the fault path from creating
shadow pages with stale sp->gfn (the only way to do that would be mutual
exclusion AFAICS).
So we put the kvm_mmu_zap_pages() call as part of the
synchronize_srcu() callback to take advantage of the srcu guarantees.
We know that when when the callback is called all new reads see the
new slots and all old readers have completed.
I think I see your concern - assigning sp->gfn leaks information out of
the srcu critical section.
Two ways out:
1) copy kvm->slots into sp->slots and use it when dropping the shadow
page. Intrusive and increases shadow footprint.
1b) Instead of sp->slots, use a 1-bit generation counter. Even uglier
but reduces the shadow footprint.
2) instead of removing the slot in rcu_assign_pointer(), mark it
invalid. gfn_to_page() will fail on such slots but the teardown paths
(like unaccount_shadow) continue to work. One we've zapped the mmu we
drop the slot completely (can do in place, no need to rcu_assign_pointer).
--
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