Re: [XenPPC] [PATCH 0/10][TOOLS][XM-TEST] [v3] Update xm-test to support new architectures
On Mon, Oct 23, 2006 at 02:55:28PM +1000, Tony Breeds wrote: On Fri, Oct 20, 2006 at 01:19:55PM +1000, Tony Breeds wrote: Hi All, These patches update the xm-test code to be more easily portable to new architecture. This focus of this endeavor is PPC but I believe that IA64 also benefits. Hi Ewan, Any feedback on these patches, or an idea if when/if they'll be merged? Patches 3 - 9 look OK. Rather than take 1 and 2 directly, I've reworked that bit of the build system as we discussed, so that xm-test.xensource.com will host a known-good version of the buildroot source. I've also changed things so that the initrd gets the architecture in the name, so that make existing continues to work (your patches don't add make existing support for PPC, AFAIK). I'll reply to patch 10 in a sec. I'll push all these things when the new ramdisks are built and uploaded -- today, hopefully. xm-test has deserved its One Point Oh for a long time now, so I'll be bumping the version number too. Thanks for all your hard work, Ewan. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 10/10][TOOLS][XM-TEST] Fix Memory assumptions in the create tests
On Fri, Oct 20, 2006 at 01:22:31PM +1000, Tony Breeds wrote: Fix Memory assumptions in the create tests. Use the architecture specified idea of minimum memory. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- [Snip] diff -r 69035d8a5f2a -r 2854ceda351e tools/xm-test/tests/create/16_create_smallmem_neg.py --- a/tools/xm-test/tests/create/16_create_smallmem_neg.pyThu Oct 19 17:01:02 2006 +1000 +++ b/tools/xm-test/tests/create/16_create_smallmem_neg.pyThu Oct 19 17:02:40 2006 +1000 @@ -3,11 +3,11 @@ # Copyright (C) International Business Machines Corp., 2005 # Author: Dan Smith [EMAIL PROTECTED] +import re from XmTestLib import * -# This is under the default lower limit of 32 and we expect this test -# to fail. 16MBs isn't enough for the -xen kernel. -MEM = 16 +# Create a domaain without enough memory. +MEM = minSafeMem() - 1 I'm not convinced by this one. Just because 32 MiB is known to be safe, that doesn't mean that 31 MiB will cause the domain to crash. The 16 MiB value is deliberately _far_ too small, so that the OOM killer kicks in, and the console runaway is detected. I don't want this test to intermittently succeed, even if it is a negative test -- it makes the results hard to analyse. Is the 16 MiB value a problem for PPC, or were you deliberately trying to test that 63 MiB failed on that platform? We could add another arch-specific option -- tooLittleMem() or something -- or we could just leave this value at 16 MiB. Ewan. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Status of xvd and problems with sd.
On PPC we have the following problem with xm-test: http://wiki.xensource.com/xenwiki/XenFaq#head- baa7000e8fc28fd168650114dd2741b7f21da8fa Where we are told: all you need to do is disable the entire scsi subsystem This is undesirable since our (the XenPPC Team) goal is to have one Linux image to run everywhere. We could switch over all the xm-tests to use xvd (Xen Virtual Block Device), but before we do that we'd like to know what the support for xvd is and what if any issues/opinion are there with doing this? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] VIO Block and Xm-Test
On Oct 23, 2006, at 2:56 AM, Tony Breeds wrote: Hi all, I'm slowly working my way through a default run on xm-test on my JS20 trying to determine if the tests that fail represent real problems with xen on PPC, or if they're showing problems with the tests themselves. By correcting some of the create/* tests (patches posted to xen-devel) XenPPC now passes that whole group. In looking at the block-* tests, I see that the failures are due to the domU kernel including scsi support, which then causes a conflict on major number 8, resulting in a lot of failures in xm-test. hmm.. If I try to do this manually, I get: Registering block device major 8 register_blkdev: cannot get major 8 for sd xen_blk: can't get major 8 with name sd vbd vbd-2065: 19 xlvbd_add at /local/domain/0/backend/vbd/1/2065 The problem is described in: http://wiki.xensource.com/xenwiki/XenFaq#head- baa7000e8fc28fd168650114dd2741b7f21da8fa Where we are told: all you need to do is disable the entire scsi subsystem GTFOOH! (said in my best soprano) There has to be a better way! [snip] I'd like to know how everyone feels about creating a make xen_domu_config target which turns of the driver that aren't needed? I think it is unacceptable. Seriously, it is really important to XenPPC that the same kernel image work everywhere Or alternatively suggestions on how to keep a unified kernel image that works? One alternative is to use the ide devices $ xm block-attach 3 file:/root/disk2 hdb2 w Works just fine, for disks. There is also the xvd (Xen Virtual Block Device) which can be attached using xen major 20 $ xm block-attach 6 file:/root/disk2 xvda w Which translates into (202,0), which is lanana blessed: http://www.be.kernel.org/pub/linux/docs/lanana/device-list/ devices-2.6+.txt I had to: mknod /dev/xvda b 202 0 to be able to mount it. I do not know what the official/current Xen support for xvd, but it is a good question, I'll ask. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [TOOLS][POWERPC] use python quad encoding for 2 cell devtree values
Is this still an issue? Have you investigated more? -- Hollis Blanchard IBM Linux Technology Center On Wed, 2006-10-18 at 18:43 -0400, Maria Butrico wrote: I cannot successfully make a libos domain with 2212M (2G+64). I also cannot make one with 1024M.With 1024M the libos terminates, with 2212 it traps. There is no reason to believe that libos has code to handle any of that so this is not terribly surprising. What intrigues me is that the in 1024 case xen terminated the domain, or so it looks at first glance and in the second case it does as well.I doubt I can be quick enough to attach the debugger and see why it trapped. I tested on one of 8G JS21. (my libos is itself not necessarily in a stable state. I was working on something else.) The console output was illuminating (XEN) allocated RMA for Dom[1]: 0x2000[0x400] (XEN) Domain[1].0: initializing (XEN) allocated RMA for Dom[2]: 0x2000[0x400] (XEN) Domain[2].0: initializing (XEN) allocated RMA for Dom[3]: 0x2000[0x400] (XEN) Domain[3].0: initializing (XEN) allocated RMA for Dom[4]: 0x2000[0x400] (XEN) Domain[4].0: initializing (XEN) allocated RMA for Dom[5]: 0x2000[0x400] (XEN) Domain[5].0: initializing (XEN) allocated RMA for Dom[6]: 0x2000[0x400] (XEN) Domain[6].0: initializing :) There is nothing unusual in /var/xen ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 10/10][TOOLS][XM-TEST] Fix Memory assumptions in the create tests
On Mon, Oct 23, 2006 at 11:55:22AM +0100, Ewan Mellor wrote: I'm not convinced by this one. Just because 32 MiB is known to be safe, that doesn't mean that 31 MiB will cause the domain to crash. The 16 MiB value is deliberately _far_ too small, so that the OOM killer kicks in, and the console runaway is detected. Okay, that makes more sense. I don't want this test to intermittently succeed, even if it is a negative test -- it makes the results hard to analyse. Is the 16 MiB value a problem for PPC, or were you deliberately trying to test that 63 MiB failed on that platform? PPC will fail for any memory value 64M, so 16 or 63 makes little difference. I probably should haev said this in the commit message but I changed this test to use minSafeMem() to be consistent with the other changes I made. We could add another arch-specific option -- tooLittleMem() or something -- or we could just leave this value at 16 MiB. Okay leaving it set at 16MiB, is probably the right thing. If we get to a state the an architecture or OS needs to vary it we can look at something like tooLittleMem() then. Yours Tony linux.conf.au http://linux.conf.au/ || http://lca2007.linux.org.au/ Jan 15-20 2007 The Australian Linux Technical Conference! ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [Xen-devel] Re: [XenPPC] [PATCH 0/10][TOOLS][XM-TEST] [v3] Update xm-test to support new architectures
On Mon, Oct 23, 2006 at 11:48:54AM +0100, Ewan Mellor wrote: Patches 3 - 9 look OK. Rather than take 1 and 2 directly,?I've reworked that bit of the build system as we discussed, so that xm-test.xensource.com will host a known-good version of the buildroot source. Great. I included them for the sake of completeness, and to take the urgency off you updateing xm-test.xensource.com. :) Also if you have any difficulty building a cross compiled initrd for PPC give me a yell. I've also changed things so that the initrd gets the architecture in the name, so that make existing continues to work (your patches don't add make existing support for PPC, AFAIK). What make you think that make existing wont work, I've been doing INITRD=http://localhost/xm-test/ make existing quite often with no problems, or is that not what you meant. Either way includeing the architecture in the initrd is nice. I'll reply to patch 10 in a sec. Thanks. I'll push all these things when the new ramdisks are built and uploaded -- today, hopefully. Excellent. xm-test has deserved its One Point Oh for a long time now, so I'll be bumping the version number too. Thanks for all your hard work, You're welcome, all I did was build on the work of the xm-test authors. Yours Tony linux.conf.au http://linux.conf.au/ || http://lca2007.linux.org.au/ Jan 15-20 2007 The Australian Linux Technical Conference! ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend start error
Hollis,
Your comment on upgrading kernel with
Xen seems to be the key. I tried Maria's tree for linux and xen tree and
xend start; xm list doesn't give an error message.
David Daly
Research Staff Member
32-003 IBM T.J. Watson Research Center
Yorktown Heights, NY, 10958
(914) 945-1845, T/L 862-1845
[EMAIL PROTECTED]
10/23/2006 06:19 PM
To
Hao Yu/Watson/[EMAIL PROTECTED]
cc
Xen-ppc-devel@lists.xensource.com, Edi
Shmueli/Watson/[EMAIL PROTECTED], David M Daly/Watson/[EMAIL PROTECTED], Doron Shiloach/Watson/[EMAIL PROTECTED]
Subject
Re: [XenPPC] xend start error
On Fri, 2006-10-20 at 11:04 -0400, Hao Yu wrote:
Hi ,
On our js21 blade running xen, we encountered a problem.
What we did:
cso83:/etc/xen # xend start
cso83:/etc/xen # xm list
Error: Error connecting to xend: No such file or directory. Is
xend
running?
cso83:/etc/xen # tail -25 /var/log/xen/xend.log
Error: (22, 'Invalid argument')
[2006-10-20 11:03:05 xend 8097] INFO (SrvDaemon:190) Xend stopped
due to
signal 15.
[2006-10-20 11:03:07 xend 8116] INFO (SrvDaemon:283) Xend Daemon started
[2006-10-20 11:03:07 xend 8116] INFO (SrvDaemon:287) Xend changeset:
Wed
Oct 11 13:01:31 2006 -0400 12202:e7cb3aefc233.
[2006-10-20 11:03:07 xend 8116] ERROR (SrvDaemon:297) Exception starting
xend ((22, 'Invalid argument'))
Traceback (most recent call last):
File //usr/lib/python/xen/xend/server/SrvDaemon.py,
line 291, in run
servers = SrvServer.create()
File //usr/lib/python/xen/xend/server/SrvServer.py,
line 108, in create
root.putChild('xend', SrvRoot())
File //usr/lib/python/xen/xend/server/SrvRoot.py,
line 40, in __init__
self.get(name)
File //usr/lib/python/xen/web/SrvDir.py, line 82,
in get
val = val.getobj()
File //usr/lib/python/xen/web/SrvDir.py, line 52,
in getobj
self.obj = klassobj()
File //usr/lib/python/xen/xend/server/SrvDomainDir.py,
line 39, in __init__
self.xd = XendDomain.instance()
File //usr/lib/python/xen/xend/XendDomain.py, line
636, in instance
inst.init()
File //usr/lib/python/xen/xend/XendDomain.py, line
76, in init
self._add_domain(
File //usr/lib/python/xen/xend/XendDomain.py, line
139, in xen_domains
domlist = xc.domain_getinfo()
Error: (22, 'Invalid argument')
We wonder what the problem could be?
Doesn't look like there's much in the domctl path that returns EINVAL.
Did you recently upgrade Xen? If so, make sure you install a newer
kernel and tools.
Do you see any errors when you run 'dmesg' in Linux?
--
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] xen_maple_defconfig fails to boot on bare metal
Compiling the current code from linux-ppc-2.6.hg with xen_maple_defconfig and booting on both JS20 and JS21 produces this: PID hash table entries: 4096 (order: 12, 32768 bytes) Maple: Found RTC at IO 0x1070 cpu 0x0: Vector: 300 (Data Access) at [c0002ffe3b60] pc: c0515128: .loopback_init+0x228/0x280 lr: c0009348: .init+0x1d8/0x430 sp: c0002ffe3de0 msr: 90009032 dar: 30 dsisr: 4000 current = 0xc00277fb47f0 paca= 0xc0538100 pid = 1, comm = swapper The tip is: changeset: 33287:968ced1469e8 tag: tip user:Jimi Xenidis [EMAIL PROTECTED] date:Tue Oct 17 17:03:31 2006 -0400 summary: [LINUX][XEN][POWERPC] remove mpic pointer hack. I'll debug this soon unless somebody beats me to it. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Enable SMP and IPIs
This patch enables SMP and IPIs. It works reliably on JS20 and JS21
blades. It is not quite ready for submission, but I would greatly
appreciate any comments.
Note that the flurry of IPIs generated by domain creation seems to be a
waste of time. Xen on x86 doesn't actually to do anything in response
to them, so I have made Xen on PPC properly deliver the event check but
then do nothing as well. Comments?
The important thing this patch is missing is the ability to invoke
functions on a remote CPU, and I have left it out because I am not yet
happy with the convention, which is to grab a lock, put the target
address in a single global shared variable, invoke a memory barrier, and
send the IPI. I am hoping to avoid a lock around that operation by
making a per-IPI-destination-CPU structure with lock, address, and ack
fields. Comments?
---
changeset : cc0cd5518e10
machines: cso103 kpblade1 cso91
pass: 35
fail: 0
transient : 0
total : 35
reliability : 100.0%
---
arch/powerpc/mpic.c|9 ---
arch/powerpc/mpic_init.c | 42 +
arch/powerpc/setup.c | 40
arch/powerpc/smp.c | 59 -
include/asm-powerpc/mach-default/irq_vectors.h | 11 ++--
include/asm-powerpc/smp.h | 10
6 files changed, 136 insertions(+), 35 deletions(-)
diff -r 3dfeb3e4a03f xen/arch/powerpc/mpic.c
--- a/xen/arch/powerpc/mpic.c Fri Oct 13 11:00:32 2006 -0400
+++ b/xen/arch/powerpc/mpic.c Mon Oct 23 22:57:51 2006 -0400
@@ -27,10 +27,6 @@
#define alloc_bootmem(x) xmalloc_bytes(x)
-#define request_irq(irq, handler, f, devname, dev_id) \
-panic(IPI requested: %d: %p: %s: %p\n, irq, handler, devname, dev_id)
-
-typedef int irqreturn_t;
#define IRQ_NONE (0)
#define IRQ_HANDLED(1)
@@ -96,11 +92,6 @@ typedef int irqreturn_t;
#endif
#include asm/mpic.h
#include asm/smp.h
-
-static inline void smp_message_recv(int msg, struct pt_regs *regs)
-{
-return;
-}
#ifdef DEBUG
#define DBG(fmt...) printk(fmt)
diff -r 3dfeb3e4a03f xen/arch/powerpc/mpic_init.c
--- a/xen/arch/powerpc/mpic_init.c Fri Oct 13 11:00:32 2006 -0400
+++ b/xen/arch/powerpc/mpic_init.c Mon Oct 23 15:32:55 2006 -0400
@@ -358,6 +358,43 @@ static struct hw_interrupt_type *share_m
#endif
+static inline struct mpic * mpic_from_ipi(unsigned int ipi)
+{
+ return container_of(irq_desc[ipi].handler, struct mpic, hc_ipi);
+}
+
+static unsigned int mpic_startup_ipi(unsigned int irq)
+{
+printk(%s\n, __func__);
+struct mpic *pic = mpic_from_ipi(irq);
+pic-hc_ipi.enable(irq);
+return 0;
+}
+
+int request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *, struct cpu_user_regs *),
+ unsigned long irqflags, const char * devname, void *dev_id)
+{
+int retval;
+struct irqaction *action;
+
+printk(%s: %d: %p: %s: %p\n, __func__, irq, handler, devname, dev_id);
+
+action = xmalloc_bytes(sizeof(struct irqaction));
+if (!action)
+ BUG();
+
+action-handler = (void (*)(int, void *, struct cpu_user_regs *))handler;
+action-name = devname;
+action-dev_id = dev_id;
+
+retval = setup_irq(irq, action);
+if (retval)
+ BUG();
+
+return retval;
+}
+
struct hw_interrupt_type *xen_mpic_init(struct hw_interrupt_type *xen_irq)
{
unsigned int isu_size;
@@ -397,6 +434,11 @@ struct hw_interrupt_type *xen_mpic_init(
hit = share_mpic(mpic-hc_irq, xen_irq);
printk(%s: success\n, __func__);
+
+mpic-hc_ipi.ack = xen_irq-ack;
+mpic-hc_ipi.startup = mpic_startup_ipi;
+mpic_request_ipis();
+
return hit;
}
diff -r 3dfeb3e4a03f xen/arch/powerpc/setup.c
--- a/xen/arch/powerpc/setup.c Fri Oct 13 11:00:32 2006 -0400
+++ b/xen/arch/powerpc/setup.c Fri Oct 13 19:00:34 2006 -0400
@@ -37,6 +37,7 @@
#include xen/keyhandler.h
#include acm/acm_hooks.h
#include public/version.h
+#include asm/mpic.h
#include asm/processor.h
#include asm/desc.h
#include asm/cache.h
@@ -88,6 +89,8 @@ struct ns16550_defaults ns16550;
extern char __per_cpu_start[], __per_cpu_data_end[], __per_cpu_end[];
+static struct domain *idle_domain;
+
volatile struct processor_area * volatile global_cpu_table[NR_CPUS];
int is_kernel_text(unsigned long addr)
@@ -159,8 +162,6 @@ static void percpu_free_unused_areas(voi
static void __init start_of_day(void)
{
-struct domain *idle_domain;
-
init_IRQ();
scheduler_init();
@@ -174,23 +175,6 @@ static void __init start_of_day(void)
/* for some reason we need to set our own bit in the thread map */
cpu_set(0, cpu_sibling_map[0]);
-
-percpu_free_unused_areas();
-
-{
-/* FIXME: Xen assumes that an online CPU is a schedualable
- * CPU, but we just are not there yet. Remove this fragment when
- * scheduling processors
