[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v9 2/3] xen/domain: adjust domain ID allocation for Arm
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |