Re: [PATCH] xen/arm: Fix under-mapping in map_range_to_domain()

["Orzel, Michal" <michal.orzel@xxxxxxx>]

On 07-Oct-26 22:20, Grall, Julien wrote:
> Hi Michal,
> 
> On 07/10/2026 15:58, Michal Orzel wrote:
>> If the memory region to be mapped does not start at the page boundary
>> and its end spans over the page boundary, map_range_to_domain() passes
>> a number of pages that is short by one to map_regions_p2mt(). Domain's
>> attempt to access memory within that page will fail. Fix it by calculating
>> the number of pages to be mapped taking into account the start offset.
> 
> Can you provide an example where the caller doesn't suitably align?
Sure. Example is handle_device() being called on the hwdom DTB creation time for
a node whose address is not page aligned i.e. /reserved-memory node or basically
any node, given that DT spec does not mention anything about memory region
alignment and there are existing DTs like that. With reg = <0x0 0x800 0x0
0x1000>, today we only map 0x0-0xfff and an access to 0x1000-0x17ff faults.

> 
>>
>> Fixes: 88c10b0d6eee ("arch/arm: let map_mmio_regions() use start and count")
>> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
> 
> The fix LGTM in the current context. However given map_range_to_domain() 
> is now used in more places (e.g. overlay), I wonder whether this is the 
> right decision to allow map_range_to_domain() with non-aligned region.
> 
> Imagine a user say "I want to map 0x400 - 0x1000 to domain A and map 
> domain B "0x0 - 0x400". This could result to interesting behavior if the 
> user is not aware of the alignment (this would become even more 
> problematic if we decide to ever support different page granularity on Arm).
I agree this is not great, but this is not something introduced here:
iomem_permit_access() and the iomem_ranges rangeset already cover whole pages
and we already map the full first page. This patch only makes the p2m mapping
match what we already allow.

I don't think we can reject unaligned regions in map_range_to_domain()
though, as the host DT is not under our control and hwdom would fail to
boot on platforms with sub-page devices. I asked AI to look at the Linux boards
for Arm and Arm64 (140 boards in total with unaligned regions) and even the
boards we claim to support have nodes that would fail:
- RPI4: hdmi@7ef00700, <0x7ef01f00 0x400>
- IMX8QXP: clock-controller@5b290004, <0x5b290004 0x10000>

~Michal