[XenPPC] [linux-ppc-2.6] [POWERPC][XEN] Don't leak frame_list and don'r post process gnttab if OP fails
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 8bccc5d192be551cfe12e1c4d38bb49144f980aa
# Parent 5eca8383a521939f0d74e68eaddb049c5057742a
[POWERPC][XEN] Don't leak frame_list and don'r post process gnttab if OP fails
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
---
arch/powerpc/platforms/xen/gnttab.c | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
diff -r 5eca8383a521 -r 8bccc5d192be arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Tue Feb 06 16:21:30 2007 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Tue Feb 06 16:30:08 2007 -0500
@@ -244,10 +244,10 @@ static void gnttab_post_map_grant_ref(
int HYPERVISOR_grant_table_op(unsigned int cmd, void *op, unsigned int count)
{
- void *desc = NULL;
+ void *desc;
void *frame_list = NULL;
int argsize;
- int ret;
+ int ret = -ENOMEM;
switch (cmd) {
case GNTTABOP_map_grant_ref:
@@ -292,17 +292,14 @@ int HYPERVISOR_grant_table_op(unsigned i
}
desc = xencomm_map_no_alloc(op, argsize);
-
- if (desc == NULL)
- return -ENOSPC;
-
- ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
-desc, count);
- if (cmd == GNTTABOP_map_grant_ref)
- gnttab_post_map_grant_ref(op, count);
-
+ if (desc) {
+ ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op),
+cmd, desc, count);
+ if (!ret cmd == GNTTABOP_map_grant_ref)
+ gnttab_post_map_grant_ref(op, count);
+ xencomm_free(desc);
+ }
xencomm_free(frame_list);
- xencomm_free(desc);
return ret;
}
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [linux-ppc-2.6] [XEN] xencomm fixes for various runtime situations
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 5eca8383a521939f0d74e68eaddb049c5057742a
# Parent ab3b5849331da89e578ae0813021376d66b7f333
[XEN] xencomm fixes for various runtime situations
This patch makes xencomm safe for all allocations scenarios including:
- too early to use allocator
- in IRQ
- Recognize when inline can be used
- vmalloc()
- Automatic use of the xencomm_mini when the number of pages is small.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
---
arch/powerpc/platforms/xen/gnttab.c | 21 ++
arch/powerpc/platforms/xen/hcall.c | 283 ++--
arch/powerpc/platforms/xen/setup.c |2
drivers/xen/core/xencomm.c | 73 -
include/xen/xencomm.h | 20 ++
5 files changed, 280 insertions(+), 119 deletions(-)
diff -r ab3b5849331d -r 5eca8383a521 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Sun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Tue Feb 06 16:21:30 2007 -0500
@@ -244,8 +244,8 @@ static void gnttab_post_map_grant_ref(
int HYPERVISOR_grant_table_op(unsigned int cmd, void *op, unsigned int count)
{
- void *desc;
- void *frame_list;
+ void *desc = NULL;
+ void *frame_list = NULL;
int argsize;
int ret;
@@ -263,8 +263,13 @@ int HYPERVISOR_grant_table_op(unsigned i
memcpy(setup, op, sizeof(setup));
argsize = sizeof(setup);
- frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ frame_list = xencomm_map(
+ xen_guest_handle(setup.frame_list),
+ (sizeof(*xen_guest_handle(setup.frame_list))
+ * setup.nr_frames));
+
+ if (frame_list == NULL)
+ return -ENOMEM;
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,12 +291,18 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_map_no_alloc(op, argsize);
+
+ if (desc == NULL)
+ return -ENOSPC;
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
if (cmd == GNTTABOP_map_grant_ref)
gnttab_post_map_grant_ref(op, count);
+
+ xencomm_free(frame_list);
+ xencomm_free(desc);
return ret;
}
diff -r ab3b5849331d -r 5eca8383a521 arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.cSun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/hcall.cTue Feb 06 16:21:30 2007 -0500
@@ -54,25 +54,43 @@
int HYPERVISOR_console_io(int cmd, int count, char *str)
{
- void *desc = xencomm_create_inline(str);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
+ int rc;
+
+ void *desc = xencomm_map_no_alloc(str, count);
+
+ if (desc == NULL)
+ return -EINVAL;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
cmd, count, desc);
+
+ xencomm_free(desc);
+
+ return rc;
}
EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
-
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
+ int rc;
+
+ void *desc = xencomm_map_no_alloc(op, sizeof(evtchn_op_t));
+ if (desc == NULL)
+ return -EINVAL;
+
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
+
+ xencomm_free(desc);
+
+ return rc;
+
}
EXPORT_SYMBOL(HYPERVISOR_event_channel_op);
-int HYPERVISOR_xen_version_userspace(int cmd, void *arg)
-{
- struct xencomm_desc *desc;
+int HYPERVISOR_xen_version(int cmd, void *arg)
+{
+ void *desc;
const unsigned long hcall = __HYPERVISOR_xen_version;
int argsize;
int rc;
@@ -97,7 +115,10 @@ int HYPERVISOR_xen_version_userspace(int
argsize = sizeof(xen_platform_parameters_t);
break;
case XENVER_pagesize:
- argsize = (arg == NULL) ? 0 : sizeof(void *);
+ if (arg == NULL)
+ argsize = 0;
+ else
+ argsize = sizeof(void *);
break;
case XENVER_get_features:
argsize = sizeof(xen_feature_info_t);
@@ -107,38 +128,41 @@ int HYPERVISOR_xen_version_userspace(int
return -ENOSYS;
}
- rc = xencomm_create(arg, argsize, desc, GFP_KERNEL);
- if (rc)
- return rc;
-
- rc =
Re: [XenPPC] [PATCH] [UPDATE] Xencomm patch
pushed.. thanks On Feb 5, 2007, at 5:42 PM, Jerone Young wrote: Yes..another Xencomm patch :-). The last one actually hit a bug that was currently in xen-linux with handling of domain control operation XEN_DOMCTL_shadow_op. This fix is included in the patch. I've also added error handling and changed return codes from xencomm_no_alloc() failure to be EINVAL. Signed-off-by: Jerone Young [EMAIL PROTECTED] xencomm.patch ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Problems with Xen in hg tree
OK all is well...no fire here...move along. I figured out what happened. I included the vmlinux as the DOM0_IMAGE and not the zImage. It compiled through .. it is a bit surprising the Xen died though and not during loading of Dom0. So ultimately this is a USER error ;-) On Tue, 2007-02-06 at 17:58 -0600, Jerone Young wrote: So cloning the Xen tree as of today .. you can no longer bootup Xen :-). Here is the output on a JS21 The currently active flashside is: 1 (temporary) Stopping BMC watchdog... Trying to load: sync_console debug || root=/dev/sda3 debug from: net ... Bootloader 1.5 Reading MAC address from device: 00:14:5E:9C:1C:C5 Requesting IP address via BOOTP: 9.3.189.7 Requesting file leaf4 via TFTP Receiving data: A###A| TFTP: Received leaf4 (65359 KBytes) Successfully loaded --- OF: Xen/PPC version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE Linux)) Tue Feb 6 17:18:51 CST 2007 boot_of_init args: 0x0 0x0 0xe11027c 0xe28bed2 0x2a boot msr: 0x10003000 boot_of_init: _start 004000d0 _end 042b0310 0xe28bed2 boot_of_alloc_init: pg :0x2000 of our image is different HANG I'll be looking into this in the morning. But just an FYI to everybody. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] boot failure with large dom0
I'll give it a try. On Wed, 2007-02-07 at 11:59 -0600, Hollis Blanchard wrote: I use a vmlinux as dom0, but it's a stripped vmlinux. A vmlinux with full debug symbols is 55MB here, which probably explains this problem. Could you see how easy it would be to catch this problem at runtime and have a nice panic? Checking dom0_len in __start_xen() would probably do the trick, maybe something like: if (dom0_start + dom0_len (3220)) panic(dom0 is too big); ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Fix up potential memory leaks introduced by xencomm patch
With some of the logic change from the Xencomm patch. In a few
hypercalls introduces a situation where you can potentially have memory
leaks if something fails. This patch address these issues.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 37ea4cf1281a arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Tue Feb 06 17:10:20 2007 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Wed Feb 07 14:50:05 2007 -0600
@@ -203,11 +203,16 @@ int HYPERVISOR_sched_op(int cmd, void *a
desc = xencomm_map_no_alloc(arg, argsize);
- if (desc == NULL)
- return -EINVAL;
-
- rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
-cmd, desc);
+ if (desc)
+ {
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
+ cmd, desc);
+ xencomm_free(desc);
+ }
+ else
+ {
+ rc = -EINVAL;
+ }
xencomm_free(ports);
@@ -389,8 +394,8 @@ static int xenppc_privcmd_domctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_domctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -463,8 +468,8 @@ static int xenppc_privcmd_sysctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_sysctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -514,8 +519,8 @@ static int xenppc_privcmd_platform_op(pr
if (copy_to_user(user_op, kern_op, sizeof(xen_platform_op_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -547,7 +552,10 @@ int HYPERVISOR_memory_op(unsigned int cm
sizeof(*xen_guest_handle(mop-extent_start)));
if (desc == NULL)
+ {
+xencomm_free(op_desc);
return -ENOMEM;
+ }
set_xen_guest_handle(mop-extent_start,
desc);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-changelog] [xen-unstable] Add RCU support to Xen.
On Sat, 2007-01-27 at 13:00 -0800, Xen patchbot-unstable wrote: # HG changeset patch # User [EMAIL PROTECTED] # Date 1169836476 0 # Node ID 32fd32bbf78d094e96027e3cea05fcbd92fee7a5 # Parent 19a600376688577f0692eac022f05bc6df30ce93 Add RCU support to Xen. ... @@ -658,6 +659,8 @@ void __init __start_xen(multiboot_info_t trap_init(); +rcu_init(); + timer_init(); early_time_init(); This patch only added the rcu_init() call for x86. When the call is omitted (on ia64 and powerpc), do_softirq() crashes trying to call a null function pointer. In cases like this where you *know* you're going to break the non-x86 architectures, please email xen-ppc-devel and xen-ia64-devel to let us know what we'll need to do in the future, rather than force us to reverse-engineer the crash. 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] Problems with Xen in hg tree
On Feb 7, 2007, at 12:48 PM, Jerone Young wrote: OK all is well...no fire here...move along. I figured out what happened. I included the vmlinux as the DOM0_IMAGE and not the zImage. It compiled through .. it is a bit surprising the Xen died though and not during loading of Dom0. So ultimately this is a USER error ;-) Thats not user error, that should work, its not smart but is should work, stripped or not stripped. So vmlinux can be like 64M which is bigger that our boo_of allocator can currently handle. This is our bug, we should simply exit gracefully. Jerone, could you file a bug with the specifics? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] boot failure with large dom0
If the problem were that dom0 was only partially transferred, we would
see dom0 start to boot and fail. The boot_of_alloc_init message happens
way before that point.
The early boot code only tracks the first 32M of memory, and I believe
that is the problem here: we're overflowing the bitmap we're using to
track memory. Page 2000 is address 200 (32MB). Try this patch:
diff -r 20e5f508accc xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Feb 06 13:42:19 2007 -0600
+++ b/xen/arch/powerpc/boot_of.cWed Feb 07 16:38:24 2007 -0600
@@ -394,6 +394,9 @@ static void boot_of_alloc_init(int m, ui
u64 start;
u64 size;
+if (((ulong)_end PAGE_SHIFT) = MEM_AVAILABLE_PAGES)
+of_panic(image is too big);
+
rc = of_getprop(m, available, a, sizeof (a));
if (rc 0) {
int l = rc / sizeof(a[0]);
--
Hollis Blanchard
IBM Linux Technology Center
On Wed, 2007-02-07 at 16:20 -0600, Jerone Young wrote:
So it looks like the problem has to do with tftp which apears to have a
64MB send limit. The file is over this and so everything does not make
it. Adding a check for dom0 image size does not good since the image
itself is not fully transfered. Which make since why you get the error:
boot_of_alloc_init: pg :0x2000 of our image is different
at bootup.
On Wed, 2007-02-07 at 11:59 -0600, Hollis Blanchard wrote:
I use a vmlinux as dom0, but it's a stripped vmlinux. A vmlinux with
full debug symbols is 55MB here, which probably explains this problem.
Could you see how easy it would be to catch this problem at runtime and
have a nice panic? Checking dom0_len in __start_xen() would probably do
the trick, maybe something like:
if (dom0_start + dom0_len (3220))
panic(dom0 is too big);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH 2/2] linux: build start_info_t from devtree only
This patch cleans up xen_init_early() to construct a start_info_t only
from the devtree as Patch1 fixes xen to no longer create a start_info_t
for dom0.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
setup.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
---
diff -r a6adf094e08e arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cTue Feb 06 13:55:48 2007 -0600
+++ b/arch/powerpc/platforms/xen/setup.cWed Feb 07 11:33:10 2007 -0600
@@ -88,29 +88,26 @@ static void __init xen_init_early(void)
static void __init xen_init_early(void)
{
struct device_node *xen;
- u64 *si;
DBG( - %s\n, __func__);
xen = of_find_node_by_path(/xen);
- si = (u64 *)get_property(xen, start-info, NULL);
-
- /* build our own start_info_t if start-info property is not present */
- if (si != NULL) {
- xen_start_info = (start_info_t *)__va(*si);
- } else {
- struct device_node *console;
- struct device_node *store;
-
- console = of_find_node_by_path(/xen/console);
- store = of_find_node_by_path(/xen/store);
-
- xen_start_info = xsi;
-
- /* fill out start_info_t from devtree */
- xen_start_info-shared_info = *((u64 *)get_property(xen,
- shared-info, NULL));
+ xen_start_info = xsi;
+
+ /* fill out start_info_t from devtree */
+ if ((char *)get_property(xen, privileged, NULL))
+ xen_start_info-flags |= SIF_PRIVILEGED;
+ if ((char *)get_property(xen, initdomain, NULL))
+ xen_start_info-flags |= SIF_INITDOMAIN;
+ xen_start_info-shared_info = *((u64 *)get_property(xen,
+ shared-info, NULL));
+
+ /* only look for store and console for guest domains */
+ if (xen_start_info-flags == 0) {
+ struct device_node *console =
of_find_node_by_path(/xen/console);
+ struct device_node *store = of_find_node_by_path(/xen/store);
+
xen_start_info-store_mfn = (*((u64 *)get_property(store,
reg, NULL))) PAGE_SHIFT;
xen_start_info-store_evtchn = *((u32 *)get_property(store,
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] boot failure with large dom0
On Feb 7, 2007, at 5:38 PM, Hollis Blanchard wrote: If the problem were that dom0 was only partially transferred, we would see dom0 start to boot and fail. The boot_of_alloc_init message happens way before that point. Thats not really true, dom0 is in .data, there are actually additional objects that will get linked in after dom0, especially the init data and bss, so if the load is partial then who knows WTF will happen. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Problems with Xen in hg tree
On Feb 7, 2007, at 5:41 PM, Jerone Young wrote: On Wed, 2007-02-07 at 17:37 -0500, Jimi Xenidis wrote: On Feb 7, 2007, at 12:48 PM, Jerone Young wrote: OK all is well...no fire here...move along. I figured out what happened. I included the vmlinux as the DOM0_IMAGE and not the zImage. It compiled through .. it is a bit surprising the Xen died though and not during loading of Dom0. So ultimately this is a USER error ;-) Thats not user error, that should work, its not smart but is should work, stripped or not stripped. So vmlinux can be like 64M which is bigger that our boo_of allocator can currently handle. This is our bug, we should simply exit gracefully. Jerone, could you file a bug with the specifics? I can though adding a check to try and catch the size (as suggested by Hollis) does not look like it got far enough in the code to catch it. I think it's the tftp limit being 64MB (though I could be wrong). I'll file a bug never the less. If this is indeed a tftp limit than it is a SLOF bug. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
