Re: [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

From: Tim Deegan <tim@xen.org>
To: Ed White <edmund.h.white@intel.com>
Cc: keir@xen.org, ian.campbell@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com
Subject: Re: [PATCH 00/11] Alternate p2m: support multiple copies of host p2m
Date: Thu, 22 Jan 2015 16:42:07 +0100	[thread overview]
Message-ID: <20150122154207.GO97314@deinos.phlegethon.org> (raw)
In-Reply-To: <54BD7D06.2000506@intel.com>

At 13:54 -0800 on 19 Jan (1421672054), Ed White wrote:
> > Or: declare in the interface that the altp2ms are soft state that can
> > be dropped on migration, with some suitable callback (#VE injection?)
> > to the guest when an altp2m 'view' is not available.  That depends on
> > whether the in-guest agent can reconstruct the state it needs from
> > scratch.
> > 
> 
> I've been wondering about this too, although it's not something the
> existing software that we want to enable on Xen has to cope with.
> 
> I still don't understand under what circumstances a machine page
> can be removed from a guest, especially given that we are only
> going to use remapping when we are actively using both copies of
> the page.

The guest itself can choose to relinquish a page (e.g. for
ballooning), or any privileged tool can remove one.  From the
hypervisor's point of view, we need to do the right (i.e. safe) thing
when this happens, even if it's a strange/pointless thing to happen.

Log-dirty has a similar issue wrt remappings -- we need to make sure
that all remapped entries in altp2ms get reset to read-only or we
might miss a write. 

> However, if such a page can be removed, the agent
> (in-domain or out-of-domain) has to be able to know about that
> and handle it. There's also the issue that access permissions
> are soft state and can be reverted to default in certain cases.
> 
> Maybe the solution to all of this is a mechanism by which the
> agent can be notified that some of its modifications have been
> invalidated, so it can rebuild state as appropriate.
> 
> We could then add a piece of state to an alternate p2m to indicate
> that it contains remapped gfn->mfn translations, and invalidate
> the entire p2m if any mfn is removed from the guest.

Yep.  That would be safe, but potentially slow -- heading towards the
flush-everything model that nested-p2m uses.  It would be nice to be
able to just invalidate the relevant entries, if we can keep enough
state to find them.

> Migration could invalidate everything.

Yep.  That certainly sounds a lot easier than trying to transport all
that state to a new machine!

Cheers,

Tim.