Re: [XenPPC] Launching DomU crashes Xen in xen-unstable
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 Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Check for NULL source pointer
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
instructions).
Nice catch, thanks.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] What does the PAPR macro?
On Mar 28, 2007, at 2:39 PM, Christian Ehrhardt wrote: Hi, 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 Xen. 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 right? Nope -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
