Xen devel - Jul 2006 - [powerpc] initial PowerPC support

Hi Keir, we have pushed the initial PowerPC support to
http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg ; it''s ready
for you to pull into xen-unstable.hg when you''re satisfied with it.

Unforunately Jimi and I are both going to be traveling a bit in the
upcoming days, but we will address comments as possible. Also, we will
be in Ottawa to discuss in person if everything hasn''t been ironed out
by then.

There are just a couple changes outside of xen/arch/powerpc that need
explanation:

xen/arch/x86/irq.c
xen/include/xen/irq.h
	We''re using x86/irq.c wholesale, and so need this extra PIC logic.

xen/common/memory.c
	PowerPC''s page->count_info is a long, because atomic operations are
performed on it. There''s no need to change its type for the other
architectures, but this printk needed to change.

xen/include/public/xencomm.h
	This is the data structure that Linux uses to pass arbitrarily sized
buffers to Xen, so it needs to be in public/ .

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10 Jul 2006, at 20:23, Hollis Blanchard wrote:
> xen/arch/x86/irq.c
> xen/include/xen/irq.h
> 	We''re using x86/irq.c wholesale, and so need this extra PIC
logic.
>
> xen/common/memory.c
> 	PowerPC''s page->count_info is a long, because atomic
operations are
> performed on it. There''s no need to change its type for the other
> architectures, but this printk needed to change.
>
> xen/include/public/xencomm.h
> 	This is the data structure that Linux uses to pass arbitrarily sized
> buffers to Xen, so it needs to be in public/ .
We''d like to separate changes to existing files from addition of new 
files. Could you send a patch that contains all modifications to 
existing files (including makefiles), and then we''ll comment on that 
separately from the bulk. This is the way we work with the ia64 team -- 
our pulls from their tree only bring in changes to ia64-specific code. 
All changes to common code are submitted separately as patches.

I think the changes are all okay to start with: I wonder why you call 
the arch powerpc rather than ppc? Also the change to the ARCH variable 
munging in xen/Rules.mk is strange -- do you have trailing characters 
after ''powerpc'' that need to be stripped off? There''s
a bogus extra
file in your tree (XendDomainInfo.py.orig).

What is the current status of this code in terms of stability and 
features? For example, does it work on a range of PPC systems, can 
unprivileged guests perform I/O, etc?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 2006-07-11 at 16:35 +0100, Keir Fraser wrote:
> On 10 Jul 2006, at 20:23, Hollis Blanchard wrote:
> 
> > xen/arch/x86/irq.c
> > xen/include/xen/irq.h
> > 	We''re using x86/irq.c wholesale, and so need this extra PIC
logic.
> >
> > xen/common/memory.c
> > 	PowerPC''s page->count_info is a long, because atomic
operations are
> > performed on it. There''s no need to change its type for the
other
> > architectures, but this printk needed to change.
> >
> > xen/include/public/xencomm.h
> > 	This is the data structure that Linux uses to pass arbitrarily sized
> > buffers to Xen, so it needs to be in public/ .
> 
> We''d like to separate changes to existing files from addition of
new
> files. Could you send a patch that contains all modifications to 
> existing files (including makefiles), and then we''ll comment on
that
> separately from the bulk. This is the way we work with the ia64 team -- 
> our pulls from their tree only bring in changes to ia64-specific code. 
> All changes to common code are submitted separately as patches.
Sure; that''s how I''ve been trying to do things too. The reason
I didn''t
do that here is because none of the common code changes are independent
(unlike e.g. the recent ELF loader changes). I will submit them
separately.
> I think the changes are all okay to start with: I wonder why you call 
> the arch powerpc rather than ppc?
Linux recently started supporting both 32- and 64-bit CPUs in the same
architecture, and they call it "powerpc" (in contrast to
"ppc" and
"ppc64"). 
> Also the change to the ARCH variable 
> munging in xen/Rules.mk is strange -- do you have trailing characters 
> after ''powerpc'' that need to be stripped off?
uname -m will return either "ppc" or "ppc64". We translate
that to be
"powerpc" or "powerpc64" (analogous to "x86_32"
and "x86_64"), then
strip the "64" to get us to xen/arch/powerpc.
> There''s a bogus extra file in your tree (XendDomainInfo.py.orig).
Hmm... I do have that file locally, but hg doesn''t know about it, and
http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg?cmd=manifest;manifest=9b5d95e5fc0c7b97a38b7bf5462ef1e0eb29bc62;path=/tools/python/xen/xend/
doesn''t list it.
> What is the current status of this code in terms of stability and 
> features? For example, does it work on a range of PPC systems, can 
> unprivileged guests perform I/O, etc?
It works on Maple evalution boards, JS20 and JS21 blades (all of these
are PowerPC 970 processors). DomU can''t perform direct IO (yet), and in
fact we''re still working on virtual IO (right now I think the main
issue
there is getting all the way through xend domain creation). SMP (in Xen
or guest) is not supported. We haven''t done any performance analysis.

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel