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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

> >>  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.

Ian.



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