[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [XenPPC] Re: xencomm porting and "inline" handles
On Thu, 2006-09-28 at 08:27 +0200, Tristan Gingold wrote: > Le Mercredi 27 Septembre 2006 17:10, Hollis Blanchard a Ãcrit : > > On Wed, 2006-09-27 at 08:19 +0200, Tristan Gingold wrote: > > > Le Mardi 26 Septembre 2006 20:23, Hollis Blanchard a Ãcrit : > > > > On Tue, 2006-09-26 at 10:04 +0200, Tristan Gingold wrote: > > > > > After more work, inline xencomm is not that magic: it doesn't work > > > > > for modules which are loaded in virtual memory. So I have to use > > > > > mini xencomm at least for modules. > > > > > > > > What's the problem with modules? Their text/data isn't physically > > > > contiguous, but where exactly is the problem? > > > > > > Inline xencomm only works for physically contiguous area because only the > > > base address is passed. Therefore it doesn't work for modules. > > > > I understand that; please explain exactly what about the modules isn't > > working. > > > > For example, the stack used in kernel modules is still physically > > contiguous, so using stack-allocated data structures should work fine. > > However, making hypercalls directly using global data structures > > wouldn't work. However, the "inline" code is only being used for the > > hypercalls that could be made early. Is that the problem? Please > > identify the specific issue(s). > Yes, some hypercalls data are global data. > Sorry, I was not specific enough! Hi Tristan, *which* hypercalls? Please identify some specific lines of code that are causing the problems... -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-ppc-devel mailing list Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ppc-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |