|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming doma
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?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Daniel De Graaf
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Ian Jackson
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Daniel De Graaf
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Ian Campbell
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Daniel De Graaf
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Ian Campbell
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Daniel De Graaf
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Ian Campbell
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Daniel De Graaf
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0, Ian Campbell
- Re: [Xen-devel] [PATCH] xenbus: Fix loopback event channel assuming domain 0,
Konrad Rzeszutek Wilk <=
- [Xen-devel] [PATCH 1/2] xenbus: Fix loopback event channel assuming domain 0, Daniel De Graaf
- [Xen-devel] [PATCH 2/2] xenbus: don't rely on xen_initial_domain to detect local xenstore, Daniel De Graaf
|
|
|
|
|