From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [XenPPC] Re: New domain builder in xen-unstable Date: Fri, 09 Mar 2007 16:05:36 -0600 Message-ID: <1173477936.29309.133.camel@basalt> References: Reply-To: Hollis Blanchard Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Brendan Cully , Gerd Hoffmann , Xen Development Mailing List , xen-ppc-devel List-Id: xen-devel@lists.xenproject.org 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