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

["Woodhouse, David" <dwmw@xxxxxxxxxxxx>]

On Wed, 2020-02-26 at 16:12 +0000, Julien Grall wrote:
> (+David)
> 
> On 26/02/2020 15:23, Jan Beulich wrote:
> > On 26.02.2020 15:05, Durrant, Paul wrote:
> > > > From: Jan Beulich <jbeulich@xxxxxxxx>
> > > > Sent: 26 February 2020 13:58
> > > > 
> > > > On 25.02.2020 10:53, Paul Durrant wrote:
> > > > > There's no particular reason shared_info need use a xenheap page. It's
> > > > > only purpose is to be mapped by the guest so use a PGC_extra domheap
> > > > 
> > > > page
> > > > > instead.
> > > > 
> > > > Since the cover letter also doesn't give any background - is there a
> > > > problem with the current arrangements? Are there any further plans
> > > > depending on this being changed? Or is this simply "let's do it
> > > > because now we can"?
> > > > 
> > > 
> > > The general direction is to get rid of shared xenheap pages. Knowing
> > > that a xenheap page is not shared with a guest makes dealing with
> > > live update much easier,
> > 
> > I may not be seeing enough of the overall picture, but it would seem
> > to me that the special treatment of shared Xen heap pages would then
> > be replaced by special treatment of PGC_extra ones.
> 
> I have been working on Liveupdate for the past couple months and I don't 
>   really see how this is going to make liveupdate easier. We will still 
> need to save the extra flags and extra records for each subsystem using 
> them (e.g grant-tables).
> 
> I have CCed David to see if he has a different opinion.

For live update we need to give a region of memory to the new Xen which
it can use for its boot allocator, before it's handled any of the live
update records and before it knows which *other* memory is still
available for use.

In order to do that, the original Xen has to ensure that it *doesn't*
use any of that memory region for domain-owned pages which would need
to be preserved.

So far in the patches I've posted upstream I have cheated, and simply
*not* added them to the main heap. Anything allocated before
end_boot_allocator() is fine because it is "ephemeral" to the first Xen
and doesn't need to be preserved (it's mostly frame tables and a few
PTE pages).

Paul's work is making it possible to use those pages as xenheap pages,
safe in the knowledge that they *won't* end up being mapped to domains,
and won't need to be preserved across live update.





Amazon Development Centre (London) Ltd. Registered in England and Wales with 
registration number 04543232 with its registered office at 1 Principal Place, 
Worship Street, London EC2A 2FA, United Kingdom.


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