Just ahead of the logic in question we've translated the subject MFN to
a valid original GFN, in order to then translate that GFN back to an
MFN. Restricting the call to p2m_remove_page() to the case where these
two MFNs match is too weak. Instead refuse the operation altogether when
there's a mismatch (which likely indicates a bug elsewhere in Xen), by
leveraging the checking in p2m_remove_entry() via passing in the
expected MFN.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
If we were certain that a mismatch indicates a bug elsewhere, we might
want to consider crashing the domain instead, to limit damage as well as
to make sure the issue is actually noticed.
---
v2: Drop the check rather than separating it out.

--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -719,8 +719,7 @@ p2m_add_page(struct domain *d, gfn_t gfn
                 ASSERT(mfn_valid(omfn));
                 P2M_DEBUG("old gfn=%#lx -> mfn %#lx\n",
                           gfn_x(ogfn) , mfn_x(omfn));
-                if ( mfn_eq(omfn, mfn_add(mfn, i)) &&
-                     (rc = p2m_remove_entry(p2m, ogfn, omfn, 0)) )
+                if ( (rc = p2m_remove_entry(p2m, ogfn, mfn_add(mfn, i), 0)) )
                     goto out;
             }
         }