[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.