[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 01/23] xen: introduce hardware domain create flag
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |