[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 6/7] xen: Allow hardare domain != dom0
>>> On 11.04.14 at 20:22, <dgdegra@xxxxxxxxxxxxx> wrote: > On 04/11/2014 11:20 AM, Jan Beulich wrote: >>>>> On 11.04.14 at 17:07, <dgdegra@xxxxxxxxxxxxx> wrote: >>> On 04/11/2014 05:13 AM, Jan Beulich wrote: >>> Otherwise, I think the is_hardware_domain definition should be: >>> >>> #ifdef CONFIG_LATE_HWDOM >>> #define is_hardware_domain(_d) ((_d)->domain_id == hardware_domid) >>> #else >>> #define is_hardware_domain(_d) ((_d)->domain_id == 0) >>> #endif >>> >>> This also allows hardware_domid to be declared inside the #ifdef. >> >> But that still wouldn't necessarily do the correct thing for any use of >> the macro before that new special case code in domain_create() got >> run. Maybe my thinking of this is wrong, but as I tried to state above, >> I would expect Dom0 to be the hardware domain up to the point >> where the intended hardware domain gets created, at which point all >> state Dom0 obtained because of having been the de-facto hardware >> domain get transferred to hardware_domain. > > I agree with this in most cases, and I think the few places where that > is not true should be changed to make them more explicit. This must > include all checks in domain_create and those in functions called from > domain_create, because (d == hardware_domain) is always false inside > domain_create. An initial version of this patch is below, but unless > there are objections I plan to integrate it into patch 1 to avoid doing > (d->domain_id == 0) => is_hardware_domain => is_hardware_domain_by_id > for the ARM code. Integration into any earlier patch would work only if we reverted what was already applied. > ------------------------------>8------------------------ > > Subject: [PATCH RFC 6/8] xen: introduce is_hardware_domain_by_id Certainly not very nice a name, and also not very nice to then have two ways to check, which likely people will not always distinguish properly. I think this needs some better idea, albeit I can't immediately offer one. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |