Re: [PATCH v2] x86/hvm: be more strict with XENMAPSPACE_gmfn source types

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.01.2026 21:32, Roger Pau Monne wrote:
> XENMAPSPACE_gmfn{_range} allows moving gfn around the guest p2m: the mfn
> behind the source gfn is zapped from the origin and mapped at the
> requested destination gfn.  The destination p2m entries are always created
> with type p2m_ram_rw.
> 
> With the current checking done in xenmem_add_to_physmap_one() it's possible
> to use XENMAPSPACE_gmfn{_range} to change the type of a p2m entry.  The
> source gfn is only checked to be not shared, and that the underlying page
> is owned by the domain.
> 
> Make the source checks more strict, by checking that the source gfn is of
> type read/write RAM or logdirty.  That prevents the operation from
> inadvertently changing the type as part of the move.
> 
> Fixes: 3e50af3d8776 ('New XENMAPSPACE_gmfn parameter for 
> XENMEM_add_to_physmap.')
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> Changes since v1:
>  - Also handle logdirty types.
>  - Return -ENOMEM on failure to unshare.
> ---
>  xen/arch/x86/mm/p2m.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)

Since this is now ready to go in, the question of backporting arises. You
explicitly wanted the change here to only go in on top of what is now
98fccdf0ac7c ("x86/mm: update log-dirty bitmap when manipulating P2M"). I
wouldn't have considered that for backporting, but I guess for these two
it can only be both, neither, or said earlier commit shrunk to the minimum
required for the change here. Thoughts on which route to take?

Jan