On 15.12.2025 15:17, Jan Beulich wrote:
> On 15.12.2025 13:46, Andrew Cooper wrote:
>> On 15/12/2025 11:22 am, Jan Beulich wrote:
>>> Overlapping requests may need processing backwards, or else the intended
>>> effect wouldn't be achieved (and instead some pages would be moved more
>>> than once).
>>>
>>> Also covers XEN_DMOP_relocate_memory, where the potential issue was first
>>> noticed.
>>>
>>> Fixes: a04811a315e0 ("mm: New XENMEM space, XENMAPSPACE_gmfn_range")
>>> Reported-by: Andrew Cooper <[email protected]>
>>> Signed-off-by: Jan Beulich <[email protected]>
>>> ---
>>> Of course an alternative would be to simply reject overlapping requests.
>>> Then we should reject all overlaps though, I think. But since the code
>>> change didn't end up overly intrusive, I thought I would go the "fix it"
>>> route first.
>>>
>>> In-place moves (->idx == ->gpfn) are effectively no-ops, but we don't look
>>> to short-circuit them for XENMAPSPACE_gmfn, so they're not short-circuited
>>> here either.
>>
>> Maybe we should short-circuit them. I can't think of anything good that
>> will come of having redundant TLB/IOTLB flushing. At the best it's a
>> waste of time, and at the worst it covers up bugs.
>
> I can do so (in a prereq change).
Or rather not. In looking more closely while actually trying to carry this out,
I had to realize that such a request e.g. has the side effect of unsharing the
source page (i.e. implicitly also allocating it). We would also take away from
the caller certain error indicators or state changes (e.g. a p2m_ram_logdirty
-> p2m_ram_rw type change; see also Roger's "x86/hvm: be more strict with
XENMAPSPACE_gmfn source types").
Jan
