|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] xenstore documentation
> -----Original Message-----
> From: NAHieu [mailto:nahieu@xxxxxxxxx]
> Sent: 04 October 2005 19:00
> To: Anthony Liguori
> Cc: Neugebauer, Rolf; Rami Rosen; harry; Jacob Gorm Hansen; xen-
> devel@xxxxxxxxxxxxxxxxxxx
> Subject: 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?
The main problem is that it doesn't work when you have multiple BE in
different domains. Something you can't do at the moment but consider
multiple NICs and device drivers in for them in multiples VMs. Which one
is dealing with it when the front end comes up. How does the FE know
which BE to connect to (ie who to grant access to the shared page to)
etc.
> But like Rolf pointed out, this solution is not good incase we want to
> save/restore(?)
Your approach above might still work with save restore etc. but you
essentially need xend to tell FE and possibly BEs which one to pick if
there are multiples out there. so xend needs to be involved as it is
parsing the VMs config file.
Basically the way it is implement for blk/net/tpm device is the right
way. I was just suggesting that of you want to prototype something you
don't necessarily need to follow this and don't initially need to
modifiy xend.
Rolf
> 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
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
RE: [Xen-devel] xenstore documentation,
Neugebauer, Rolf <=
|
|
|
|
|