Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-06-10 14:33, Stefano Stabellini wrote:
> +Jason
>
> On Tue, 10 Jun 2025, Julien Grall wrote:
> > But even if we are ok to break compatibility, I don't see the value of
> > "control_domid". The implication of setting "hardware_domid" is you will
> > have a separate control domain. At which point, why would it matter to specify
> > the domain ID?
>   
> I just wanted to say that while we (AMD) are looking for a hardware
> domain / control domain separation for safety reasons, I don't think we
> have a need to specify the domid for either one.
Specifying domids isn't really necessary, but it can be convenience or 
usability improvement with dom0less/Hyperlaunch.  But I don't think 
control_domid is necessary.
hardware_domid is not used for dom0less/Hyperlaunch with split control 
and hardware domains.  The "capabilities" device tree (DT) property 
specifies the role of the domain.
Hyperlaunch lets you specify a domid in the DT - there is some 
auto-allocation logic, but I haven't use it.  dom0less doesn't allow 
specifying a domid today, but it could.  dom0less domains are assigned 
domids sequentially, so you can determine it from the order in the DT.
Knowing the domids can be helpful for configuring userspace, and that 
only really matters for dom0less/Hyperlaunch.  e.g. xenstored wants to 
know which domid is control.
I think it's nice to have a domid property so that you know when 
configuring the system which domain is which.  You can explicitly read 
the domid out of the DT and know what it is.  Since dom0 userspace needs 
to refer to domids, this make it clear which domain is which for, as an 
example, connecting disks.
hardware_domid= is the way of enabling later hardware domain 
functionality.  dom0 boots as dom0.  When it creates domid == 
hardware_domid, that new domain becomes the hardware domain, and dom0 
loses hwdom and becomes just the control domain.  It's a legacy feature 
and was a workaround for when Xen could only create a single domain at boot.
Regards,
Jason