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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.02.2020 17:53, Woodhouse, David wrote:
> 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.

I've started looking at the latest version of Paul's series, but I'm
still struggling to see the picture: There's no true distinction
between Xen heap and domain heap on x86-64 (except on very large
systems). Therefore it is unclear to me what "those pages" is actually
referring to above. Surely new Xen can't be given any pages in use
_in any way_ by old Xen, no matter whether it's ones assigned to
domains, or ones used internally to (old) Xen.

Jan

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