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

[Ed White <edmund.h.white@xxxxxxxxx>]

On 01/22/2015 07:42 AM, Tim Deegan wrote:
> 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!

IMO, invalidating an entire altp2m seems like the right level of
granularity to expect the agent to handle, in which case it will
be possible to fine-tune the algorithm that determines when to
invalidate without changing the notification interface.

My thought is to start by tracking the upper and lower bound of
modified mfn's (modified in any way) in a p2m, and see how
effective that is. If it's good enough in a non-pathological
case, why do something more complex?

Changing tack somewhat, in the short term I intend to submit
the p2m class tracking changes (patch 4 in the series) as a
standalone patch, combining your suggestions and Andrew's, as
that doesn't seem to be controversial and lays the groundwork
for altp2m. If I think I can do it without treading on toes
inside Intel, I might change p2m_write_entry() and submit a
standalone patch for that too.

Then I'll probably disappear for a while. I completely
understand that you can't accept these changes without the
ability to test them automatically, but I don't have an answer
as to how I can provide test code. I'll return once I've
figured that out.

Ed


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel