WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: question about shadow_blow_tables

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
Subject: [Xen-devel] RE: question about shadow_blow_tables
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071127095827.GA17453@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <D470B4E54465E3469E2ABBC5AFAC390F024D8C92@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20071127095827.GA17453@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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