From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] xenbus: Fix loopback event channel assuming domain 0
Date: Thu, 06 Oct 2011 14:32:05 -0400 [thread overview]
Message-ID: <4E8DF425.9000807@tycho.nsa.gov> (raw)
In-Reply-To: <20109.60188.905267.410813@mariner.uk.xensource.com>
On 10/06/2011 01:53 PM, Ian Jackson wrote:
> Daniel De Graaf writes ("[Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0"):
>> The xenbus event channel established in xenbus_init is intended to be a
>> loopback channel, but the remote domain was hardcoded to 0; this will
>> cause the channel to be unusable when xenstore is not being run in
>> domain 0.
>
> I'm not sure I understand this.
>
> ...
>> /* Next allocate a local port which xenstored can bind to */
>> alloc_unbound.dom = DOMID_SELF;
>> - alloc_unbound.remote_dom = 0;
>> + alloc_unbound.remote_dom = DOMID_SELF;
>
> The comment doesn't suggest that this is supposedly a loopback channel
> (ie one for use by the xenbus client for signalling to itself,
> somehow).
The event channel being changed here is a loopback event channel exposed in
/proc/xen/xsd_port, which xenstored binds to. This code is only used for the
initial domain; otherwise, the shared info page is used.
> Rather it's supposed to be a channel to xenstore. So the remote
> domain should be the xenstore domain, which should come from the
> shared info page.
>
> Have you actually tested this with a separate xenstored domain ?
>
> Ian.
>
The test setup that exposed this issue is having a non-dom0 Linux domain
running xenstored (in addition to other services); this domain is started
with the SIF_INITDOMAIN flag set. It has been tested and can start other
domains with references back to the xenstored running there; the local
kernel is able to communicate with the locally running xenstore to provide
backend services.
The test for xen_initial_domain() here might better be replaced with a
check on xen_start_info->store_evtchn which should be a valid event channel
on all domains except the domain running xenstored. This seems like a more
elegant solution than relying on the SIF_INITDOMAIN flag to determine the
location of xenstore.
--
Daniel De Graaf
National Security Agency
next prev parent reply other threads:[~2011-10-06 18:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 14:28 [PATCH] xenbus: Fix loopback event channel assuming domain 0 Daniel De Graaf
2011-10-06 17:53 ` Ian Jackson
2011-10-06 18:32 ` Daniel De Graaf [this message]
2011-10-07 7:52 ` Ian Campbell
2011-10-07 16:37 ` Daniel De Graaf
2011-10-10 12:54 ` Ian Campbell
2011-10-11 14:52 ` Daniel De Graaf
2011-10-12 16:32 ` Ian Campbell
2011-10-12 18:47 ` Daniel De Graaf
2011-10-13 9:24 ` Ian Campbell
2011-10-13 18:24 ` Konrad Rzeszutek Wilk
2011-10-13 20:07 ` [PATCH 1/2] " Daniel De Graaf
2011-10-13 20:07 ` [PATCH 2/2] xenbus: don't rely on xen_initial_domain to detect local xenstore Daniel De Graaf
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=4E8DF425.9000807@tycho.nsa.gov \
--to=dgdegra@tycho.nsa.gov \
--cc=Ian.Jackson@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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.