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

[dmkhn@proton.me]

On Tue, Jun 10, 2025 at 05:37:33PM -0400, Jason Andryuk wrote:
> 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.

Thanks for explanation!

> 
> Regards,
> Jason