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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home