From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] xenbus: Fix loopback event channel assuming domain 0 Date: Thu, 13 Oct 2011 14:24:26 -0400 Message-ID: <20111013182426.GG15499@phenom.oracle.com> References: <1317824920-639-1-git-send-email-dgdegra@tycho.nsa.gov> <20109.60188.905267.410813@mariner.uk.xensource.com> <4E8DF425.9000807@tycho.nsa.gov> <1317973956.21903.281.camel@zakaz.uk.xensource.com> <4E8F2AD0.2060904@tycho.nsa.gov> <1318251283.21903.424.camel@zakaz.uk.xensource.com> <4E94582C.4060305@tycho.nsa.gov> <1318437131.21903.775.camel@zakaz.uk.xensource.com> <4E95E0AB.5010901@tycho.nsa.gov> <1318497874.21903.812.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1318497874.21903.812.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Daniel De Graaf , "xen-devel@lists.xensource.com" , Ian Jackson List-Id: xen-devel@lists.xenproject.org On Thu, Oct 13, 2011 at 10:24:34AM +0100, Ian Campbell wrote: > > >> but > > >> the only Linux change required for the second case is the posted fix to the > > >> loopback event channel. > > > > > > Unless dom0 is also running Linux? In which case it has no way to talk > > > to the xenstored in the second domain? > > > > Correct; I am not addressing this problem as dom0 is not running Linux here. > > Sure, my concern was that we don't paint ourselves into a corner wrt > future moves in this direction. I think I'm now convinced that this > isn't the case and that everything is fine (thanks!). > > > The other patches you pointed to do address that possibility with the ioctl, > > which seems a good solution if you want to also run Linux in dom0 > > Agreed, I think the ioctl path will fit into your > "xenstored_local_init()" path just the same as it fits into the current > code. > > > > How does the xenstored running in the second domain get the necessary > > > page/evtchn numbers to allow it to communicate with dom0? > > > > In my setup, it doesn't ever communicate with dom0 as dom0 dies once it > > has set up the boot domains. For a more general case, the page/evtchn > > numbers could be passed in a normal introduce message if they are made > > available outside dom0 (perhaps by command-line parameters or via another > > mechanism like v4v). > > That rings a bell -- I think Deigo had them on the xenstored domain > command line. > > > > I assume it is guaranteed that xen_start_info->store_evtchn == 0 (and > > > presumably xen_start_info->store_mfn == 0) for the real dom0? > > > > Yes; the start_info page is zeroed prior to filling it in for dom0, and > > these fields are not filled in. > > Great. > > The representation of your changes which diff chose was not terribly > helpful for seeing the trees in the woods but I applied it and reviewed > the result and it looks ok to me. Daniel, Could you please repost these two patches with Ian's Reviewed-by and rebase it on top of 3.1-rc9 please?