From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH 6/7] xen: Allow hardare domain != dom0 Date: Mon, 14 Apr 2014 16:12:24 -0400 Message-ID: <534C4128.40102@tycho.nsa.gov> References: <1395921128-7086-1-git-send-email-dgdegra@tycho.nsa.gov> <1395921128-7086-7-git-send-email-dgdegra@tycho.nsa.gov> <5347CE550200007800007E5E@nat28.tlf.novell.com> <5348053A.9040703@tycho.nsa.gov> <5348244E02000078000080C2@nat28.tlf.novell.com> <534832FD.8000105@tycho.nsa.gov> <534BB0C0020000780000842D@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <534BB0C0020000780000842D@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Keir Fraser , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 04/14/2014 03:56 AM, Jan Beulich wrote: >>>> On 11.04.14 at 20:22, wrote: >> On 04/11/2014 11:20 AM, Jan Beulich wrote: >>>>>> On 11.04.14 at 17:07, 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. Ah, I didn't see that part of the series was applied. Anyway, I didn't really like how far the full version (larger than the RFC below) ended up having to propagate the _by_id version, so a different solution would be better. >> ------------------------------>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 If the assignment to hardware_domain is moved into domain_create, this makes the (d == hardware_domain) version of is_hardware_domain work as expected, and removes the need for is_hardware_domain_by_id. This also makes the initialization look a bit cleaner; the patch will be posted momentarily. -- Daniel De Graaf National Security Agency