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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Fri, Mar 19, 2021 at 7:25 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 19.03.2021 12:06, Tamas K Lengyel wrote:
> > On Fri, Mar 19, 2021, 6:23 AM Jan Beulich <jbeulich@xxxxxxxx> 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.

Sure, but that's a separate issue from what this patch addresses so at
this point I don't plan on including that work in here.

Tamas