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?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel