Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking

[Jan Beulich <jbeulich@suse.com>]

On 19.03.2021 12:06, Tamas K Lengyel wrote:
> On Fri, Mar 19, 2021, 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> On 18.03.2021 22:36, Tamas K Lengyel wrote:
>>> --- a/xen/arch/x86/mm/mem_sharing.c
>>> +++ b/xen/arch/x86/mm/mem_sharing.c
>>> @@ -1761,6 +1761,7 @@ static int copy_settings(struct domain *cd, struct
>> domain *d)
>>>          return rc;
>>>
>>>      copy_tsc(cd, d);
>>> +    p2m_get_hostp2m(cd)->max_mapped_pfn =
>> p2m_get_hostp2m(d)->max_mapped_pfn;
>>
>> Makes sense to me, yes, but then an immediate question is: What
>> about the somewhat similar {min,max}_remapped_gfn fields? Which
>> of course implies the more general question of how alternate
>> p2m-s (are supposed to) get treated in the first place. From my
>> looking at it, fork() doesn't appear to also fork those, but
>> also doesn't appear to refuse cloning when altp2m is in use.
>>
> 
> It's untested, forking and altp2m is not currently used simultaniously.
> Don't know if it should be restricted as not working as I haven't tested
> it. Both forking and altp2m is experimental so there be dragons. At some
> point I would like to be able to use altp2m in forks but forking a domain
> that has altp2m enabled will likely be a setup that's too insane to try to
> get working.

Well, I see only two (consistent) options - either the other two
fields mentioned get copied as well, or altp2m use results in
forking getting refused.

Jan