[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [XenPPC] Re: New domain builder in xen-unstable
On Wed, 2007-03-07 at 08:27 +0000, Keir Fraser wrote: > > > The new domain builder infrastructure is not flexible enough for > > PowerPC, so we're sticking with our own xc_linux_build(). It sounded > > before like that would be possible, so I assume a20ec270998b was > just an > > oversight? > > Hmm yes. You can #ifdef in the Python wrapper for now. But I'm > surprised that you can't move to the new domain builder at all -- it > has hooks for arch-dependent code to be inserted already, and we could > add more if there's a need. It's pretty complex, which you may not realize since Gerd did the x86 work for you. FYI, I've been working on this for three days, and when I'm done I will only have un-broken PowerPC. Dubious use of time IMHO. I can't just ifdef PowerPC's xc_linux_build back in, because libelf doesn't map page-by-page like the old ELF loader did. That means I need to pre-map the memory, which starts dragging in xc_dom infrastructure. I'm tempted to copy-paste-and-hack that infrastructure, but I'm trying to be a good person and fit into the common code (avoiding ifdefs) wherever possible. Here's my current confusion: where are these ELF features described? Since PowerPC domU communicate only via GPFNs, do I need to set the "auto-translated" feature? What is the difference between dom->shadow_enable and xc_dom_feature_translated()? -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |