Hi Wei, Yes, indeed. Before the teardown is implemented, even if I simply remove the first check, when I try to destroy the master domain, the domain will become a zombie, because the refcount of the shared pages won't be correctly decreased on slave destruction.
I don't know why this hasn't been done, so I'm separating this patch out to serve as a place to discuss this problem. For this GSoC project, I would also ask if there is any temporary workaround. While waiting for any further suggestions and answers, I'll continue to work on the ARM side. Cheers, Zhongze Liu 2017-08-04 21:27 GMT+08:00 Wei Liu <wei.l...@citrix.com>: > On Fri, Aug 04, 2017 at 10:20:24AM +0800, Zhongze Liu wrote: >> Two checks in the p2m code forbids sharing physical pages among DomU's by >> using >> xc_add_to_physmap_batch with XENMAPSPACE_gmfn_foreign. Just simply remove >> them >> in this RFC patch to ask for suggestions on how to properly handle this. >> >> This is for the proposal "Allow setting up shared memory areas between VMs >> from xl config file" (see [1]). >> >> [1] >> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html >> >> Signed-off-by: Zhongze Liu <blacksk...@gmail.com> >> --- >> Cc: George Dunlap <george.dun...@eu.citrix.com> >> Cc: Jan Beulich <jbeul...@suse.com> >> Cc: Andrew Cooper <andrew.coop...@citrix.com> >> Cc: Stefano Stabellini <sstabell...@kernel.org> >> Cc: Julien Grall <julien.gr...@arm.com> >> Cc: xen-devel@lists.xen.org >> --- >> xen/arch/x86/mm/p2m.c | 20 +++++++++++++++----- >> 1 file changed, 15 insertions(+), 5 deletions(-) >> >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c >> index e8a57d118c..3ee4c14ed4 100644 >> --- a/xen/arch/x86/mm/p2m.c >> +++ b/xen/arch/x86/mm/p2m.c >> @@ -2531,8 +2531,13 @@ int p2m_add_foreign(struct domain *tdom, unsigned >> long fgfn, >> * hvm fixme: until support is added to p2m teardown code to cleanup any >> * foreign entries, limit this to hardware domain only. > > This HVM fixme needs to be fixed before the check can go away. This is > going to be a non-trivial project, but it is going to be useful in its > own right. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
