On 2025-03-07 11:26, Andrew Cooper wrote:
On 07/03/2025 2:55 pm, Jason Andryuk wrote:
On 2025-03-06 17:39, Andrew Cooper wrote:
Second, you've created a case where we can make multiple hardware
domains, yet it is very much a singleton object from Xen's point of
view.
hardware_domain still remains the check for is_hardware_domain(), so
it's still a singleton.
Multiple domains can pass in CDF_hardware and latest-takes-precedence
for hardware_domain.
That only exists because late_hwdom is a bodge and relies on stealing.
A later ARM patch for the dom0less code adds a panic() if the device
tree defines a second hardware domains.
Another option might be to strip out late_hwdom, and do this more
nicely. I have little confidence that it works, seeing as it only gets
touched to fix build issues.
I don't want late_hwdom to hold up ARM side changes. I'm not using
late_hwdom, so I'd be fine removing it. But until Hyperlaunch is
merged, removal seems a little premature.
Either way, I think the common code wants to be ultimately responsible
for refusing to create multiple hardware domains.
But, by the end, I think we do need to have reasonable confidence that
only a single domain can be constructed as the hardware domain.
Would just an addition check be okay? Only allow the late_hwdom
behaviour for dom0.
--- i/xen/common/domain.c
+++ w/xen/common/domain.c
@@ -704,6 +704,10 @@ struct domain *domain_create(domid_t domid,
if ( hardware_domid < 0 || hardware_domid >=
DOMID_FIRST_RESERVED )
panic("The value of hardware_dom must be a valid domain
ID\n");
+ /* late_hwdom is only allowed for dom0. */
+ if ( hardware_domain && hardware_domain->domain_id )
+ return -EINVAL;
+
old_hwdom = hardware_domain;
hardware_domain = d;
}
CDF_hardware is a Xen-internal flag, so it's not something the toolstack
can pass in.
Regards,
Jason
