[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: question about shadow_blow_tables
Thanks a lot for your clarification. Now I'm clear that current solution is safe. Actually in the start I also doubt my suspicion, since such hole is severe and unlikely nobody reports. So just post for your help on this part. :-) Thanks, Kevin >From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx] >Sent: 2007年11月27日 18:51 > >Hi, > >At 18:32 +0800 on 27 Nov (1196188342), Tian, Kevin wrote: >> Maybe I made some misunderstanding here. By comment of shadow_blow_ >> tables: >> /* Deliberately free all the memory we can: this will tear >down all of >> * this domain's shadows */ > >In this comment, "free" means only freeing as far as the >domain's shadow >free lists, not to domheap. Does that make more sense? > >> The implicit here is that all shadow pages of this domain >will be released >> as result. However when 'blow' is on-going on one cpu, the >'blow-ed' pages >> may be active on address translation on another cpu, if >other vcpus are >> not paused. I think anyway hardware should be prevented from walking >> shadow pages which are torn down from another cpu... > >As I said, it's safe to do this concurrently with other CPUs >reading the >shadow pagetables, and we have the shadow lock to protect against >concurrent writes. > >- other CPUs never see a half-written entry because of the logic in > safe_write_entry(). >- l1es in other CPUs' TLBs are safe to leave until the final TLB flush > because there's no intermediate stage mid-operation that >requires rights > to have been relinquished. >- higher-level entries in other CPUs' TLBs are safe because we >leave the > contents of the shadow pagetables they point at alone until >we're sure > all the TLBs are flushed. (We never write to pages on the >shadow free > list and we check the TLB flush timestamps when we allocate them > from the free list again.) > >Can you be clearer about what you think the risk is? If we've missed >something then it's quite important, because it probably affects every >other shadow operation as well. > >> So my question is, whether all shadow pages are indeed >free-ed as result >> of 'blow' option? > >Only as far as the free list. We never free shadow pages back to >domheap until the allocation is changed or shadow mode is >disabled. But >I think it would still be safe even if we freed to domheap because the >deferred-TLB-flush logic in page_alloc.c would do the right thing. > >> Or some IPI will be definitely triggered when free-ing one >> shadow page referenced by multiple VCPUs, before final TLB flush? > >No. We do no synchronisation until the TLB flush at the end. > >Cheers, > >Tim. > >-- >Tim Deegan <Tim.Deegan@xxxxxxxxxx> >Principal Software Engineer, Citrix Systems. >[Company #5334508: XenSource UK Ltd, reg'd c/o EC2Y 5EB, UK.] > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |