Re: [XenPPC] [PATCH]fix xencomm_copy_{from, to}_guest.
On Fri, 2007-01-05 at 12:19 +0900, Isaku Yamahata wrote:
fix xencomm_copy_{from, to}_guest.
It should not call paddr_to_maddr() with invalid address.
Thanks Yamahata-san! I've asked Jerone (CCed) to give this a quick test.
Originally this issue was found in xen/ia64 xencomm code and
in fact I didn't test this patch because currently ia64 xencomm forked
from common code. They should be consolidated somehow.
I couldn't agree more. I've posted comments on that before; please let
me know if anybody on the ia64 side has questions about it.
--
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] systemsim-gpul problems
Not sure this sheds any light on the timing problem but it looks like Xen is in it's idle_loop() during the time things are running unexpectedly slow. Stuart -Original Message- From: Hollis Blanchard [mailto:[EMAIL PROTECTED] Sent: Friday, January 05, 2007 1:06 PM To: Yoder Stuart-B08248 Cc: Jimi Xenidis; xen-ppc-devel@lists.xensource.com Subject: RE: [XenPPC] systemsim-gpul problems On Fri, 2007-01-05 at 09:54 -0700, Yoder Stuart-B08248 wrote: 1449668513: (1449502549): IPv4 over IPv4 tunneling driver 1450457186: (1450290832): TCP bic registered 1450527304: (1450360932): NET: Registered protocol family 1 1450557364: (1450390979): NET: Registered protocol family 17 146000: [0]: (PC:0x0042FA80) : 7997.4 Kilo-In... 148000: [0]: (PC:0x0042FA80) : .3 Kilo-In... 15: [0]: (PC:0x004224B0) : .3 Kilo-In... This is interesting because it seems to indicate that we're spending lots of time in Xen (that's a Xen address). nm xen-syms | sort should help you figure out what function that is. -- 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]fix xencomm_copy_{from, to}_guest.
Just quickly tried it out and my js20 blade boots without issue with
this patch.
On Mon, 2007-01-08 at 16:51 -0600, Hollis Blanchard wrote:
On Fri, 2007-01-05 at 12:19 +0900, Isaku Yamahata wrote:
fix xencomm_copy_{from, to}_guest.
It should not call paddr_to_maddr() with invalid address.
Thanks Yamahata-san! I've asked Jerone (CCed) to give this a quick test.
Originally this issue was found in xen/ia64 xencomm code and
in fact I didn't test this patch because currently ia64 xencomm forked
from common code. They should be consolidated somehow.
I couldn't agree more. I've posted comments on that before; please let
me know if anybody on the ia64 side has questions about it.
--
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] fix debug print in boot_of_alloc_init
On Jan 8, 2007, at 5:46 PM, Yoder Stuart-B08248 wrote:
This is a minor bug in a debug print that most likely will never
be seen, as start is typically 0, but it is something I noticed.
thanks, but this patch is incorrect, see below
Signed-off-by: Stuart Yoder [EMAIL PROTECTED]
diff -r db52c7d043bb xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Dec 19 09:20:58 2006 -0500
+++ b/xen/arch/powerpc/boot_of.cMon Jan 08 16:43:09 2007 -0600
@@ -419,7 +419,7 @@ static void boot_of_alloc_init(int m, ui
start = ALIGN_UP(start, PAGE_SIZE);
start is in bytes here
DBG(%s: marking 0x%x - 0x%lx\n, __func__,
-pg PAGE_SHIFT, start);
+pg PAGE_SHIFT, start PAGE_SHIFT);
becomes in pages here
start = PAGE_SHIFT;
while (pg MEM_AVAILABLE_PAGES pg start) {
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
RE: [XenPPC] [PATCH] fix debug print in boot_of_alloc_init
-Original Message- From: Hollis Blanchard [mailto:[EMAIL PROTECTED] Sent: Monday, January 08, 2007 4:55 PM Thanks Stuart. However, the patch I just sent out an hour ago is going to remove this code entirely. :) I haven't checked it in yet though: I'd appreciate it if you could test it on systemsim, and please let me know if you have any comments as well. Hollis, Something is broke with systemsim. Log message is below: 25923: (25925): --- 29591: (29593): OF: Xen/PPC version 3.0-unstable (b08248@) (gcc version 3.4.1) Mon Jan 8 17:30:28 CST 2007 32814: (32817): boot_of_init args: 0x0 0x0 0xf000 0x0 0x0 33540: (33543): boot msr: 0x10003000 36100: (36103): boot_of_init: _start 0040 _end 0088ba18 0x0 38296: (38299): Physical RAM map: WARNING: 39059: GetProp: We didn't find the property device_type in parent /cpus:8 WARNING: 40784: GetProp: We didn't find the property device_type in parent /chosen:27 44858: (44862): : 2000 WARNING: 45883: GetProp: We didn't find the property device_type in parent /options:45 WARNING: 46611: GetProp: We didn't find the property device_type in parent /rtas:50 WARNING: 48337: GetProp: We didn't find the property device_type in parent /systemsim:79 WARNING: 49065: GetProp: We didn't find the property device_type in parent /mambo:83 56459: (56464): max_page: 0x2 57652: (57657): nr_pages: 0x2 59004: (59009): Total memory: 524288 KiB 60652: (60658): searching for 0x4000 bytes for bitmap: WARNING: 61415: GetProp: We didn't find the property device_type in parent /cpus:8 WARNING: 63141: GetProp: We didn't find the property device_type in parent /chosen:27 67193: (67199): : 2000 -- found WARNING: 68781: GetProp: We didn't find the property device_type in parent /options:45 WARNING: 69509: GetProp: We didn't find the property device_type in parent /rtas:50 WARNING: 71234: GetProp: We didn't find the property device_type in parent /systemsim:79 WARNING: 71962: GetProp: We didn't find the property device_type in parent /mambo:83 79660: (79667): couldn't find space for allocator bitmap 80400: (80408): HANG Stuart ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
RE: [XenPPC] [PATCH] fix debug print in boot_of_alloc_init
-Original Message-
From: Jimi Xenidis [mailto:[EMAIL PROTECTED]
start is in bytes here
DBG(%s: marking 0x%x - 0x%lx\n, __func__,
-pg PAGE_SHIFT, start);
+pg PAGE_SHIFT, start PAGE_SHIFT);
becomes in pages here
start = PAGE_SHIFT;
while (pg MEM_AVAILABLE_PAGES pg start) {
I see... Thanks. There was a similar bug (for real) in code
removed by an earlier patch that led me to jump to the
conclusion the same shift was needed there.
Stuart
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Move lots of memory logic earlier
I disagree with what this patch does. On Jan 8, 2007, at 4:03 PM, Hollis Blanchard wrote: # HG changeset patch # User Hollis Blanchard [EMAIL PROTECTED] # Date 1168293789 21600 # Node ID e1ee8b26c15de7afd7dec2d604b00d607e1307f4 # Parent dbc74db14a4b39d359365fcf8257216d968fa269 Move lots of memory logic earlier. - We now require the common boot allocator has been initialized before __start_xen(), and we use that in boot_of.c instead of managing our own. It is far more important that we do as little as possible in boot_of, just enough to know where we are and instantiate any parts of memory that need it. When we are booted with a flattened devtree (via kexec, or some other loader), we will never call into boot_of.c. The custom boot_of allocator is trivial and allows for simple tracking of available memory. Removing our custom allocator is important to simplify the upcoming multiboot2 conversion. how? - We also handle arbitrary-sized properties now, instead of probably-large-enough fixed-sized buffers. this is fine by me, I'm a big fan of alloca()! However, you use: proplen = of_getprop(child, string, NULL, 0); when proplen = of_getproplen(child, string); Is sufficient and defined and used already in this file. - This will also be needed to support non-Open Firmware systems (though the firmware-specific interface was not the focus of this patch). But what is there is designed with non-OF in mind. IMHO this is a step backwards. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
