[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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.

Tamas

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.