Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Fri, 2020-03-06 at 13:55 +0100, Jan Beulich wrote:
> I'm sorry, but this doesn't really make things much more clear.
> Further up you say "As it processes the live update information
> ...", i.e. that's a case where you get positive indication that a
> page is in use. You also have that reserved region, where old Xen
> promises to not put anything that needs to survive. (It remains
> unclear what exact form and shape this is meant to take, as I
> hope you don't mean to re-introduce a Xen heap with static
> boundaries, entirely distinct from the domain heap.) But the
> situation for all other pages remains rather nebulous to me. Yet
> by a certain point in time new Xen will want to take control of
> all memory, i.e. know of the used (or not) status of all pages
> in the system.

In terms of the design discussion for live update, I don't know that
"xenheap" and "domheap" are the right terms to use as they have a
loaded existing meaning (albeit one which is being blurred a lot as the
secret hiding happens).

Let's say "ephemeral pages" and "preserved pages".

If Xen needs to allocate a page which needs to be preserved over live
update, then it can only come from *outside* the reserved bootmem
region.

If Xen needs to allocate an ephemeral page (which can be thrown away on
live update), that can come from *anywhere*. But we might *start* by
looking in the reserved region, and then allocate from the general
population of memory after the reserved region has been used up.

Obviously, the *usage* of this maps fairly closely to the existing
xenheap and domheap. But we wouldn't end up with a hard partition
between 'xenheap' and 'domheap' as we have had on some architectures
before. We'd satisfy xenheap allocations *first* from the xenheap-only
reserved ranges, and then from the rest of memory (domheap).

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel