All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [PATCH 6/7] xen: Allow hardare domain != dom0
Date: Fri, 11 Apr 2014 11:07:38 -0400	[thread overview]
Message-ID: <5348053A.9040703@tycho.nsa.gov> (raw)
In-Reply-To: <5347CE550200007800007E5E@nat28.tlf.novell.com>

On 04/11/2014 05:13 AM, Jan Beulich wrote:
>>>> On 27.03.14 at 12:52, <dgdegra@tycho.nsa.gov> wrote:
>
> I was about to commit this, but further changes are needed (along
> with fixing the typo in the title):

I noticed the typo soon after posting v3, but didn't want to post
v4 with that and some other whitespace.  It looks like v4 will have
useful changes now, however.

>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -84,6 +84,8 @@ unsigned long __initdata highmem_start;
>>   size_param("highmem-start", highmem_start);
>>   #endif
>>
>> +integer_param("hardware_dom", hardware_domid);
>
> This should be moved alongside the definition of the symbol in
> common code, and be enclosed in "#ifdef CONFIG_LATE_HWDOM".
>
> And docs/misc/xen-command-line.markdown wants an entry for it.

OK.

>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -45,6 +45,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
>>
>>   /* A global pointer to the hardware domain (usually DOM0). */
>>   extern struct domain *hardware_domain;
>> +extern domid_t hardware_domid;
>>
>>   #ifndef CONFIG_COMPAT
>>   #define BITS_PER_EVTCHN_WORD(d) BITS_PER_XEN_ULONG
>> @@ -794,7 +795,7 @@ void watchdog_domain_destroy(struct domain *d);
>>    *    (that is, this would not be suitable for a driver domain)
>>    *  - There is never a reason to deny dom0 access to this
>>    */
>> -#define is_hardware_domain(_d) ((_d)->domain_id == 0)
>> +#define is_hardware_domain(d)  ((d)->domain_id == hardware_domid)
>
> This macro should imo evaluate to true for Dom0 until the hardware
> domain go created, i.e. you should compare _d with hardware_domain
> rather than their IDs. With that the definition of hardware_domid can
> then also be moved inside the #ifdef requested above.

This isn't quite as simple as changing the function since there are
some places where is_hardware_domain needs to return false for domain 0
when a hardware domain is used.  Also, the hardware_domain variable is
not set until domain_create returns, so there are a few places where the
domain ID still needs to be checked explicitly.  It should be possible
to create an is_hardware_domid function for those cases, if comparing to
hardware_domain is preferred for most cases; I think that would belong in
a new patch 5.5/7 (i.e. 6/8 in v4).

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.

-- 
Daniel De Graaf
National Security Agency

  reply	other threads:[~2014-04-11 15:07 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 [this message]
2014-04-11 15:20       ` Jan Beulich
2014-04-11 18:22         ` Daniel De Graaf
2014-04-14  7:56           ` Jan Beulich
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=5348053A.9040703@tycho.nsa.gov \
    --to=dgdegra@tycho.nsa.gov \
    --cc=JBeulich@suse.com \
    --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.