On Tue, Mar 19, 2013 at 11:37:38PM +0800, Xiao Guangrong wrote: > On 03/19/2013 10:40 PM, Marcelo Tosatti wrote: > > > > > I misunderstood the benefit of your idea (now i got it: zap root > > and flush TLB guarantees vcpus will refault). What i'd like to avoid is > > > > memset(cache, 0, sizeof(*cache)); > > kvm_mmu_init(kvm); > > > > I'd prefer normal operations on those data structures (in mmu_cache). > > And also the page accounting is a problem. > > > > Perhaps you can use a generation number to consider whether shadow pages > > are valid? So: > > > > find_sp(gfn_t gfn) > > lookup hash > > if sp->generation_number != mmu->current_generation_number > > initialize page as if it were just allocated (but keep it in the hash list) > > > > And on kvm_mmu_zap_all() > > spin_lock(mmu_lock) > > for each page > > if page->root_count > > zero sp->spt[] > > > > flush TLB > > mmu->current_generation_number++ > > spin_unlock(mmu_lock) > > > > Then have kvm_mmu_free_all() that actually frees all data. > > > > Hum, not sure if thats any better than your current patchset. > > I also got the idea of generation number like yours which i mentioned > it in the [PATCH 0/6]: > > * TODO > Avoiding Marcelo beat me :), they are some works not attached to make the > patchset more smaller: > (1): batch kvm_reload_remote_mmus for zapping root shadow pages > (2): free shadow pages by using generation-number > (3): remove unneeded kvm_reload_remote_mmus after kvm_mmu_zap_all > (4): drop unnecessary @npages from kvm_arch_create_memslot > (5): rename init_kvm_mmu to init_vcpu_mmu Long patch sets are OK. Problem are unrelated changes in a patchset. -- 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
