All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [PATCH 6/7] xen: Allow hardare domain != dom0
Date: Mon, 14 Apr 2014 08:56:16 +0100	[thread overview]
Message-ID: <534BB0C0020000780000842D@nat28.tlf.novell.com> (raw)
In-Reply-To: <534832FD.8000105@tycho.nsa.gov>

>>> On 11.04.14 at 20:22, <dgdegra@tycho.nsa.gov> wrote:
> On 04/11/2014 11:20 AM, Jan Beulich wrote:
>>>>> On 11.04.14 at 17:07, <dgdegra@tycho.nsa.gov> 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

  reply	other threads:[~2014-04-14  7:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 11:52 [PATCH v3 0/7] xen: Hardware domain support Daniel De Graaf
2014-03-27 11:52 ` [PATCH 1/7] xen: use domid check in is_hardware_domain Daniel De Graaf
2014-03-27 15:31   ` Ian Campbell
2014-03-27 11:52 ` [PATCH 2/7] xen/iommu: Move dom0 setup code to __hwdom_init Daniel De Graaf
2014-03-27 11:52 ` [PATCH 3/7] xen: prevent 0 from being used as a dynamic domid Daniel De Graaf
2014-03-27 11:52 ` [PATCH 4/7] xen: rename dom0 to hardware_domain Daniel De Graaf
2014-03-27 12:20   ` Egger, Christoph
2014-03-27 12:48     ` Daniel De Graaf
2014-03-27 15:46       ` Egger, Christoph
2014-03-27 15:33   ` Ian Campbell
2014-03-27 11:52 ` [PATCH 5/7] xen: rename various functions referencing dom0 Daniel De Graaf
2014-03-27 15:34   ` Ian Campbell
2014-03-27 15:47     ` Daniel De Graaf
2014-03-27 11:52 ` [PATCH 6/7] xen: Allow hardare domain != dom0 Daniel De Graaf
2014-04-11  9:13   ` Jan Beulich
2014-04-11 15:07     ` Daniel De Graaf
2014-04-11 15:20       ` Jan Beulich
2014-04-11 18:22         ` Daniel De Graaf
2014-04-14  7:56           ` Jan Beulich [this message]
2014-04-14 20:12             ` Daniel De Graaf
2014-03-27 11:52 ` [PATCH 7/7] tools/libxl: Allow dom0 to be destroyed Daniel De Graaf
2014-03-27 15:35   ` Ian Campbell
2014-04-02 15:08     ` Ian Jackson
2014-04-10 15:58 ` [PATCH v3 0/7] xen: Hardware domain support Keir Fraser
  -- strict thread matches above, loose matches on Subject: below --
2014-03-18 21:34 [PATCH v2 " Daniel De Graaf
2014-03-18 21:34 ` [PATCH 6/7] xen: Allow hardare domain != dom0 Daniel De Graaf
2014-03-19  9:15   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=534BB0C0020000780000842D@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.