On 06/03/2025 10:03 pm, Jason Andryuk wrote: > From: "Daniel P. Smith" <dpsm...@apertussolutions.com> > > Add and use a new internal create domain flag to specify the hardware > domain. This removes the hardcoding of domid 0 as the hardware domain. > > This allows more flexibility with domain creation. > > Signed-off-by: Daniel P. Smith <dpsm...@apertussolutions.com> > Signed-off-by: Jason Andryuk <jason.andr...@amd.com>
I definitely like the removal of the late_hwdom bodges. However, there are several things to be aware of here. First, CDF_privileged probably wants renaming to CDF_control, now that CDF_hardware is being split out. 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. This might be ok it's addressed by later in the series. One especially nasty bit of late_hwdom was how dom0 started as both, then the late_hwdom stole dom0's hw-ness. I expect untangling this is more complicated than a single patch. 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. > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h > index 3de5635291..b5e82578c3 100644 > --- a/xen/include/xen/domain.h > +++ b/xen/include/xen/domain.h > @@ -50,6 +50,8 @@ void arch_get_domain_info(const struct domain *d, > #else > #define CDF_staticmem 0 > #endif > +/* Is this the hardware? */ > +#define CDF_hardware (1U << 3) No, this one CDF flag isn't the hardware. That would be the CPU we're running on. ~Andrew
