On Thu, May 23, 2013 at 03:38:49PM +0800, Xiao Guangrong wrote:
> On 05/23/2013 03:37 PM, Xiao Guangrong wrote:
> > On 05/23/2013 03:24 PM, Gleb Natapov wrote:
> >> On Thu, May 23, 2013 at 02:26:57PM +0800, Xiao Guangrong wrote:
> >>> On 05/23/2013 02:12 PM, Gleb Natapov wrote:
> >>>> On Thu, May 23, 2013 at 03:55:59AM +0800, Xiao Guangrong wrote:
> >>>>> kvm_zap_obsolete_pages uses lock-break technique to zap pages,
> >>>>> it will flush tlb every time when it does lock-break
> >>>>>
> >>>>> We can reload mmu on all vcpus after updating the generation
> >>>>> number so that the obsolete pages are not used on any vcpus,
> >>>>> after that we do not need to flush tlb when obsolete pages
> >>>>> are zapped
> >>>>>
> >>>>> Note: kvm_mmu_commit_zap_page is still needed before free
> >>>>> the pages since other vcpus may be doing locklessly shadow
> >>>>> page walking
> >>>>>
> >>>> Since obsolete pages are not accessible for lockless page walking after
> >>>> reload of all roots I do not understand why additional tlb flush is
> >>>
> >>> kvm_reload_remote_mmus() forces vcpus to leave guest mode, but if the
> >>> vcpu is not running on guest mode, it does nothing except set the request
> >>> bit. So, the vcpu can go lockless page walking after kvm_reload_remote_mmus()
> >>> return on other vcpu.
> >>>
> >>> Like this scenario:
> >>>
> >>> VCPU 0 VCPU 1
> >>> exit when it encounters #PF
> >>>
> >>> kvm_reload_remote_mmus(){
> >>> set vcpu1->request bit;
> >>>
> >>> do not send IPI due to
> >>> vcpu 1 not running on guest mode
> >>>
> >>> call page-fault handler then go lockless walking !!!
> >>> return
> >>> }
> >>>
> >>>
> >>>> needed. Also why tlb flush should prevent lockless-walking from using
> >>>> the page? Making page unreachable from root_hpa does that, no?
> >>>
> >>> lockless-walking disables the interrupt and makes the vcpu state as
> >>> READING_SHADOW_PAGE_TABLES, this state is treated as GUEST_MODE,
> >>> kvm_flush_remote_tlbs() should send IPI to this vcpu in this case.
> >>
> >> kvm_flush_remote_tlbs() uses the same make_all_cpus_request() as
> >> kvm_reload_remote_mmus() does, so why the same scenario you describe
> >> above cannot happen with kvm_flush_remote_tlbs()?
> >
> >
> > After call kvm_flush_remote_tlbs(), the page still exists on vcpu->root,
>
> Sorry, should be kvm_reload_remote_mmus() here.
>
> > so we can not protect the page is being used by other vcpu.
> >
> > But before call kvm_mmu_commit_zap_page(), the page has been deleted from
> > vcpu's page table, after call kvm_flush_remote_tlbs(), we can ensure that
> > other vcpus can not find these pages.
> >
Ah, I see, so the barrier is needed after page is unlinked from the
vcpu->root hierarchy.
--
Gleb.
--
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
