Re: [PATCH 0/5] KVM: MMU: fast invalid all mmio sptes
Still reading, but sounds great if this works! I did not like the idea of mmio-rmap based approach so much, but this would be really/perfectly scalable. Thanks, Takuya On Fri, 15 Mar 2013 23:26:16 +0800 Xiao Guangrong wrote: > The current way is holding hot mmu-lock and walking all shadow pages, this > is not scale. This patchset tries to introduce a very simple and scale way > to fast invalid all mmio sptes - it need not walk any shadow pages and hold > any locks. > > The idea is simple: > KVM maintains a global mmio invalid generation-number which is stored in > kvm->arch.mmio_invalid_gen and every mmio spte stores the current global > generation-number into his available bits when it is created. > > When KVM need zap all mmio sptes, it just simply increase the global > generation-number. When guests do mmio access, KVM intercepts a MMIO #PF > then it walks the shadow page table and get the mmio spte. If the > generation-number on the spte does not equal the global generation-number, > it will go to the normal #PF handler to update the mmio spte. > > Since 19 bits are used to store generation-number on mmio spte, the > generation-number can be round after 33554432 times. It is large enough > for nearly all most cases, but making the code be more strong, we zap all > shadow pages when the number is round. > > Note: after my patchset that fast zap all shadow pages, kvm_mmu_zap_all is > not a problem any more. The scalability is the same as zap mmio shadow page > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Takuya Yoshikawa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] KVM: MMU: fast invalid all mmio sptes
The current way is holding hot mmu-lock and walking all shadow pages, this is not scale. This patchset tries to introduce a very simple and scale way to fast invalid all mmio sptes - it need not walk any shadow pages and hold any locks. The idea is simple: KVM maintains a global mmio invalid generation-number which is stored in kvm->arch.mmio_invalid_gen and every mmio spte stores the current global generation-number into his available bits when it is created. When KVM need zap all mmio sptes, it just simply increase the global generation-number. When guests do mmio access, KVM intercepts a MMIO #PF then it walks the shadow page table and get the mmio spte. If the generation-number on the spte does not equal the global generation-number, it will go to the normal #PF handler to update the mmio spte. Since 19 bits are used to store generation-number on mmio spte, the generation-number can be round after 33554432 times. It is large enough for nearly all most cases, but making the code be more strong, we zap all shadow pages when the number is round. Note: after my patchset that fast zap all shadow pages, kvm_mmu_zap_all is not a problem any more. The scalability is the same as zap mmio shadow page -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] KVM: MMU: fast invalid all mmio sptes
The current way is holding hot mmu-lock and walking all shadow pages, this is not scale. This patchset tries to introduce a very simple and scale way to fast invalid all mmio sptes - it need not walk any shadow pages and hold any locks. The idea is simple: KVM maintains a global mmio invalid generation-number which is stored in kvm-arch.mmio_invalid_gen and every mmio spte stores the current global generation-number into his available bits when it is created. When KVM need zap all mmio sptes, it just simply increase the global generation-number. When guests do mmio access, KVM intercepts a MMIO #PF then it walks the shadow page table and get the mmio spte. If the generation-number on the spte does not equal the global generation-number, it will go to the normal #PF handler to update the mmio spte. Since 19 bits are used to store generation-number on mmio spte, the generation-number can be round after 33554432 times. It is large enough for nearly all most cases, but making the code be more strong, we zap all shadow pages when the number is round. Note: after my patchset that fast zap all shadow pages, kvm_mmu_zap_all is not a problem any more. The scalability is the same as zap mmio shadow page -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] KVM: MMU: fast invalid all mmio sptes
Still reading, but sounds great if this works! I did not like the idea of mmio-rmap based approach so much, but this would be really/perfectly scalable. Thanks, Takuya On Fri, 15 Mar 2013 23:26:16 +0800 Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote: The current way is holding hot mmu-lock and walking all shadow pages, this is not scale. This patchset tries to introduce a very simple and scale way to fast invalid all mmio sptes - it need not walk any shadow pages and hold any locks. The idea is simple: KVM maintains a global mmio invalid generation-number which is stored in kvm-arch.mmio_invalid_gen and every mmio spte stores the current global generation-number into his available bits when it is created. When KVM need zap all mmio sptes, it just simply increase the global generation-number. When guests do mmio access, KVM intercepts a MMIO #PF then it walks the shadow page table and get the mmio spte. If the generation-number on the spte does not equal the global generation-number, it will go to the normal #PF handler to update the mmio spte. Since 19 bits are used to store generation-number on mmio spte, the generation-number can be round after 33554432 times. It is large enough for nearly all most cases, but making the code be more strong, we zap all shadow pages when the number is round. Note: after my patchset that fast zap all shadow pages, kvm_mmu_zap_all is not a problem any more. The scalability is the same as zap mmio shadow page -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Takuya Yoshikawa takuya.yoshik...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
