Re: [Xen-devel] Re: [XenPPC] Xencomm for xen/ia64

2006-08-22 Thread Tristan Gingold
Le Lundi 21 Août 2006 18:24, Hollis Blanchard a écrit : On Mon, 2006-08-21 at 08:46 +0200, Tristan Gingold wrote: Le Vendredi 18 Août 2006 18:39, Hollis Blanchard a écrit : On Fri, 2006-08-18 at 11:04 +0200, Tristan Gingold wrote: Le Jeudi 17 Août 2006 20:35, Hollis Blanchard a écrit :

Re: [XenPPC] RFC: xencomm - linux side

2006-08-22 Thread Tristan Gingold
Le Lundi 21 Août 2006 21:07, Hollis Blanchard a écrit : On Mon, 2006-08-21 at 17:18 +0200, Tristan Gingold wrote: I am posting the linux xencomm code for review. I'd plan to submit soon unless comments/remarks. NAK. I'm still waiting to hear back about how you can use xencomm_inline()

[XenPPC] [xenppc-unstable] [POWERPC] RFC: memory clean up

2006-08-22 Thread poff
This code walks the OF dev tree, finding end-of-memory and memory holes. All memory beyond the hypervisor's RMA is added to domheap. (Previously only memory upto 1st hole was used.) Finally, parts of setup.c have been swept into memory.c as cleanup. diff -r 9c72449e4370 xen/arch/powerpc/setup.c

Re: [XenPPC] [PATCH] Enable SMP, smp_processor_id, for_each_cpu, nosmp, maxcpus=X

2006-08-22 Thread Jimi Xenidis
On Aug 21, 2006, at 8:12 PM, Amos Waterland wrote: Add support for the nosmp and maxcpus=X command line options, and address Hollis' concerns about comments, prototypes, and panic messages. thanks Amos, pushed. I had to follow it with a workaround for a Xen assumption so domain creation

[XenPPC] making xen tools on dom0 can be slow

2006-08-22 Thread Maria Butrico
This was discussed yesterday and it was suggested that I should enter a bug for this. Since then I have done a few experiments: By default dom0 has 64M. Under these condition make tools takes 24 minutes on a js20. make[1]: Leaving directory `/home/j9/xen-ppc/tools' real24m1.321s user

[XenPPC] [xenppc-unstable] [POWERPC] Take all secondary processors offline after they are enumerated

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID 13d64dec47117e45d04e934f90a96eb042d7bf41 # Parent e65f030855fb11b708332a1f0453d33659b499a8 [POWERPC] Take all secondary processors offline after they are enumerated Xen assumes that an online CPU is a schedualable CPU, but we

[XenPPC] [xenppc-unstable] [POWERPC] Enable SMP, smp_processor_id, for_each_cpu, nosmp, maxcpus=X

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID e65f030855fb11b708332a1f0453d33659b499a8 # Parent 326e6736d92bf8079ff360292aeeaef3b2958bb4 [POWERPC] Enable SMP, smp_processor_id, for_each_cpu, nosmp, maxcpus=X Add support for the nosmp and maxcpus=X command line options, and

[XenPPC] [xenppc-unstable] [POWERPC] Explain the RMA values a little more

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID 6eccd4911e6c084bcc3d8bc1de8bbdb6e343f132 # Parent 13d64dec47117e45d04e934f90a96eb042d7bf41 [POWERPC] Explain the RMA values a little more Since I did not understand them myself. Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]

Re: [XenPPC] making xen tools on dom0 can be slow

2006-08-22 Thread Hollis Blanchard
On Tue, 2006-08-22 at 11:48 -0400, Maria Butrico wrote: By default dom0 has 64M. Under these condition make tools takes 24 minutes on a js20. Wow, that's terrible. Just as a data point, is the time more reasonable if you copy the source first then build locally? -- Hollis Blanchard IBM

Re: [XenPPC] [PATCH] Fix domU device tree creation for JS20/1

2006-08-22 Thread Hollis Blanchard
On Mon, 2006-08-21 at 19:34 -0400, Maria Butrico wrote: Summary: Fix device tree creation for domU for js20/1 under SLOF The device tree of dom0 on js20 and js21 with SLOF does not have the cpus' d and i cache sets nor does it have the l2 cache subdirectory. Hi Maria, please try this

Re: [XenPPC] making xen tools on dom0 can be slow

2006-08-22 Thread Maria Butrico
Maria Butrico wrote: This was discussed yesterday and it was suggested that I should enter a bug for this. Since then I have done a few experiments: By default dom0 has 64M. Under these condition make tools takes 24 minutes on a js20. make[1]: Leaving directory `/home/j9/xen-ppc/tools' real

Re: [XenPPC] RFC: xencomm - linux side

2006-08-22 Thread Hollis Blanchard
On Tue, 2006-08-22 at 09:42 +0200, Tristan Gingold wrote: Le Lundi 21 Août 2006 21:07, Hollis Blanchard a écrit : On Mon, 2006-08-21 at 17:18 +0200, Tristan Gingold wrote: I am posting the linux xencomm code for review. I'd plan to submit soon unless comments/remarks. NAK. I'm still

Re: [XenPPC] RFC: xencomm - linux side

2006-08-22 Thread Hollis Blanchard
I apologize for my mailer line-wrapping the patch as I quote it below. On Mon, 2006-08-21 at 17:18 +0200, Tristan Gingold wrote: diff -r b7db009d622c linux-2.6-xen-sparse/drivers/xen/Kconfig --- a/linux-2.6-xen-sparse/drivers/xen/Kconfig Mon Aug 21 09:41:24 2006 +0200 +++

Re: [XenPPC] [PATCH] Fix domU device tree creation for JS20/1

2006-08-22 Thread Hollis Blanchard
On Tue, 2006-08-22 at 11:31 -0500, Hollis Blanchard wrote: Hi Maria, please try this patch. It's a little noisy (I made printing work for better debugging), but if it works for you I'll split it up and check it in. Thanks for testing, Maria. I've committed and pushed this patch, so you

[XenPPC] [xenppc-unstable] [XEND][POWERPC] remove python warning

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Hollis Blanchard [EMAIL PROTECTED] # Node ID e0973ea10547390bb50722d7622edf5adb2e47de # Parent 7a77cf4a7428fff092aa94226ed29a6e333c56e7 [XEND][POWERPC] remove python warning Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] --- tools/python/xen/xend/FlatDeviceTree.py

[XenPPC] [xenppc-unstable] [XEND][POWERPC] copy all cpu properties from system device tree

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Hollis Blanchard [EMAIL PROTECTED] # Node ID b985b2e85bf343f136ec2ceb55176edb62832f81 # Parent e0973ea10547390bb50722d7622edf5adb2e47de [XEND][POWERPC] copy all cpu properties from system device tree - fixes problem with newer versions of SLOF firmware, which don't

[XenPPC] [xenppc-unstable] [XEND][POWERPC] nicely display flat device tree

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Hollis Blanchard [EMAIL PROTECTED] # Node ID 7a77cf4a7428fff092aa94226ed29a6e333c56e7 # Parent 6eccd4911e6c084bcc3d8bc1de8bbdb6e343f132 [XEND][POWERPC] nicely display flat device tree Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] ---

[XenPPC] Fwd: [Xen-devel] 3.0.3 freeze

2006-08-22 Thread Hollis Blanchard
The code that we have upstream in xen-unstable right now will not successfully launch a domU, and because those changes will be relatively invasive (especially splitting xc_linux_build()), I will not be trying to fix that before 3.0.3 is released (which will likely be weeks at least). I don't

[XenPPC] [xenppc-unstable] [merge] conflict

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID e06e2cca9f39d56344ec96b90ad4a2405b247996 # Parent f2527015891cfd68f4576a8c63d3ee60e99841e2 # Parent b985b2e85bf343f136ec2ceb55176edb62832f81 [merge] conflict --- tools/python/xen/xend/FlatDeviceTree.py | 87

[XenPPC] [xenppc-unstable] [POWERPC] Find all of memory and feed all the heaps

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID f2527015891cfd68f4576a8c63d3ee60e99841e2 # Parent 6eccd4911e6c084bcc3d8bc1de8bbdb6e343f132 [POWERPC] Find all of memory and feed all the heaps This code walks the OF dev tree, finding end-of-memory and memory holes. All memory

[XenPPC] RMA and Real memory

2006-08-22 Thread Jimi Xenidis
Currently when we create a domain we immediately allocate its RMA. Previously we allowed the xend tools to fail when allocating more memory. However, when the tools probe to see if there is enuf memory to allocate the expected failing one it goes after the balloon driver. specific example:

[XenPPC] [PATCH] [XEND] abstract architecture-specific bits in image.py

2006-08-22 Thread Hollis Blanchard
Since this patch wasn't committed, the shadow2 changes created conflicts. Here is the respin. Note that I have not tested with shadow2, but as you can see below the math doesn't need to be so complicated. Ewan, please apply or comment. [XEND] abstract architecture-specific bits in image.py -

[XenPPC] [xenppc-unstable] [XEND][POWERPC] fix typo

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Hollis Blanchard [EMAIL PROTECTED] # Node ID 5ec3af32d347a058f6939fb9b13c0cb2d6247566 # Parent e06e2cca9f39d56344ec96b90ad4a2405b247996 [XEND][POWERPC] fix typo Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] --- tools/python/xen/xend/FlatDeviceTree.py |2 +- 1

[XenPPC] [xenppc-unstable] [XEND][POWERPC] correct shadow2 merge conflict

2006-08-22 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Hollis Blanchard [EMAIL PROTECTED] # Node ID 8fa42dd4c92a1e3c27e20fc5225edaa49bfb4972 # Parent 5ec3af32d347a058f6939fb9b13c0cb2d6247566 [XEND][POWERPC] correct shadow2 merge conflict Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] ---