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 > Well, maybe resend patchset with bug fixes / improvements and > we go from there. I agree. Thanks for your time, Marcelo! -- 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
