Re: [XenPPC] Launching DomU crashes Xen in xen-unstable

2007-03-28 Thread Hollis Blanchard
On Tue, 2007-03-27 at 18:03 -0500, Jerone Young wrote:
 (XEN) allocated RMA for Dom[1]: 0x42c00[0x400]
 (XEN) PFN is 0x2c000
 (XEN) BUG at mm.c:134 

This is an embarrassing bug.

The machine address we're trying to map is 0x42c00. That is above
16GB, because the machine has 16GB of RAM plus a 2GB IO hole, meaning
addresses up to 18GB are actually possible.

However, the flag we use to indicate a foreign mapping is the 16GB bit,
0x4. (We unfortunately did not start with bits at the top of the
address space.)

Aside from having Xen pick another bit, we will need a Linux patch
because that bit is hardcoded in some assembly.

Hollis Blanchard
IBM Linux Technology Center

Xen-ppc-devel mailing list

Re: [XenPPC] [PATCH] Check for NULL source pointer

2007-03-28 Thread Hollis Blanchard
On Tue, 2007-03-27 at 19:18 -0400, Amos Waterland wrote:
 While debugging the zImage problem on a JS21, I noticed that DOM0
 bootargs was filled with bogus characters.  I believe something like
 this is necessary.
 Signed-off-by: Amos Waterland [EMAIL PROTECTED]
  ofd_fixup.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 diff -r cc72b77132f9 xen/arch/powerpc/ofd_fixup.c
 --- a/xen/arch/powerpc/ofd_fixup.cWed Mar 21 18:29:49 2007 -0500
 +++ b/xen/arch/powerpc/ofd_fixup.cTue Mar 27 19:13:03 2007 -0400
 @@ -276,7 +276,10 @@ static ofdn_t ofd_chosen_props(void *m, 
   path[1], sizeof (path) - 1);
 -strlcpy(bootargs, cmdline, sizeof(bootargs));
 +memset(bootargs, 0, sizeof(bootargs));
 +if (cmdline) {
 +strlcpy(bootargs, cmdline, sizeof(bootargs));
  bsz = strlen(bootargs) + 1;
  rm = sizeof (bootargs) - bsz;

Scary, it looks like we're doing strlen(NULL) in strlcpy(), which must
be returning a non-0 length (since the memory at 0 actually contains

Nice catch, thanks.

Hollis Blanchard
IBM Linux Technology Center

Xen-ppc-devel mailing list

Re: [XenPPC] What does the PAPR macro?

2007-03-28 Thread Jimi Xenidis

On Mar 28, 2007, at 2:39 PM, Christian Ehrhardt wrote:

I'm curently implementing H_PERFMON and found some code in the file  
arch/powerpc/of_handler/papr.S which is not clear for me by just  
reading it ;)

This is code for the OF stub that we but in Dom0 address space, it  
usually only needs to perform console hcalls, there is no reason to  
add the H_PERFMON hcall to this code, this code runs in a domain NOT  

I guessed this line together for H_PERFMON based on the other  
lines around there, but what would the following line really do?

PAPR(5, 1,papr_h_perfmon, H_PERFMON)

This will create a C callable function (papr_h_perfmon) written in  
assembler that for an hcall that takes 5 arguements and returns a  
single result value.

Is it correct and if not why?

It is correct, but unecessary, please do not bother.

I assume it's some kind of registering xen implemented papr hooks  


Xen-ppc-devel mailing list