Generation of phandles for guest DTB in dom0less

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

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?
Thanks,
 Oleksii