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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.03.2020 13:37, David Woodhouse wrote:
> On Fri, 2020-03-06 at 13:25 +0100, Jan Beulich wrote:
>> And likely interrupt remapping tables, device tables, etc. I don't
>> have a clear picture on how you want to delineate ones in use in any
>> such way from ones indeed free to re-use.
> 
> Right. The solution there is two-fold:
> 
> For pages in the general population (outside the reserved bootmem), the
> responsibility lies with the new Xen. As it processes the live update
> information that it receives from the old Xen, it must mark those pages
> as in-use so that it doesn't attempt to allocate them.
> 
> That's what this bugfix paves the way for — it avoids putting *bad*
> pages into the buddy allocator, by setting the page state before the
> page is seen by init_heap_pages(), and making init_heap_pages() skip
> the pages marked as broken.
> 
> It's trivial, then, to make init_heap_pages() *also* skip pages which
> get marked as "already in use" when we process the live update data.
> 
> 
> The second part, as discussed, is that the old Xen must not put any of
> those "needs to be preserved" pages into the reserved bootmem region.
> 
> That's what Paul is working on. We stop sharing xenheap pages to
> domains, which is part of it — but *also* we need to use the right
> allocation for any IOMMU page tables and IRQ remapping tables which
> need to be preserved, etc. 

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.

Jan

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