Re: Generation of phandles for guest DTB in dom0less

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 10 Apr 2026, Oleksii Kurochko wrote:
> Hi all,
> 
> While working on dom0less guest FDT construction I noticed that
> fdt_generate_phandle() is "broken" when used to generate phandles for a
> guest's nodes. The root cause is the way dom0less manages phandle_intc
> (phandle_gic in Arm terminology): the dummy GIC node already occupies a
> phandle in pfdt, but fdt_generate_phandle(kinfo->fdt, ...) has no visibility
> into pfdt and therefore may produce a phandle that collides with phandle_intc.
> 
> I see three potential approaches to fix this and would like to get the
> community's feedback before going further.
> 
> **Option 1: guest_fdt_generate_phandle() wrapper**
> 
> Introduce a thin wrapper that skips any phandle already reserved by the
> architecture:
> 
>   int guest_fdt_generate_phandle(const struct kernel_info *kinfo, uint32_t
> *phandle)
>   {
>       int res;
> 
>       res = fdt_generate_phandle(kinfo->fdt, phandle);
> 
>       if ( *phandle == kinfo->phandle_intc )
>           (*phandle)++;
> 
>       return res;
>   }
> 
> The obvious downside is that this is not flexible: every future node added to
> pfdt would require a corresponding fixup here, which is easy to forget and
> hard to maintain.
> 
> **Option 2: Reserve a "first free phandle" field in the arch-specific
> structure**
> 
> Add a field to the arch-specific part of struct kernel_info that stores the
> first phandle number guaranteed not to be used by pfdt. Guest phandle
> allocation would then start from (and increment) this field, completely
> avoiding the pfdt phandle space.
> 
> This is cleaner than Option 1 but requires careful initialisation and
> documentation to make sure the field is always set before it is consumed.
> 
> **Option 3: Store a pfdt pointer in struct kernel_info**
> 
> Add a `pfdt` pointer to struct kernel_info and pass it to
> fdt_generate_phandle() whenever a guest phandle is needed:
> 
>   fdt_generate_phandle(kinfo->pfdt, ...)
> 
> Because fdt_generate_phandle() walks the target FDT to find the highest
> existing phandle and returns the next free one, using pfdt as the source of
> truth guarantees uniqueness across both pfdt and the guest FDT, without any
> manual bookkeeping.
> 
> This feels like the most robust option to me, since it naturally handles any
> future nodes added to pfdt without requiring changes to the phandle allocation
> logic.
> 
> Does anyone see issues with Option 3? Are there other approaches worth
> considering?

Option 3 looks decent