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
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] 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
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 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] 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 debug print in boot_of_alloc_init
On Mon, 2007-01-08 at 15:46 -0700, 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.
>
> 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);
>
> DBG("%s: marking 0x%x - 0x%lx\n", __func__,
> -pg << PAGE_SHIFT, start);
> +pg << PAGE_SHIFT, start << PAGE_SHIFT);
>
> start >>= PAGE_SHIFT;
> while (pg < MEM_AVAILABLE_PAGES && pg < start) {
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 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.
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
[XenPPC] [PATCH] fix debug print in boot_of_alloc_init
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.
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);
DBG("%s: marking 0x%x - 0x%lx\n", __func__,
-pg << PAGE_SHIFT, start);
+pg << PAGE_SHIFT, start << PAGE_SHIFT);
start >>= PAGE_SHIFT;
while (pg < MEM_AVAILABLE_PAGES && pg < start) {
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
RE: [XenPPC] systemsim-gpul problems
> -Original Message- > From: Jimi Xenidis [mailto:[EMAIL PROTECTED] > > This one does not make sense, is there garage that matches this in > your available property? > > boot_of_alloc_init: marking 0x0 - 0x400^M > This particular print is actually gone in top of tree Xen. I had been playing with different changesets and the trace I put in the email was from an old version that had four regions marked in boot_of_alloc_init. Stuart ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Move lots of memory logic earlier
# 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.
Removing our custom allocator is important to simplify the upcoming
multiboot2 conversion.
- We also handle arbitrary-sized properties now, instead of
probably-large-enough fixed-sized buffers.
- This will also be needed to support non-Open Firmware systems (though the
firmware-specific interface was not the focus of this patch).
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff -r dbc74db14a4b -r e1ee8b26c15d xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Dec 12 14:35:07 2006 -0600
+++ b/xen/arch/powerpc/boot_of.cMon Jan 08 16:03:09 2007 -0600
@@ -13,13 +13,14 @@
* along with this program; if not, write to the Free Software
* Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
- * Copyright (C) IBM Corp. 2005, 2006
+ * Copyright IBM Corp. 2005, 2006, 2007
*
* Authors: Jimi Xenidis <[EMAIL PROTECTED]>
* Hollis Blanchard <[EMAIL PROTECTED]>
*/
#include
+#include
#include
#include
#include
@@ -35,19 +36,32 @@
#include "oftree.h"
#include "rtas.h"
+typedef ulong (*of_walk_fn)(int node, void *arg);
+
/* Secondary processors use this for handshaking with main processor. */
volatile unsigned int __spin_ack;
static ulong of_vec;
static ulong of_msr;
static int of_out;
-static ulong eomem;
-
-#define MEM_AVAILABLE_PAGES ((32 << 20) >> PAGE_SHIFT)
-static DECLARE_BITMAP(mem_available_pages, MEM_AVAILABLE_PAGES);
+static uint addr_cells;
+static uint size_cells;
+
+ulong xenheap_size;
+ulong xenheap_phys_end;
extern char builtin_cmdline[];
extern struct ns16550_defaults ns16550;
+
+extern ulong nr_pages;
+extern ulong bitmap_addr;
+
+/*
+ * opt_xenheap_megabytes: Size of Xen heap in megabytes, excluding the
+ * page_info table and allocation bitmap.
+ */
+static unsigned int opt_xenheap_megabytes = XENHEAP_DEFAULT_MB;
+integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#undef OF_DEBUG
#undef OF_DEBUG_LOW
@@ -72,6 +86,11 @@ struct of_service {
u32 ofs_nargs;
u32 ofs_nrets;
u32 ofs_args[10];
+};
+
+struct membuf {
+ulong start;
+ulong size;
};
static int bof_chosen;
@@ -377,234 +396,204 @@ static int __init of_open(const char *de
return rets[0];
}
-static void boot_of_alloc_init(int m, uint addr_cells, uint size_cells)
-{
-int rc;
-uint pg;
-uint a[64];
-int tst;
-u64 start;
-u64 size;
-
-rc = of_getprop(m, "available", a, sizeof (a));
-if (rc > 0) {
-int l = rc / sizeof(a[0]);
-int r = 0;
-
-#ifdef OF_DEBUG
-{
-int i;
-of_printf("avail:\n");
-for (i = 0; i < l; i += 4)
-of_printf(" 0x%x%x, 0x%x%x\n",
- a[i], a[i + 1],
- a[i + 2] ,a[i + 3]);
-}
-#endif
-
-pg = 0;
-while (pg < MEM_AVAILABLE_PAGES && r < l) {
-ulong end;
-
-start = a[r++];
-if (addr_cells == 2 && (r < l) )
-start = (start << 32) | a[r++];
-
-size = a[r++];
-if (size_cells == 2 && (r < l) )
-size = (size << 32) | a[r++];
-
-end = ALIGN_DOWN(start + size, PAGE_SIZE);
-
-start = ALIGN_UP(start, PAGE_SIZE);
-
-DBG("%s: marking 0x%x - 0x%lx\n", __func__,
-pg << PAGE_SHIFT, start);
-
-start >>= PAGE_SHIFT;
-while (pg < MEM_AVAILABLE_PAGES && pg < start) {
-set_bit(pg, mem_available_pages);
-pg++;
+
+static ulong boot_of_alloc(ulong size)
+{
+return alloc_boot_pages(size >> PAGE_SHIFT, 1) << PAGE_SHIFT;
+}
+
+static ulong of_walk_type(int root, const char *type, of_walk_fn fn, void *arg)
+{
+int child;
+ulong rc;
+
+child = of_getchild(root);
+while (child > 0) {
+int proplen;
+char *propval;
+
+proplen = of_getprop(child, "device_type", NULL, 0);
+if (proplen > 0) {
+propval = alloca(proplen);
+proplen = of_getprop(child, "device_type", propval, proplen);
+if (!strcmp(propval, type)) {
+/* if the type matches, call the callback */
+rc = fn(child, arg);
+if (rc)
+return rc;
}
-
-pg = end >> PAGE_SHIFT;
-}
-}
-
-/* Now make sure we mark our own memory */
-pg = (ulong)_start >> PAGE_SHIFT;
-start = (ulong)_end >> PAGE_SHIFT;
-
-DBG("%s: marking 0x%x - 0x%lx\n", __func__,
-pg << PAGE_SHIFT, start <<
