WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming doma

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0
From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date: Thu, 06 Oct 2011 14:32:05 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 06 Oct 2011 11:32:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20109.60188.905267.410813@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: National Security Agency
References: <1317824920-639-1-git-send-email-dgdegra@xxxxxxxxxxxxx> <20109.60188.905267.410813@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel