From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH] xenbus: Add support for xenbus backend in stub domain Date: Thu, 12 Jan 2012 10:58:58 -0500 Message-ID: <4F0F0342.7080105@tycho.nsa.gov> References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov> <1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov> <4F0EAF05020000780006C061@nat28.tlf.novell.com> <4F0EFC0B.9030600@tycho.nsa.gov> <4F0F0CE3020000780006C27E@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F0F0CE3020000780006C27E@nat28.tlf.novell.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: Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 01/12/2012 10:40 AM, Jan Beulich wrote: >>>> On 12.01.12 at 16:28, Daniel De Graaf wrote: >> On 01/12/2012 03:59 AM, Jan Beulich wrote: >>>>>> On 11.01.12 at 18:22, Daniel De Graaf wrote: >>>> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the >>>> xenbus backend to be started after the kernel has booted. This is >>>> intended to allow dom0 to start another domain to run xenstore. >>>> >>>> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be >>>> started; the domain ID is passed as the ioctl argument. This sets up a >>>> listening event channel and grant reference to xenbus, but does not >>>> start using this interface. It returns the local event channel port. >>> >>> Any chance to get at least the setup part matched with the >>> legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)? >>> >>> Jan >> >> From what I can tell, the legacy ioctl cannot restore watches because the >> return value must be used to set up xenstore communication before they can >> be used. > > Then I must have missed something. But this was the only kernel side > patch, wasn't it? > > Is the intended behavior then to have a Dom0-based xenstored > starting first, then do a brain transfer to that running in a stub > domain? That certainly wasn't the behavior of what the legacy > Linux implementation was intended for... > >> Or were you just asking if IOCTL_XENBUS_BACKEND_REMOTE_SETUP's parameter >> can be changed to xenbus_alloc_t? That structure could be populated in the >> same way as the legacy implementation, but it wouldn't give any more >> information than the current ioctl does. > > No, if it functionally differs, then we really should just care that > the ioctl numbers don't collide. > > Jan > I think this depends on how the xenstore domain is constructed: if it is started instead of the dom0-based xenstored (not the current method, but converting init-xenstored to create the domain itself should make this possible) then the setup/commit split of the ioctl is not needed. In that case the older ioctl name/interface can be preserved (although the grant field will always be populated with 1). -- Daniel De Graaf National Security Agency