[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |