|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] xenstore documentation
On 10/5/05, Anthony Liguori <aliguori@xxxxxxxxxx> wrote:
> NAHieu wrote:
>
> >>or no ;) depending on what you want to do. so for example if you only
> >>ever have one backend in the system then you "could" store that under a
> >>well known name in the store and the frontends can simply read that.
> >>you'll also need a place for the BE to watch for FE updates in a similar
> >>fashion.
> >>
> >>
> >>
> >
> >Rolf, I am really suprised here: how can BE watch for FE updates? BE
> >and FE are in different domain, so they cannot access each other
> >xenstore tree. (??)
> >
> >
> Yes they can. Permissions are currently off so technically any domain
> can access any other domains tree.
>
> When permissions are enabled, the backends will have at least read
> permission on all the frontend domains.
>
If so, I think we can do simply like this to exchange information
between dom0 & domU:
- dom0 watch for @introduceDomain to detect the new domU comes up.
Then dom0 watch for /domU/<device>/{evtchn,grant-ref}
- domU write evtchn,grant-ref,... to /domU/<device>/{evtchn,grant-ref}
(better doesnt write it outside its home, like in Rolf's example)
- dom0 detect the updates, setup evtchn, then start to notify domU via
this channel. Other data can be written into the share memory (like
grant-ref above) to exchange information at this step.
This way is good (if it works - I will try it myself), since we don't
need to mod xend, which is horrified to many. Any ideas?
But like Rolf pointed out, this solution is not good incase we want to
save/restore(?)
Thanks.
Hieu
> Regards,
>
> Anthony Liguori
>
> >So exactly what did you mean?
> >
> >Thanks.
> >Hieu
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-devel
> >
> >
> >
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|