* [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking @ 2021-03-18 21:36 Tamas K Lengyel 2021-03-19 10:23 ` Jan Beulich ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Tamas K Lengyel @ 2021-03-18 21:36 UTC (permalink / raw) To: xen-devel Cc: Tamas K Lengyel, Tamas K Lengyel, Jan Beulich, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value. Some toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum addressable physical memory in the VM and for forks that have not yet been unpaused that value is not going to reflect the correct max gpfn that's possible to populate into the p2m. This patch fixes the issue. Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com> --- xen/arch/x86/mm/mem_sharing.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c index 00ada05c10..98b14f7b0a 100644 --- 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; return rc; } -- 2.25.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-18 21:36 [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking Tamas K Lengyel @ 2021-03-19 10:23 ` Jan Beulich 2021-03-19 11:06 ` Tamas K Lengyel 2021-03-19 12:31 ` Tamas K Lengyel 2021-03-26 15:04 ` Andrew Cooper 2 siblings, 1 reply; 11+ messages in thread From: Jan Beulich @ 2021-03-19 10:23 UTC (permalink / raw) To: Tamas K Lengyel Cc: Tamas K Lengyel, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu, xen-devel 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. Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-19 10:23 ` Jan Beulich @ 2021-03-19 11:06 ` Tamas K Lengyel 2021-03-19 11:25 ` Jan Beulich 0 siblings, 1 reply; 11+ messages in thread From: Tamas K Lengyel @ 2021-03-19 11:06 UTC (permalink / raw) To: Jan Beulich Cc: Tamas K Lengyel, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu, Xen-devel [-- Attachment #1: Type: text/plain, Size: 1207 bytes --] 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. Tamas > [-- Attachment #2: Type: text/html, Size: 1844 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-19 11:06 ` Tamas K Lengyel @ 2021-03-19 11:25 ` Jan Beulich 2021-03-19 12:17 ` Tamas K Lengyel 0 siblings, 1 reply; 11+ messages in thread From: Jan Beulich @ 2021-03-19 11:25 UTC (permalink / raw) To: Tamas K Lengyel Cc: Tamas K Lengyel, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu, Xen-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-19 11:25 ` Jan Beulich @ 2021-03-19 12:17 ` Tamas K Lengyel 0 siblings, 0 replies; 11+ messages in thread From: Tamas K Lengyel @ 2021-03-19 12:17 UTC (permalink / raw) To: Jan Beulich Cc: Tamas K Lengyel, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu, Xen-devel On Fri, Mar 19, 2021 at 7:25 AM Jan Beulich <jbeulich@suse.com> wrote: > > 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. 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-18 21:36 [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking Tamas K Lengyel 2021-03-19 10:23 ` Jan Beulich @ 2021-03-19 12:31 ` Tamas K Lengyel 2021-03-24 11:42 ` Tamas K Lengyel 2021-03-26 11:36 ` Ian Jackson 2021-03-26 15:04 ` Andrew Cooper 2 siblings, 2 replies; 11+ messages in thread From: Tamas K Lengyel @ 2021-03-19 12:31 UTC (permalink / raw) To: Tamas K Lengyel Cc: Xen-devel, Jan Beulich, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu, Ian Jackson On Thu, Mar 18, 2021 at 5:36 PM Tamas K Lengyel <tamas.lengyel@intel.com> wrote: > > When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value. Some > toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum > addressable physical memory in the VM and for forks that have not yet been > unpaused that value is not going to reflect the correct max gpfn that's > possible to populate into the p2m. This patch fixes the issue. > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com> > --- > xen/arch/x86/mm/mem_sharing.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c > index 00ada05c10..98b14f7b0a 100644 > --- 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; > > return rc; > } > -- > 2.25.1 > CC-ing Ian as 4.15 release manager. This patch is safe to include in 4.15 as it's a minor fix in a tech preview feature that's not even compiled by default. Thanks, Tamas ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-19 12:31 ` Tamas K Lengyel @ 2021-03-24 11:42 ` Tamas K Lengyel 2021-03-26 11:36 ` Ian Jackson 1 sibling, 0 replies; 11+ messages in thread From: Tamas K Lengyel @ 2021-03-24 11:42 UTC (permalink / raw) To: Ian Jackson Cc: Xen-devel, Tamas K Lengyel, Jan Beulich, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu > > When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value. Some > > toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum > > addressable physical memory in the VM and for forks that have not yet been > > unpaused that value is not going to reflect the correct max gpfn that's > > possible to populate into the p2m. This patch fixes the issue. > > > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com> > > --- > > xen/arch/x86/mm/mem_sharing.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c > > index 00ada05c10..98b14f7b0a 100644 > > --- 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; > > > > return rc; > > } > > -- > > 2.25.1 > > > > CC-ing Ian as 4.15 release manager. This patch is safe to include in > 4.15 as it's a minor fix in a tech preview feature that's not even > compiled by default. Patch ping just to not forget that I would like this included in the 4.15 release. Thanks, Tamas ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-19 12:31 ` Tamas K Lengyel 2021-03-24 11:42 ` Tamas K Lengyel @ 2021-03-26 11:36 ` Ian Jackson 2021-03-26 12:14 ` Tamas K Lengyel 1 sibling, 1 reply; 11+ messages in thread From: Ian Jackson @ 2021-03-26 11:36 UTC (permalink / raw) To: Tamas K Lengyel Cc: Tamas K Lengyel, Xen-devel, Jan Beulich, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu Tamas K Lengyel writes ("Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking"): > On Thu, Mar 18, 2021 at 5:36 PM Tamas K Lengyel <tamas.lengyel@intel.com> wrote: > > > > When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value. Some > > toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum > > addressable physical memory in the VM and for forks that have not yet been > > unpaused that value is not going to reflect the correct max gpfn that's > > possible to populate into the p2m. This patch fixes the issue. ... > CC-ing Ian as 4.15 release manager. This patch is safe to include in > 4.15 as it's a minor fix in a tech preview feature that's not even > compiled by default. As far as I can tell this patch is lacking a maintainer review ? Release-Acked-by: Ian Jackson <iwj@xenproject.org> *Provided that it is committed today* I'm not sure how likely that is. Thanks, Ian. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-26 11:36 ` Ian Jackson @ 2021-03-26 12:14 ` Tamas K Lengyel 2021-03-26 12:31 ` Ian Jackson 0 siblings, 1 reply; 11+ messages in thread From: Tamas K Lengyel @ 2021-03-26 12:14 UTC (permalink / raw) To: Ian Jackson Cc: Tamas K Lengyel, Xen-devel, Jan Beulich, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu On Fri, Mar 26, 2021 at 7:37 AM Ian Jackson <iwj@xenproject.org> wrote: > > Tamas K Lengyel writes ("Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking"): > > On Thu, Mar 18, 2021 at 5:36 PM Tamas K Lengyel <tamas.lengyel@intel.com> wrote: > > > > > > When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value. Some > > > toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum > > > addressable physical memory in the VM and for forks that have not yet been > > > unpaused that value is not going to reflect the correct max gpfn that's > > > possible to populate into the p2m. This patch fixes the issue. > ... > > CC-ing Ian as 4.15 release manager. This patch is safe to include in > > 4.15 as it's a minor fix in a tech preview feature that's not even > > compiled by default. > > As far as I can tell this patch is lacking a maintainer review ? > > Release-Acked-by: Ian Jackson <iwj@xenproject.org> > > *Provided that it is committed today* I'm not sure how likely that is. Thanks, as I'm the sole maintainer of the code AFAIU it just needs a Reviewed-by from someone in the community. Tamas ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-26 12:14 ` Tamas K Lengyel @ 2021-03-26 12:31 ` Ian Jackson 0 siblings, 0 replies; 11+ messages in thread From: Ian Jackson @ 2021-03-26 12:31 UTC (permalink / raw) To: Tamas K Lengyel Cc: Tamas K Lengyel, Xen-devel, Jan Beulich, Andrew Cooper, George Dunlap, Roger Pau Monné, Wei Liu Tamas K Lengyel writes ("Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking"): > On Fri, Mar 26, 2021 at 7:37 AM Ian Jackson <iwj@xenproject.org> wrote: > > Release-Acked-by: Ian Jackson <iwj@xenproject.org> > > > > *Provided that it is committed today* I'm not sure how likely that is. > > Thanks, as I'm the sole maintainer of the code AFAIU it just needs a > Reviewed-by from someone in the community. I don't feel qualified myself, unfortunately. But your argument in favour of having this in 4.15 seems very strong to me so I definitely hope someone is able to do the review. Ian. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking 2021-03-18 21:36 [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking Tamas K Lengyel 2021-03-19 10:23 ` Jan Beulich 2021-03-19 12:31 ` Tamas K Lengyel @ 2021-03-26 15:04 ` Andrew Cooper 2 siblings, 0 replies; 11+ messages in thread From: Andrew Cooper @ 2021-03-26 15:04 UTC (permalink / raw) To: Tamas K Lengyel, xen-devel Cc: Tamas K Lengyel, Jan Beulich, George Dunlap, Roger Pau Monné, Wei Liu On 18/03/2021 21:36, Tamas K Lengyel wrote: > When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value. Some > toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum > addressable physical memory in the VM and for forks that have not yet been > unpaused that value is not going to reflect the correct max gpfn that's > possible to populate into the p2m. This patch fixes the issue. > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-03-26 15:04 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-18 21:36 [PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking Tamas K Lengyel 2021-03-19 10:23 ` Jan Beulich 2021-03-19 11:06 ` Tamas K Lengyel 2021-03-19 11:25 ` Jan Beulich 2021-03-19 12:17 ` Tamas K Lengyel 2021-03-19 12:31 ` Tamas K Lengyel 2021-03-24 11:42 ` Tamas K Lengyel 2021-03-26 11:36 ` Ian Jackson 2021-03-26 12:14 ` Tamas K Lengyel 2021-03-26 12:31 ` Ian Jackson 2021-03-26 15:04 ` Andrew Cooper
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).