| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[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
|
|
|
| |
|
Home