[Xen-devel] Re: question about shadow_blow_tables

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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