|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] RE: 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
|
|
|
|
|