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

[Xen-devel] Re: question about shadow_blow_tables



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.

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

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