[XenPPC] Re: xencomm porting and "inline" handles
Le Jeudi 28 Septembre 2006 17:07, Hollis Blanchard a écrit :
> On Thu, 2006-09-28 at 08:27 +0200, Tristan Gingold wrote:
> > Le Mercredi 27 Septembre 2006 17:10, Hollis Blanchard a écrit :
> > > On Wed, 2006-09-27 at 08:19 +0200, Tristan Gingold wrote:
> > > > Le Mardi 26 Septembre 2006 20:23, Hollis Blanchard a écrit :
> > > > > On Tue, 2006-09-26 at 10:04 +0200, Tristan Gingold wrote:
> > > > > > After more work, inline xencomm is not that magic: it doesn't
> > > > > > work for modules which are loaded in virtual memory. So I have
> > > > > > to use mini xencomm at least for modules.
> > > > >
> > > > > What's the problem with modules? Their text/data isn't physically
> > > > > contiguous, but where exactly is the problem?
> > > >
> > > > Inline xencomm only works for physically contiguous area because only
> > > > the base address is passed. Therefore it doesn't work for modules.
> > >
> > > I understand that; please explain exactly what about the modules isn't
> > > working.
> > >
> > > For example, the stack used in kernel modules is still physically
> > > contiguous, so using stack-allocated data structures should work fine.
> > > However, making hypercalls directly using global data structures
> > > wouldn't work. However, the "inline" code is only being used for the
> > > hypercalls that could be made early. Is that the problem? Please
> > > identify the specific issue(s).
> >
> > Yes, some hypercalls data are global data.
> > Sorry, I was not specific enough!
>
> Hi Tristan, *which* hypercalls? Please identify some specific lines of
> code that are causing the problems...
This issue was at least hit in drivers/xen/netback/netback.c:
static void net_rx_action(unsigned long unused)
{
netif_t *netif = NULL;
s8 status;
u16 id, irq, flags;
netif_rx_response_t *resp;
multicall_entry_t *mcl;
struct sk_buff_head rxq;
struct sk_buff *skb;
int notify_nr = 0;
int ret;
int nr_frags;
int count;
unsigned long offset;
/*
* Putting hundreds of bytes on the stack is considered rude.
* Static works because a tasklet can only be on one CPU at any time.
*/
static multicall_entry_t rx_mcl[NET_RX_RING_SIZE+3];
static mmu_update_t rx_mmu[NET_RX_RING_SIZE];
static gnttab_transfer_t grant_trans_op[NET_RX_RING_SIZE];
static gnttab_copy_t grant_copy_op[NET_RX_RING_SIZE];
static unsigned char rx_notify[NR_IRQS];
static u16 notify_list[NET_RX_RING_SIZE];
static struct netbk_rx_meta meta[NET_RX_RING_SIZE];
Lot's of hypercall parameters in module data segment!
Tristan.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH 0/3][XM-TEST] Updates to xm-test ramdisk code
On Mon, 2006-09-25 at 13:12 +1000, Tony Breeds wrote: > Hi All, > These patches update the ramdisk creation code to be > architecture neutral in preparation for PPC to use the xm-test code. > > Patch summary: > > 1: Instead of using a dated snapshot (which no longer exists) > use buildroot-snapshot. > 2: Remove hardcoded references to i386. > 3: Rename configs/buildroot -> configs/buildroot-i386 > and update Makefiles. > > With patches applied x86 still builds an initrd.img > > Feedback appreciated. Who maintains xm-test and could take a look at these patches? -- 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] xm dump-core
On Sep 28, 2006, at 3:58 PM, Maria Butrico wrote: I can dump part of the core file out but not all. I see a message about connection refused to xend. Yet xend is running.Are there tools for reading the core file? Sorry, not supported yet, not even in our checklist: http://wiki.xensource.com/xenwiki/XenPPC/XMChecklist -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] xm dump-core
I can dump part of the core file out but not all. I see a message about connection refused to xend. Yet xend is running.Are there tools for reading the core file? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] Allow Xen to use RTAS if available
If you wish to actually have Xen reboot you will need to set
crash_debug=n since xen will call out to the debugger if dom0 dies
-JX
On Sep 28, 2006, at 12:40 PM, Xen patchbot-xenppc-unstable wrote:
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID c9bf3af5624b6186e665e6d8d783ff92a5b3afce
# Parent 2aa9a65408bc10594cd2488f6640574f5ea67549
[XEN][POWERPC] Allow Xen to use RTAS if available
If FW provides an RTAS layer, it will be instantiated and Xen will try
to use it for power control (halt, reboot, power-off, etc). Xen will
also communicate to Dom0 (using /xen/power-control in the devtree)
when Xen cannot control power and it is hoped that the domain can,
especially useful for Maple boards running non-RTAS versions of PIBS.
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
xen/arch/powerpc/boot_of.c | 210 +
+---
xen/arch/powerpc/domain.c | 17 ++
xen/arch/powerpc/memory.c | 26 +++-
xen/arch/powerpc/ofd_fixup.c |5
xen/arch/powerpc/rtas.c| 84 ++
xen/arch/powerpc/rtas.h| 34 +
xen/arch/powerpc/setup.c | 15 +-
xen/include/asm-powerpc/debugger.h | 10 +
8 files changed, 321 insertions(+), 80 deletions(-)
diff -r 2aa9a65408bc -r c9bf3af5624b xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Sep 26 14:01:11 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cThu Sep 28 12:34:01 2006 -0400
@@ -32,6 +32,7 @@
#include "exceptions.h"
#include "of-devtree.h"
#include "oftree.h"
+#include "rtas.h"
/* Secondary processors use this for handshaking with main
processor. */
volatile unsigned int __spin_ack;
@@ -68,7 +69,6 @@ static int bof_chosen;
static int bof_chosen;
static struct of_service s;
-extern s32 prom_call(void *arg, ulong rtas_base, ulong func, ulong
msr);
static int __init of_call(
const char *service, u32 nargs, u32 nrets, s32 rets[], ...)
@@ -359,6 +359,14 @@ static int __init of_getparent(int ph)
of_call("parent", 1, 1, rets, ph);
DBG("getparent 0x%x -> 0x%x\n", ph, rets[0]);
+return rets[0];
+}
+
+static int __init of_open(const char *devspec)
+{
+int rets[1] = { OF_FAILURE };
+
+of_call("open", 1, 1, rets, devspec);
return rets[0];
}
@@ -500,7 +508,8 @@ static int save_props(void *m, ofdn_t n,
of_panic("obj array not big enough for 0x%x
\n", sz);
}
actual = of_getprop(pkg, name, obj, sz);
-if (actual > sz) of_panic("obj too small");
+if (actual > sz)
+of_panic("obj too small");
}
if (strncmp(name, name_str, sizeof(name_str)) == 0) {
@@ -512,7 +521,8 @@ static int save_props(void *m, ofdn_t n,
}
pos = ofd_prop_add(m, n, name, obj, actual);
-if (pos == 0) of_panic("prop_create");
+if (pos == 0)
+of_panic("prop_create");
}
result = of_nextprop(pkg, name, name);
@@ -536,10 +546,12 @@ retry:
if (pnext != 0) {
sz = of_package_to_path(pnext, path, psz);
-if (sz == OF_FAILURE) of_panic("bad path\n");
+if (sz == OF_FAILURE)
+of_panic("bad path\n");
nnext = ofd_node_child_create(m, n, path, sz);
-if (nnext == 0) of_panic("out of mem\n");
+if (nnext == 0)
+of_panic("out of mem\n");
do_pkg(m, nnext, pnext, path, psz);
}
@@ -551,7 +563,8 @@ retry:
sz = of_package_to_path(pnext, path, psz);
nnext = ofd_node_peer_create(m, n, path, sz);
-if (nnext <= 0) of_panic("out of space in OFD tree.\n");
+if (nnext <= 0)
+of_panic("out of space in OFD tree.\n");
n = nnext;
p = pnext;
@@ -570,7 +583,8 @@ static int pkg_save(void *mem)
/* get root */
root = of_getpeer(0);
-if (root == OF_FAILURE) of_panic("no root package\n");
+if (root == OF_FAILURE)
+of_panic("no root package\n");
do_pkg(mem, OFD_ROOT, root, path, sizeof(path));
@@ -604,7 +618,8 @@ static int boot_of_fixup_refs(void *mem)
char ofpath[256];
path = ofd_node_path(mem, c);
-if (path == NULL) of_panic("no path to found prop: %s
\n", name);
+if (path == NULL)
+of_panic("no path to found prop: %s\n", name);
rp = of_finddevice(path);
if (rp == OF_FAILURE)
@@ -629,13 +644,15 @@ static int boot_of_fixup_refs(void *mem)
"ref 0x%x\n", name, path, rp, ref);
dp = ofd_node_find(mem, ofpath);
-if (dp <= 0) of_panic("no ofd node for OF node[0x%x]: %
s\n",
- ref, ofpath);
+if (dp <= 0)
+of_panic("no ofd node for OF node[0x%x]: %s\n",
+ ref, ofpath);
ref = dp;
upd = ofd_pro
[XenPPC] [linux-ppc-2.6] [LINUX][POWERPC] Use Xen property to decide if domain can control power
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID c52ba3176a285683f00beaa2e82d2ed39bcedae8
# Parent cae64f65891af6e6f596f96245b7d09b6569078e
[LINUX][POWERPC] Use Xen property to decide if domain can control power
If Xen is not able to control the machine reboot/halt controls it will
create a /xen/power-control property indicating to the domain that it
has been given the capability to try.
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/xen/setup.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff -r cae64f65891a -r c52ba3176a28 arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cMon Sep 18 12:46:10 2006 -0400
+++ b/arch/powerpc/platforms/xen/setup.cThu Sep 28 12:26:59 2006 -0400
@@ -114,8 +114,6 @@ static void __init xen_init_early(void)
is_dom0 = !!(xen_start_info->flags & SIF_INITDOMAIN);
if (is_dom0) {
- xen_reboot_init(&mach_maple_md);
-
ppc_md.pcibios_fixup= mach_maple_md.pcibios_fixup;
ppc_md.pci_get_legacy_ide_irq =
mach_maple_md.pci_get_legacy_ide_irq;
ppc_md.get_boot_time= mach_maple_md.get_boot_time;
@@ -123,9 +121,12 @@ static void __init xen_init_early(void)
ppc_md.get_rtc_time = mach_maple_md.get_rtc_time;
add_preferred_console("ttyS", 0, NULL);
- } else {
+ }
+
+ if (get_property(xen, "power-control", NULL))
+ xen_reboot_init(&mach_maple_md);
+ else
xen_reboot_init(NULL);
- }
/* get the domain features */
setup_xen_features();
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [XEN][POWERPC] Allow Xen to use RTAS if available
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID c9bf3af5624b6186e665e6d8d783ff92a5b3afce
# Parent 2aa9a65408bc10594cd2488f6640574f5ea67549
[XEN][POWERPC] Allow Xen to use RTAS if available
If FW provides an RTAS layer, it will be instantiated and Xen will try
to use it for power control (halt, reboot, power-off, etc). Xen will
also communicate to Dom0 (using /xen/power-control in the devtree)
when Xen cannot control power and it is hoped that the domain can,
especially useful for Maple boards running non-RTAS versions of PIBS.
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
xen/arch/powerpc/boot_of.c | 210 ++---
xen/arch/powerpc/domain.c | 17 ++
xen/arch/powerpc/memory.c | 26 +++-
xen/arch/powerpc/ofd_fixup.c |5
xen/arch/powerpc/rtas.c| 84 ++
xen/arch/powerpc/rtas.h| 34 +
xen/arch/powerpc/setup.c | 15 +-
xen/include/asm-powerpc/debugger.h | 10 +
8 files changed, 321 insertions(+), 80 deletions(-)
diff -r 2aa9a65408bc -r c9bf3af5624b xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Sep 26 14:01:11 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cThu Sep 28 12:34:01 2006 -0400
@@ -32,6 +32,7 @@
#include "exceptions.h"
#include "of-devtree.h"
#include "oftree.h"
+#include "rtas.h"
/* Secondary processors use this for handshaking with main processor. */
volatile unsigned int __spin_ack;
@@ -68,7 +69,6 @@ static int bof_chosen;
static int bof_chosen;
static struct of_service s;
-extern s32 prom_call(void *arg, ulong rtas_base, ulong func, ulong msr);
static int __init of_call(
const char *service, u32 nargs, u32 nrets, s32 rets[], ...)
@@ -359,6 +359,14 @@ static int __init of_getparent(int ph)
of_call("parent", 1, 1, rets, ph);
DBG("getparent 0x%x -> 0x%x\n", ph, rets[0]);
+return rets[0];
+}
+
+static int __init of_open(const char *devspec)
+{
+int rets[1] = { OF_FAILURE };
+
+of_call("open", 1, 1, rets, devspec);
return rets[0];
}
@@ -500,7 +508,8 @@ static int save_props(void *m, ofdn_t n,
of_panic("obj array not big enough for 0x%x\n", sz);
}
actual = of_getprop(pkg, name, obj, sz);
-if (actual > sz) of_panic("obj too small");
+if (actual > sz)
+of_panic("obj too small");
}
if (strncmp(name, name_str, sizeof(name_str)) == 0) {
@@ -512,7 +521,8 @@ static int save_props(void *m, ofdn_t n,
}
pos = ofd_prop_add(m, n, name, obj, actual);
-if (pos == 0) of_panic("prop_create");
+if (pos == 0)
+of_panic("prop_create");
}
result = of_nextprop(pkg, name, name);
@@ -536,10 +546,12 @@ retry:
if (pnext != 0) {
sz = of_package_to_path(pnext, path, psz);
-if (sz == OF_FAILURE) of_panic("bad path\n");
+if (sz == OF_FAILURE)
+of_panic("bad path\n");
nnext = ofd_node_child_create(m, n, path, sz);
-if (nnext == 0) of_panic("out of mem\n");
+if (nnext == 0)
+of_panic("out of mem\n");
do_pkg(m, nnext, pnext, path, psz);
}
@@ -551,7 +563,8 @@ retry:
sz = of_package_to_path(pnext, path, psz);
nnext = ofd_node_peer_create(m, n, path, sz);
-if (nnext <= 0) of_panic("out of space in OFD tree.\n");
+if (nnext <= 0)
+of_panic("out of space in OFD tree.\n");
n = nnext;
p = pnext;
@@ -570,7 +583,8 @@ static int pkg_save(void *mem)
/* get root */
root = of_getpeer(0);
-if (root == OF_FAILURE) of_panic("no root package\n");
+if (root == OF_FAILURE)
+of_panic("no root package\n");
do_pkg(mem, OFD_ROOT, root, path, sizeof(path));
@@ -604,7 +618,8 @@ static int boot_of_fixup_refs(void *mem)
char ofpath[256];
path = ofd_node_path(mem, c);
-if (path == NULL) of_panic("no path to found prop: %s\n", name);
+if (path == NULL)
+of_panic("no path to found prop: %s\n", name);
rp = of_finddevice(path);
if (rp == OF_FAILURE)
@@ -629,13 +644,15 @@ static int boot_of_fixup_refs(void *mem)
"ref 0x%x\n", name, path, rp, ref);
dp = ofd_node_find(mem, ofpath);
-if (dp <= 0) of_panic("no ofd node for OF node[0x%x]: %s\n",
- ref, ofpath);
+if (dp <= 0)
+of_panic("no ofd node for OF node[0x%x]: %s\n",
+ ref, ofpath);
ref = dp;
upd = ofd_prop_add(mem, c, name, &ref, sizeof(ref));
-if (upd <= 0) of_panic("update failed: %s\n", name);
+if (upd <= 0)
+of_panic("update failed: %s\n", name);
#ifdef D
[XenPPC] Re: xencomm porting and "inline" handles
On Thu, 2006-09-28 at 08:27 +0200, Tristan Gingold wrote: > Le Mercredi 27 Septembre 2006 17:10, Hollis Blanchard a écrit : > > On Wed, 2006-09-27 at 08:19 +0200, Tristan Gingold wrote: > > > Le Mardi 26 Septembre 2006 20:23, Hollis Blanchard a écrit : > > > > On Tue, 2006-09-26 at 10:04 +0200, Tristan Gingold wrote: > > > > > After more work, inline xencomm is not that magic: it doesn't work > > > > > for modules which are loaded in virtual memory. So I have to use > > > > > mini xencomm at least for modules. > > > > > > > > What's the problem with modules? Their text/data isn't physically > > > > contiguous, but where exactly is the problem? > > > > > > Inline xencomm only works for physically contiguous area because only the > > > base address is passed. Therefore it doesn't work for modules. > > > > I understand that; please explain exactly what about the modules isn't > > working. > > > > For example, the stack used in kernel modules is still physically > > contiguous, so using stack-allocated data structures should work fine. > > However, making hypercalls directly using global data structures > > wouldn't work. However, the "inline" code is only being used for the > > hypercalls that could be made early. Is that the problem? Please > > identify the specific issue(s). > Yes, some hypercalls data are global data. > Sorry, I was not specific enough! Hi Tristan, *which* hypercalls? Please identify some specific lines of code that are causing the problems... -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
