[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: question about shadow_blow_tables


  • To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 27 Nov 2007 18:32:22 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 27 Nov 2007 02:33:21 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acgw3CR8yiMjdpDhRW+qJZUI3zlbVwAAwlyA
  • Thread-topic: question about shadow_blow_tables

>From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx] 
>Sent: 2007年11月27日 17:58
>
>Hi, 
>
>At 10:49 +0800 on 27 Nov (1196160559), Tian, Kevin wrote:
>> I remembered that some portion of shadow table is per-domain 
>property,
>> which is why a domain shadow lock is used.
>
>I'm not sure what you mean.  The shadow lock is used to stop concurrent
>updates to a domain's shadow pagetable state from different CPUs.

I meant same to you, that some shadow entry is domain-wise and shared 
on multiple vcpus.

>
>> Then at shadow_blow_tables, should target domain be paused before
>> blowing all tables in case some entries are still in use in guest
>> context on other cpus for a SMP guest. Or some delay unhook mechanism
>> is used to check above condition?
>
>No, we just unhook them.  Updates to shadow pagetables are safe against
>concurrent *reads* because we're careful about the ordering of writes
>on PAE entries and writes are atomic on non-pae and 64-bit.

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 */

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...

So my question is, whether all shadow pages are indeed free-ed as result
of 'blow' option? Or some IPI will be definitely triggered when free-ing one
shadow page referenced by multiple VCPUs, before final TLB flush?


Thanks,
Kevin

>
>Of course, other CPUs might have the old contents of the shadow
>pagetables in their TLBs.  This is safe because we don't overwrite old
>shadow pagetables until TLBs have been flushed (see shadow_alloc()) and
>we flush all the TLBs at the bottom of shadow_blow_tables().
>
>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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.