On 04/24/2012 12:24 PM, Avi Kivity wrote: > On 04/24/2012 04:17 AM, Marcelo Tosatti wrote: > > On Mon, Apr 23, 2012 at 07:16:52PM +0300, Avi Kivity wrote: > > > Using RCU for lockless shadow walking can increase the amount of memory > > > in use by the system, since RCU grace periods are unpredictable. We also > > > have an unconditional write to a shared variable (reader_counter), which > > > isn't good for scaling. > > > > > > Replace that with a scheme similar to x86's get_user_pages_fast(): disable > > > interrupts during lockless shadow walk to force the freer > > > (kvm_mmu_commit_zap_page()) to wait for the TLB flush IPI to find the > > > processor with interrupts enabled. > > > > > > We also add a new vcpu->mode, READING_SHADOW_PAGE_TABLES, to prevent > > > kvm_flush_remote_tlbs() from avoiding the IPI. > > > > > > > Should add an explicit mb after prepare_zap_page? (currently rely on > > unrelated ones internal to flush_remote_tlbs). > > Yes. Is that really true? If unlocked shadow walk doesn't see the changes by prepare_zap_page(), it will still see valid sptes that will not be reused (blocked by kvm_flush_remote_tlbs()). If it does see the changes, it won't access those sptes at all. Either way we're fine. -- 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
