From: Mykola Kvach <mykola_kvach@epam.com>

With LLC coloring enabled, the hardware domain memory is allocated by
allocate_hwdom_memory() instead of relying on the fixed direct-map
layout. Since de99f3263555 ("device-tree: Improve hwdom memory
allocation for DMA"), the allocator prefers lower host regions, but the
first-bank filter still only enforces the old 128MB heuristic.

A low candidate bank can satisfy that heuristic while still being
unsuitable for the Arm kernel/DTB/initrd placement rules. Split the Arm
placement logic into reusable helpers first, then validate the candidate
hardware-domain bank 0 against those helpers before allocating it.

Changes in v2:
- Split the previous single patch into a behavior-preserving Arm
  placement refactoring and a separate hardware-domain first-bank fix.
- Rename find_module_placement() and place_modules() to use DTB/initrd
  terminology.
- Pass ramend to find_dtb_initrd_placement().
- Update the stale tools/libs/guest/xg_dom_arm.c reference.

Link to v1:
  https://patchew.org/Xen/4f862bb2dc323914b8120b0f16af7516140cf42b.1780065103.git.mykola._5Fkvach@epam.com/

Mykola Kvach (2):
  xen/arm: split DTB/initrd placement helpers
  device-tree: device-tree: validate hwdom bank 0 boot placement

 xen/arch/arm/acpi/domain_build.c        |   2 -
 xen/arch/arm/domain_build.c             |   8 +
 xen/arch/arm/include/asm/domain_build.h |   4 +
 xen/arch/arm/include/asm/kernel.h       |   9 ++
 xen/arch/arm/kernel.c                   | 190 ++++++++++++++++++------
 xen/common/device-tree/domain-build.c   |  30 ++--
 xen/include/xen/fdt-kernel.h            |   9 ++
 7 files changed, 192 insertions(+), 60 deletions(-)

-- 
2.43.0

Hello Mykola,

On 6/5/26 7:19 AM, Mykola Kvach wrote:
> From: Mykola Kvach <mykola_kvach@epam.com>

Just out of curiosity, is it okay that the email address listed here 
differs from the one you're using to send patches? (By the way, nice 
email address ;))

> 
> With LLC coloring enabled, the hardware domain memory is allocated by
> allocate_hwdom_memory() instead of relying on the fixed direct-map
> layout. Since de99f3263555 ("device-tree: Improve hwdom memory
> allocation for DMA"), the allocator prefers lower host regions, but the
> first-bank filter still only enforces the old 128MB heuristic.
> 
> A low candidate bank can satisfy that heuristic while still being
> unsuitable for the Arm kernel/DTB/initrd placement rules. Split the Arm
> placement logic into reusable helpers first, then validate the candidate
> hardware-domain bank 0 against those helpers before allocating it.
> 
> Changes in v2:
> - Split the previous single patch into a behavior-preserving Arm
>    placement refactoring and a separate hardware-domain first-bank fix.
> - Rename find_module_placement() and place_modules() to use DTB/initrd
>    terminology.
> - Pass ramend to find_dtb_initrd_placement().
> - Update the stale tools/libs/guest/xg_dom_arm.c reference.
> 
> Link to v1:
>    https://patchew.org/Xen/4f862bb2dc323914b8120b0f16af7516140cf42b.1780065103.git.mykola._5Fkvach@epam.com/
> 

I would like to clarify whether my understanding is correct.

With LLC coloring enabled on ARM, the allocator could assign the 
hardware domain a bank 0 that passes the size check but is unsuitable 
for kernel/DTB/initrd placement. As a result, the hardware domain may 
fail to boot or could silently corrupt memory if the images are placed 
in an incorrect location.

Is my understanding correct?

Thanks in advance.

~ Oleksii

On 05-Jun-26 10:00, Oleksii Kurochko wrote:
> Hello Mykola,
> 
> On 6/5/26 7:19 AM, Mykola Kvach wrote:
>> From: Mykola Kvach <mykola_kvach@epam.com>
> 
> Just out of curiosity, is it okay that the email address listed here 
> differs from the one you're using to send patches? (By the way, nice 
> email address ;))
> 
>>
>> With LLC coloring enabled, the hardware domain memory is allocated by
>> allocate_hwdom_memory() instead of relying on the fixed direct-map
>> layout. Since de99f3263555 ("device-tree: Improve hwdom memory
>> allocation for DMA"), the allocator prefers lower host regions, but the
>> first-bank filter still only enforces the old 128MB heuristic.
>>
>> A low candidate bank can satisfy that heuristic while still being
>> unsuitable for the Arm kernel/DTB/initrd placement rules. Split the Arm
>> placement logic into reusable helpers first, then validate the candidate
>> hardware-domain bank 0 against those helpers before allocating it.
>>
>> Changes in v2:
>> - Split the previous single patch into a behavior-preserving Arm
>>    placement refactoring and a separate hardware-domain first-bank fix.
>> - Rename find_module_placement() and place_modules() to use DTB/initrd
>>    terminology.
>> - Pass ramend to find_dtb_initrd_placement().
>> - Update the stale tools/libs/guest/xg_dom_arm.c reference.
>>
>> Link to v1:
>>    https://patchew.org/Xen/4f862bb2dc323914b8120b0f16af7516140cf42b.1780065103.git.mykola._5Fkvach@epam.com/
>>
> 
> I would like to clarify whether my understanding is correct.
> 
> With LLC coloring enabled on ARM, the allocator could assign the 
> hardware domain a bank 0 that passes the size check but is unsuitable 
> for kernel/DTB/initrd placement. As a result, the hardware domain may 
> fail to boot or could silently corrupt memory if the images are placed 
> in an incorrect location.
> 
> Is my understanding correct?
Yes, Xen would fail to boot such domain. On Arm we carry a lot of placement
logic we need to deal with...

~Michal

On 6/5/26 10:03 AM, Orzel, Michal wrote:
> 
> 
> On 05-Jun-26 10:00, Oleksii Kurochko wrote:
>> Hello Mykola,
>>
>> On 6/5/26 7:19 AM, Mykola Kvach wrote:
>>> From: Mykola Kvach <mykola_kvach@epam.com>
>>
>> Just out of curiosity, is it okay that the email address listed here
>> differs from the one you're using to send patches? (By the way, nice
>> email address ;))
>>
>>>
>>> With LLC coloring enabled, the hardware domain memory is allocated by
>>> allocate_hwdom_memory() instead of relying on the fixed direct-map
>>> layout. Since de99f3263555 ("device-tree: Improve hwdom memory
>>> allocation for DMA"), the allocator prefers lower host regions, but the
>>> first-bank filter still only enforces the old 128MB heuristic.
>>>
>>> A low candidate bank can satisfy that heuristic while still being
>>> unsuitable for the Arm kernel/DTB/initrd placement rules. Split the Arm
>>> placement logic into reusable helpers first, then validate the candidate
>>> hardware-domain bank 0 against those helpers before allocating it.
>>>
>>> Changes in v2:
>>> - Split the previous single patch into a behavior-preserving Arm
>>>     placement refactoring and a separate hardware-domain first-bank fix.
>>> - Rename find_module_placement() and place_modules() to use DTB/initrd
>>>     terminology.
>>> - Pass ramend to find_dtb_initrd_placement().
>>> - Update the stale tools/libs/guest/xg_dom_arm.c reference.
>>>
>>> Link to v1:
>>>     https://patchew.org/Xen/4f862bb2dc323914b8120b0f16af7516140cf42b.1780065103.git.mykola._5Fkvach@epam.com/
>>>
>>
>> I would like to clarify whether my understanding is correct.
>>
>> With LLC coloring enabled on ARM, the allocator could assign the
>> hardware domain a bank 0 that passes the size check but is unsuitable
>> for kernel/DTB/initrd placement. As a result, the hardware domain may
>> fail to boot or could silently corrupt memory if the images are placed
>> in an incorrect location.
>>
>> Is my understanding correct?
> Yes, Xen would fail to boot such domain. On Arm we carry a lot of placement
> logic we need to deal with...

Thanks for confirming. Then for this patch series:

Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii