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
