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:36 +0100, Jan Beulich wrote:
> Oh, so really this is an optimization to allow the memory range to
> not remain unused altogether by "old" Xen, i.e. unlike the kexec
> range. 

Right. At the moment I just *don't* use the pages in the reserved
region (and that includes inittext/initdata freed by Xen, since the
plan is for new Xen to be placed where old Xen used to be in physical
memory).

From
https://xenbits.xen.org/gitweb/?p=people/dwmw2/xen.git;a=commitdiff;h=cdbef644824

void init_lu_reserved_pages(paddr_t ps, paddr_t pe)
{
    if (!lu_bootmem_start)
        init_xenheap_pages(ps, pe);

    /* There is ongoing work for other reasons to eliminate the use of
     * share_xen_page_with_guest() and get to a point where the normal
     * xenheap actually meets the requirement we need for live update
     * reserved memory, that nothing allocated from it will be mapped
     * to a guest and/or need to be preserved over a live update.
     * Until then, we simply don't use these pages after boot. */
}


> And of course this means you're intending to (at least
> partially) resurrect the distinction between domheap and xenheap,
> which isn't said anywhere in Paul's series, I don't think.

Right. Secret hiding makes the distinction (xenheap is mapped, domheap
is not) mostly go away. We are talking about restoring *a* distinction
between one type of page (Xen ephemeral pages which don't need to be
preserved over live update) and another (must be preserved), but
whether that should still be called "xenheap" vs. "domheap", despite
the massive parallels, isn't entirely clear.

>  If this
> is a sufficiently correct understanding of mine, then on one hand
> I start seeing the point of the conversion Paul wants to make, but
> otoh this then feels a little like making the 2nd step before the
> 1st.


What would you suggest is the first step?

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

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