[Xen-ia64-devel] [PATCH] xencomm: tmem support.
[IA64] xencomm: tmem support.
add tmem support to xencomm.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
diff --git a/arch/ia64/xen/xcom_hcall.c b/arch/ia64/xen/xcom_hcall.c
--- a/arch/ia64/xen/xcom_hcall.c
+++ b/arch/ia64/xen/xcom_hcall.c
@@ -40,6 +40,7 @@
#include xen/interface/xenoprof.h
#include xen/interface/vcpu.h
#include xen/interface/kexec.h
+#include xen/interface/tmem.h
#include asm/hypervisor.h
#include asm/page.h
#include asm/uaccess.h
@@ -739,3 +740,15 @@ xencomm_hypercall_kexec_op(int cmd, void
return xencomm_arch_hypercall_kexec_op(cmd, desc);
}
+
+int
+xencomm_hypercall_tmem_op(struct tmem_op *op)
+{
+ struct xencomm_handle *desc;
+
+ desc = xencomm_map_no_alloc(op, sizeof(*op));
+ if (desc == NULL)
+ return -EINVAL;
+
+ return xencomm_arch_hypercall_tmem_op(desc);
+}
diff --git a/arch/ia64/xen/xcom_privcmd.c b/arch/ia64/xen/xcom_privcmd.c
--- a/arch/ia64/xen/xcom_privcmd.c
+++ b/arch/ia64/xen/xcom_privcmd.c
@@ -32,6 +32,7 @@
#include xen/interface/xsm/acm_ops.h
#include xen/interface/hvm/params.h
#include xen/interface/arch-ia64/debug_op.h
+#include xen/interface/tmem.h
#include xen/public/privcmd.h
#include asm/hypercall.h
#include asm/page.h
@@ -897,6 +898,22 @@ xencomm_privcmd_ia64_physdev_op(privcmd_
return ret;
}
+static int
+xencomm_privcmd_tmem_op(privcmd_hypercall_t *hypercall)
+{
+ struct xencomm_handle *desc;
+ int ret;
+
+ desc = xencomm_map((void *)hypercall-arg[0], sizeof(struct tmem_op));
+ if (desc == NULL)
+ return -ENOMEM;
+
+ ret = xencomm_arch_hypercall_tmem_op(desc);
+
+ xencomm_free(desc);
+ return ret;
+}
+
int
privcmd_hypercall(privcmd_hypercall_t *hypercall)
{
@@ -925,6 +942,8 @@ privcmd_hypercall(privcmd_hypercall_t *h
return xencomm_privcmd_ia64_debug_op(hypercall);
case __HYPERVISOR_physdev_op:
return xencomm_privcmd_ia64_physdev_op(hypercall);
+ case __HYPERVISOR_tmem_op:
+ return xencomm_privcmd_tmem_op(hypercall);
default:
printk(%s: unknown hcall (%ld)\n, __func__, hypercall-op);
return -ENOSYS;
diff --git a/include/asm-ia64/hypercall.h b/include/asm-ia64/hypercall.h
--- a/include/asm-ia64/hypercall.h
+++ b/include/asm-ia64/hypercall.h
@@ -435,6 +435,12 @@ xencomm_arch_hypercall_kexec_op(int cmd,
return _hypercall2(int, kexec_op, cmd, arg);
}
+static inline int
+xencomm_arch_hypercall_tmem_op(struct xencomm_handle *arg)
+{
+ return _hypercall1(int, tmem_op, arg);
+}
+
// for balloon driver
#define HYPERVISOR_update_va_mapping(va, new_val, flags) (0)
@@ -455,6 +461,7 @@ xencomm_arch_hypercall_kexec_op(int cmd,
#define HYPERVISOR_vcpu_op xencomm_hypercall_vcpu_op
#define HYPERVISOR_opt_feature xencomm_hypercall_opt_feature
#define HYPERVISOR_kexec_op xencomm_hypercall_kexec_op
+#define HYPERVISOR_tmem_op xencomm_hypercall_tmem_op
/* to compile gnttab_copy_grant_page() in drivers/xen/core/gnttab.c */
#define HYPERVISOR_mmu_update(req, count, success_count, domid) ({BUG();0;})
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] xencomm support for multi call with physdev_op and event_channel_op.
IA64: xencomm support for multi call with physdev_op and event_channel_op.
Recently the c/s of d545a95fca73 makes use of multi call
with __HYPERVISOR_event_channel_op and __HYPERVISOR_physdev_op.
This patch adds support of those hypercall.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff --git a/arch/ia64/xen/xcom_hcall.c b/arch/ia64/xen/xcom_hcall.c
--- a/arch/ia64/xen/xcom_hcall.c
+++ b/arch/ia64/xen/xcom_hcall.c
@@ -70,13 +70,27 @@ xencomm_hypercall_console_io(int cmd, in
}
EXPORT_SYMBOL_GPL(xencomm_hypercall_console_io);
+static int
+xencommize_event_channel_op(struct xencomm_mini **xc_area, void *op,
+ struct xencomm_handle **desc)
+{
+ *desc = __xencomm_map_no_alloc(op, sizeof(evtchn_op_t), *xc_area);
+ if (*desc == NULL)
+ return -EINVAL;
+ (*xc_area)++;
+ return 0;
+}
+
int
xencomm_hypercall_event_channel_op(int cmd, void *op)
{
+ int rc;
struct xencomm_handle *desc;
- desc = xencomm_map_no_alloc(op, sizeof(evtchn_op_t));
- if (desc == NULL)
- return -EINVAL;
+ XENCOMM_MINI_ALIGNED(xc_area, 2);
+
+ rc = xencommize_event_channel_op(xc_area, op, desc);
+ if (rc)
+ return rc;
return xencomm_arch_hypercall_event_channel_op(cmd, desc);
}
@@ -127,8 +141,9 @@ xencomm_hypercall_xen_version(int cmd, v
}
EXPORT_SYMBOL_GPL(xencomm_hypercall_xen_version);
-int
-xencomm_hypercall_physdev_op(int cmd, void *op)
+static int
+xencommize_physdev_op(struct xencomm_mini **xc_area, int cmd, void *op,
+ struct xencomm_handle **desc)
{
unsigned int argsize;
@@ -159,9 +174,26 @@ xencomm_hypercall_physdev_op(int cmd, vo
printk(%s: unknown physdev op %d\n, __func__, cmd);
return -ENOSYS;
}
-
- return xencomm_arch_hypercall_physdev_op
- (cmd, xencomm_map_no_alloc(op, argsize));
+
+ *desc = __xencomm_map_no_alloc(op, argsize, *xc_area);
+ if (*desc == NULL)
+ return -EINVAL;
+ (*xc_area)++;
+ return 0;
+}
+
+int
+xencomm_hypercall_physdev_op(int cmd, void *op)
+{
+ int rc;
+ struct xencomm_handle *desc;
+ XENCOMM_MINI_ALIGNED(xc_area, 2);
+
+ rc = xencommize_physdev_op(xc_area, cmd, op, desc);
+ if (rc)
+ return rc;
+
+ return xencomm_arch_hypercall_physdev_op(cmd, desc);
}
static int
@@ -319,6 +351,34 @@ xencomm_hypercall_multicall(void *call_l
if (rc)
return rc;
mce-args[1] = (unsigned long)desc;
+ break;
+ case __HYPERVISOR_event_channel_op:
+ rc = xencommize_event_channel_op(xc_area,
+(void *)mce-args[1],
+desc);
+ if (rc)
+ return rc;
+ mce-args[1] = (unsigned long)desc;
+ break;
+ case __HYPERVISOR_physdev_op:
+ switch (mce-args[0]) {
+ case PHYSDEVOP_eoi: {
+ struct physdev_eoi *eoi =
+ (struct physdev_eoi *)mce-args[1];
+ mce-op = __HYPERVISOR_ia64_fast_eoi;
+ mce-args[0] = eoi-irq;
+ break;
+ }
+ default:
+ rc = xencommize_physdev_op(xc_area,
+ mce-args[0],
+ (void *)mce-args[1],
+ desc);
+ if (rc)
+ return rc;
+ mce-args[1] = (unsigned long)desc;
+ break;
+ }
break;
case __HYPERVISOR_memory_op:
default:
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] xencomm: support XENMEM_add_to_physmap and XENMEM_remove_from_phsymap
Note: this patch depends on the c/s of 653:8566781df55e
which updates include/xen/interface/memory.h.
[IA64] xencomm: support XENMEM_add_to_physmap and XENMEM_remove_from_phsymap
support XENMEM_add_to_physmap and XENMEM_remove_from_phsymap.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r a35dde520af5 arch/ia64/xen/xcom_privcmd.c
--- a/arch/ia64/xen/xcom_privcmd.c Tue Sep 09 16:57:09 2008 +0900
+++ b/arch/ia64/xen/xcom_privcmd.c Tue Sep 09 18:25:44 2008 +0900
@@ -575,6 +575,34 @@
return ret;
}
+ case XENMEM_add_to_physmap:
+ case XENMEM_remove_from_physmap:
+ {
+ void __user *arg = (void __user *)hypercall-arg[1];
+ size_t argsize;
+ struct xencomm_handle *desc;
+
+ switch (cmd) {
+ case XENMEM_add_to_physmap:
+ argsize = sizeof(struct xen_add_to_physmap);
+ break;
+ case XENMEM_remove_from_physmap:
+ argsize = sizeof(struct xen_remove_from_physmap);
+ break;
+ default:
+ BUG();
+ }
+
+ desc = xencomm_map(arg, argsize);
+ if (desc == NULL)
+ return -ENOMEM;
+
+ ret = xencomm_arch_hypercall_memory_op(cmd, desc);
+
+ xencomm_free(desc);
+ return ret;
+
+ }
default:
printk(%s: unknown memory op %lu\n, __func__, cmd);
ret = -ENOSYS;
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] xencomm: support PHYSDEVOP_manage_pci_add/remove.
[IA64] xencomm: support PHYSDEVOP_manage_pci_add/remove. add support PHYSDEVOP_manage_pci_add/remove which were newly added. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff -r 65290c01dca0 arch/ia64/xen/xcom_hcall.c --- a/arch/ia64/xen/xcom_hcall.cThu Jul 24 14:31:47 2008 +0900 +++ b/arch/ia64/xen/xcom_hcall.cThu Jul 24 16:04:45 2008 +0900 @@ -143,6 +143,10 @@ break; case PHYSDEVOP_irq_status_query: argsize = sizeof(physdev_irq_status_query_t); + break; + case PHYSDEVOP_manage_pci_add: + case PHYSDEVOP_manage_pci_remove: + argsize = sizeof(physdev_manage_pci_t); break; default: -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] xencomm: fix dirty page leak
This patch fixes a dirty page leak for live migration.
The common part of this fix is already applied to upstream.
http://xenbits.xensource.com/xen-unstable.hg?rev/146f214a0e63
Thanks,
Kouya
Signed-off-by: Kouya Shimura [EMAIL PROTECTED]
diff -r feee6422144f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Apr 01 11:29:03 2008 -0600
+++ b/xen/arch/ia64/xen/mm.cWed Apr 09 15:29:15 2008 +0900
@@ -2903,6 +2903,20 @@ int is_iomem_page(unsigned long mfn)
return (!mfn_valid(mfn) || (page_get_owner(mfn_to_page(mfn)) == dom_io));
}
+void xencomm_mark_dirty(unsigned long addr, unsigned int len)
+{
+struct domain *d = current-domain;
+unsigned long gpfn;
+unsigned long end_addr = addr + len;
+
+if (shadow_mode_enabled(d)) {
+for (addr = PAGE_MASK; addr end_addr; addr += PAGE_SIZE) {
+gpfn = get_gpfn_from_mfn(virt_to_mfn(addr));
+shadow_mark_page_dirty(d, gpfn);
+}
+}
+}
+
/*
* Local variables:
* mode: C
diff -r feee6422144f xen/include/asm-ia64/config.h
--- a/xen/include/asm-ia64/config.h Tue Apr 01 11:29:03 2008 -0600
+++ b/xen/include/asm-ia64/config.h Wed Apr 09 15:29:15 2008 +0900
@@ -291,4 +291,6 @@ struct screen_info { };
/* Define CONFIG_PRIVIFY to support privified OS (deprecated). */
#undef CONFIG_PRIVIFY
+#define CONFIG_XENCOMM_MARK_DIRTY 1
+
#endif /* _IA64_CONFIG_H_ */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] [xencomm, xen] use common xencomm.c and remove ia64 xencomm.c
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1186475123 -32400
# Node ID 8b6af0333d531d1fd63b1ce02c2df51b0d4f45f5
# Parent 6f18f5bdeea3473766929f9caa10cc163a411aa3
use common xencomm.c and remove ia64 xencomm.c
PATCHNAME: use_common_xencomm_c_and_remove_ia64_xencomm_c
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 6f18f5bdeea3 -r 8b6af0333d53 config/ia64.mk
--- a/config/ia64.mkMon Aug 06 15:33:42 2007 +0100
+++ b/config/ia64.mkTue Aug 07 17:25:23 2007 +0900
@@ -3,5 +3,6 @@ CONFIG_IA64_$(XEN_OS) := y
CONFIG_IOEMU := y
CONFIG_XCUTILS := y
+CONFIG_XENCOMM := y
LIBDIR := lib
diff -r 6f18f5bdeea3 -r 8b6af0333d53 xen/arch/ia64/xen/Makefile
--- a/xen/arch/ia64/xen/MakefileMon Aug 06 15:33:42 2007 +0100
+++ b/xen/arch/ia64/xen/MakefileTue Aug 07 17:25:23 2007 +0900
@@ -35,7 +35,6 @@ obj-y += flushd.o
obj-y += flushd.o
obj-y += privop_stat.o
obj-y += xenpatch.o
-obj-y += xencomm.o
obj-$(crash_debug) += gdbstub.o
obj-$(xen_ia64_tlb_track) += tlb_track.o
diff -r 6f18f5bdeea3 -r 8b6af0333d53 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cMon Aug 06 15:33:42 2007 +0100
+++ b/xen/arch/ia64/xen/mm.cTue Aug 07 17:25:23 2007 +0900
@@ -737,7 +737,7 @@ void *domain_mpa_to_imva(struct domain *
#endif
unsigned long
-xencomm_paddr_to_maddr(unsigned long paddr)
+paddr_to_maddr(unsigned long paddr)
{
struct vcpu *v = current;
struct domain *d = v-domain;
diff -r 6f18f5bdeea3 -r 8b6af0333d53 xen/arch/ia64/xen/xencomm.c
--- a/xen/arch/ia64/xen/xencomm.c Mon Aug 06 15:33:42 2007 +0100
+++ /dev/null Thu Jan 01 00:00:00 1970 +
@@ -1,387 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * 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. 2006
- *
- * Authors: Hollis Blanchard [EMAIL PROTECTED]
- * Tristan Gingold [EMAIL PROTECTED]
- */
-
-#include xen/config.h
-#include xen/mm.h
-#include xen/sched.h
-#include asm/current.h
-#include asm/guest_access.h
-#include public/xen.h
-#include public/xencomm.h
-#include xen/errno.h
-
-#undef DEBUG
-#ifdef DEBUG
-static int xencomm_debug = 1; /* extremely verbose */
-#else
-#define xencomm_debug 0
-#endif
-
-static int
-xencomm_copy_chunk_from(
-unsigned long to,
-unsigned long paddr,
-unsigned int len)
-{
-unsigned long maddr;
-struct page_info *page;
-
-while (1) {
- maddr = xencomm_paddr_to_maddr(paddr);
- if (xencomm_debug 1)
- printk(%lx[%d] - %lx\n, maddr, len, to);
- if (maddr == 0)
- return -EFAULT;
-
- page = virt_to_page(maddr);
- if (get_page(page, current-domain) == 0) {
- if (page_get_owner(page) != current-domain) {
- /* This page might be a page granted by another domain */
- panic_domain(NULL, copy_from_guest from foreign domain\n);
- }
- /* Try again. */
- continue;
- }
- memcpy((void *)to, (void *)maddr, len);
- put_page(page);
- return 0;
-}
-}
-
-/**
- * xencomm_copy_from_guest: Copy a block of data from domain space.
- * @to: Machine address.
- * @from: Physical address to a xencomm buffer descriptor.
- * @n:Number of bytes to copy.
- * @skip: Number of bytes from the start to skip.
- *
- * Copy data from domain to hypervisor.
- *
- * Returns number of bytes that could not be copied.
- * On success, this will be zero.
- */
-unsigned long
-xencomm_copy_from_guest(
-void *to,
-const void *from,
-unsigned int n,
-unsigned int skip)
-{
-struct xencomm_desc *desc;
-unsigned long desc_addr;
-unsigned int from_pos = 0;
-unsigned int to_pos = 0;
-unsigned int i = 0;
-
-if (xencomm_debug)
-printk(xencomm_copy_from_guest: from=%lx+%u n=%u\n,
- (unsigned long)from, skip, n);
-
-if (XENCOMM_IS_INLINE(from)) {
-unsigned long src_paddr = XENCOMM_INLINE_ADDR(from);
-
-src_paddr += skip;
-
-while (n 0) {
-unsigned int chunksz;
-unsigned int bytes;
- int res;
-
-chunksz = PAGE_SIZE - (src_paddr % PAGE_SIZE);
-
-bytes = min(chunksz, n);
-
-res = xencomm_copy_chunk_from((unsigned long)to, src_paddr, bytes);
- if (res != 0)
-
[Xen-ia64-devel] [PATCH] xencomm update for acm interface change
xencomm update for acm interface change by c/s 15189:96915ca8d5f2
of xen-unstable.h
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1181649851 -32400
# Node ID 287794cccd22e7de3ea3f96beff87a4c114bbf30
# Parent 245902ee7ce0c1499c172b3a9240b8e2ede45a5f
xencomm update for acm interface change by c/s 15189:96915ca8d5f2
of xen-unstable.h
PATCHNAME: xencom_update_for_acm
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 245902ee7ce0 -r 287794cccd22 arch/ia64/xen/xcom_privcmd.c
--- a/arch/ia64/xen/xcom_privcmd.c Mon Jun 11 14:59:53 2007 -0600
+++ b/arch/ia64/xen/xcom_privcmd.c Tue Jun 12 21:04:11 2007 +0900
@@ -338,40 +338,39 @@ static int
static int
xencomm_privcmd_acm_op(privcmd_hypercall_t *hypercall)
{
- int cmd = hypercall-arg[0];
- void __user *arg = (void __user *)hypercall-arg[1];
+ void __user *arg = (void __user *)hypercall-arg[0];
+ xen_acmctl_t kern_arg;
struct xencomm_handle *op_desc;
struct xencomm_handle *desc = NULL;
int ret;
- switch (cmd) {
- case ACMOP_getssid:
- {
- struct acm_getssid kern_arg;
-
- if (copy_from_user(kern_arg, arg, sizeof (kern_arg)))
+ if (copy_from_user(kern_arg, arg, sizeof(kern_arg)))
+ return -EFAULT;
+ if (kern_arg.interface_version != ACM_INTERFACE_VERSION)
+ return -ENOSYS;
+
+ switch (kern_arg.cmd) {
+ case ACMOP_getssid: {
+ op_desc = xencomm_create_inline(kern_arg);
+
+ ret = xencomm_create(
+ xen_guest_handle(kern_arg.u.getssid.ssidbuf),
+ kern_arg.u.getssid.ssidbuf_size, desc, GFP_KERNEL);
+ if (ret)
+ return ret;
+
+ set_xen_guest_handle(kern_arg.u.getssid.ssidbuf, (void *)desc);
+
+ ret = xencomm_arch_hypercall_acm_op(op_desc);
+
+ xencomm_free(desc);
+
+ if (copy_to_user(arg, kern_arg, sizeof(kern_arg)))
return -EFAULT;
-
- op_desc = xencomm_create_inline(kern_arg);
-
- ret = xencomm_create(xen_guest_handle(kern_arg.ssidbuf),
- kern_arg.ssidbuf_size, desc, GFP_KERNEL);
- if (ret)
- return ret;
-
- set_xen_guest_handle(kern_arg.ssidbuf, (void *)desc);
-
- ret = xencomm_arch_hypercall_acm_op(cmd, op_desc);
-
- xencomm_free(desc);
-
- if (copy_to_user(arg, kern_arg, sizeof (kern_arg)))
- return -EFAULT;
-
- return ret;
- }
- default:
- printk(%s: unknown acm_op cmd %d\n, __func__, cmd);
+ return ret;
+ }
+ default:
+ printk(%s: unknown acm_op cmd %d\n, __func__, kern_arg.cmd);
return -ENOSYS;
}
diff -r 245902ee7ce0 -r 287794cccd22 include/asm-ia64/hypercall.h
--- a/include/asm-ia64/hypercall.h Mon Jun 11 14:59:53 2007 -0600
+++ b/include/asm-ia64/hypercall.h Tue Jun 12 21:04:11 2007 +0900
@@ -157,9 +157,9 @@ xencomm_arch_hypercall_event_channel_op(
}
static inline int
-xencomm_arch_hypercall_acm_op(unsigned int cmd, struct xencomm_handle *arg)
-{
- return _hypercall2(int, acm_op, cmd, arg);
+xencomm_arch_hypercall_acm_op(struct xencomm_handle *arg)
+{
+ return _hypercall1(int, acm_op, arg);
}
static inline int
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] xencomm update for acm interface change
On Tue, 2007-06-12 at 21:14 +0900, Isaku Yamahata wrote: xencomm update for acm interface change by c/s 15189:96915ca8d5f2 of xen-unstable.h Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] xencomm, xenmem and hypercall continuation
fix xenmem hypercall for non-trivial xencomm arch(i.e. ia64, and powerpc)
On ia64 and powerpc, guest_handle_add_offset() effect persists over
hypercall continuation because its consumed offset is recorced in
guest domains memory space.
On the other hand, x86 guest_handle_add_offset() effect is volatile
over hypercall continuation.
So xenmem hypercall(more specifically increase_reservation,
decrease_reservaton, populate_memory and exchange) is broken on
ia64 and powerpc.
#ifdef/ifndef CONFIG_X86 is used to solve this issue without breaking
the existing ABI. #ifdef is ugly, but it would be difficult to solve
this issue without #ifdef and to preserve the existing ABI simaltaneously.
I checked other users of both guest_handle_add_offset() and hypercall
continuation. Fortunately other users records restart points
by hypercall argument so that this isn't an issue.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1163136126 -32400
# Node ID f3e97d467b6f7e36c95d4deb3ed3bc955710f8e7
# Parent 5470cadfeb22e33e7abb86193224984140732361
fix xenmem hypercall for non-trivial xencomm arch(i.e. ia64, and powerpc)
On ia64 and powerpc, guest_handle_add_offset() effect persists over
hypercall continuation because its consumed offset is recorced in
guest domains memory space.
On the other hand, x86 guest_handle_add_offset() effect is volatile
over hypercall continuation.
So xenmem hypercall(more specifically increase_reservation,
decrease_reservaton, populate_memory and exchange) is broken on
ia64 and powerpc.
#ifdef/ifndef CONFIG_X86 is used to solve this issue without breaking
the existing ABI. #ifdef is ugly, but it would be difficult to solve
this issue without #ifdef and to preserve the existing ABI simaltaneously.
I checked other users of both guest_handle_add_offset() and hypercall
continuation. Fortunately other users records restart points
by hypercall argument so that this isn't an issue.
PATCHNAME: xencomm_and_xenmem_hypercall
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 5470cadfeb22 -r f3e97d467b6f xen/common/memory.c
--- a/xen/common/memory.c Fri Nov 10 14:22:05 2006 +0900
+++ b/xen/common/memory.c Fri Nov 10 14:22:06 2006 +0900
@@ -341,23 +341,29 @@ memory_exchange(XEN_GUEST_HANDLE(xen_mem
memflags = MEMF_dma;
}
+#ifdef CONFIG_X86
guest_handle_add_offset(exch.in.extent_start, exch.nr_exchanged);
+#endif
exch.in.nr_extents -= exch.nr_exchanged;
if ( exch.in.extent_order = exch.out.extent_order )
{
in_chunk_order = exch.out.extent_order - exch.in.extent_order;
out_chunk_order = 0;
+#ifdef CONFIG_X86
guest_handle_add_offset(
exch.out.extent_start, exch.nr_exchanged in_chunk_order);
+#endif
exch.out.nr_extents -= exch.nr_exchanged in_chunk_order;
}
else
{
in_chunk_order = 0;
out_chunk_order = exch.in.extent_order - exch.out.extent_order;
+#ifdef CONFIG_X86
guest_handle_add_offset(
exch.out.extent_start, exch.nr_exchanged out_chunk_order);
+#endif
exch.out.nr_extents -= exch.nr_exchanged out_chunk_order;
}
@@ -379,6 +385,15 @@ memory_exchange(XEN_GUEST_HANDLE(xen_mem
{
if ( hypercall_preempt_check() )
{
+#ifndef CONFIG_X86
+guest_handle_add_offset(exch.in.extent_start, i);
+if ( exch.in.extent_order = exch.out.extent_order )
+guest_handle_add_offset(
+exch.out.extent_start, i in_chunk_order);
+else
+guest_handle_add_offset(
+exch.out.extent_start, i out_chunk_order);
+#endif
exch.nr_exchanged += i in_chunk_order;
if ( copy_field_to_guest(arg, exch, nr_exchanged) )
return -EFAULT;
@@ -543,8 +558,10 @@ long do_memory_op(unsigned long cmd, XEN
if ( unlikely(start_extent reservation.nr_extents) )
return start_extent;
+#ifdef CONFIG_X86
if ( !guest_handle_is_null(reservation.extent_start) )
guest_handle_add_offset(reservation.extent_start, start_extent);
+#endif
reservation.nr_extents -= start_extent;
if ( (reservation.address_bits != 0)
@@ -596,6 +613,10 @@ long do_memory_op(unsigned long cmd, XEN
if ( unlikely(reservation.domid != DOMID_SELF) )
put_domain(d);
+#ifndef CONFIG_X86
+if (rc 0 !guest_handle_is_null(reservation.extent_start))
+guest_handle_add_offset(reservation.extent_start, rc);
+#endif
rc += start_extent;
if ( preempted )
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: xencomm fixes for HVM PV drivers and driver domain
Hi,
Two fixes for xencomm glitches.
Tested by booting driver domU.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 0b2f6318af669fa3f1092f1d1e9cb5a048792d99
# Parent 1a0b58e7b5de8c666b19d3063658d9a3c25e9bea
Xencomm fixes for HVM PV-drivers and driver domain.
Create xcom_mini.c from xcom_hcall.c
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 1a0b58e7b5de -r 0b2f6318af66 linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Thu Oct 05 12:25:53 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Fri Oct 06 08:58:21 2006 +0200
@@ -63,6 +63,7 @@
#include asm/system.h
#ifdef CONFIG_XEN
#include asm/hypervisor.h
+#include asm/xen/xencomm.h
#endif
#include linux/dma-mapping.h
@@ -76,8 +77,6 @@ EXPORT_SYMBOL(__per_cpu_offset);
#endif
#ifdef CONFIG_XEN
-unsigned long kernel_start_pa;
-
static int
xen_panic_event(struct notifier_block *this, unsigned long event, void *ptr)
{
@@ -435,7 +434,9 @@ setup_arch (char **cmdline_p)
#ifdef CONFIG_XEN
if (is_running_on_xen()) {
- kernel_start_pa = KERNEL_START - ia64_tpa(KERNEL_START);
+ /* Must be done before any hypercall. */
+ xencomm_init ();
+
setup_xen_features();
/* Register a call for panic conditions. */
notifier_chain_register(panic_notifier_list, xen_panic_block);
diff -r 1a0b58e7b5de -r 0b2f6318af66 linux-2.6-xen-sparse/arch/ia64/xen/Makefile
--- a/linux-2.6-xen-sparse/arch/ia64/xen/Makefile Thu Oct 05 12:25:53 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/Makefile Fri Oct 06 08:58:21 2006 +0200
@@ -4,6 +4,6 @@
obj-y := hypercall.o xenivt.o xenentry.o xensetup.o xenpal.o xenhpski.o \
hypervisor.o pci-dma-xen.o util.o xencomm.o xcom_hcall.o \
- xcom_privcmd.o
+ xcom_mini.o xcom_privcmd.o
pci-dma-xen-y := ../../i386/kernel/pci-dma-xen.o
diff -r 1a0b58e7b5de -r 0b2f6318af66 linux-2.6-xen-sparse/arch/ia64/xen/xcom_hcall.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/xcom_hcall.c Thu Oct 05 12:25:53 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/xcom_hcall.c Fri Oct 06 08:58:21 2006 +0200
@@ -32,7 +32,6 @@
#include xen/interface/callback.h
#include xen/interface/acm_ops.h
#include xen/interface/hvm/params.h
-#include xen/public/privcmd.h
#include asm/hypercall.h
#include asm/page.h
#include asm/uaccess.h
@@ -128,7 +127,8 @@ xencommize_grant_table_op(unsigned int c
}
int
-xencomm_hypercall_grant_table_op(unsigned int cmd, void *op, unsigned int count)
+xencomm_hypercall_grant_table_op(unsigned int cmd,
+ void *op, unsigned int count)
{
void *desc = xencommize_grant_table_op (cmd, op, count);
@@ -142,15 +142,25 @@ xencomm_hypercall_sched_op(int cmd, void
case SCHEDOP_yield:
case SCHEDOP_block:
case SCHEDOP_shutdown:
+ case SCHEDOP_remote_shutdown:
+ break;
case SCHEDOP_poll:
- case SCHEDOP_remote_shutdown:
- break;
+ {
+ sched_poll_t *poll = arg;
+ struct xencomm_handle *ports;
+
+ ports = xencomm_create_inline(xen_guest_handle(poll-ports));
+
+ set_xen_guest_handle(poll-ports, (void *)ports);
+ break;
+ }
default:
printk(%s: unknown sched op %d\n, __func__, cmd);
return -ENOSYS;
}
- return xencomm_arch_hypercall_sched_op(cmd, xencomm_create_inline(arg));
+ return xencomm_arch_hypercall_sched_op
+ (cmd, xencomm_create_inline(arg));
}
int
@@ -263,207 +273,3 @@ xencomm_hypercall_suspend(unsigned long
return xencomm_arch_hypercall_suspend(xencomm_create_inline(arg));
}
-
-int
-xencomm_mini_hypercall_event_channel_op(int cmd, void *op)
-{
- struct xencomm_mini xc_area[2];
- int nbr_area = 2;
- struct xencomm_handle *desc;
- int rc;
-
- rc = xencomm_create_mini(xc_area, nbr_area,
- op, sizeof(evtchn_op_t), desc);
- if (rc)
- return rc;
-
- return xencomm_arch_hypercall_event_channel_op(cmd, desc);
-}
-EXPORT_SYMBOL(xencomm_mini_hypercall_event_channel_op);
-
-static int
-xencommize_mini_grant_table_op(struct xencomm_mini *xc_area, int *nbr_area,
- unsigned int cmd, void *op, unsigned int count,
- struct xencomm_handle **desc)
-{
- struct xencomm_handle *desc1;
- unsigned int argsize;
- int rc;
-
- switch (cmd) {
- case GNTTABOP_map_grant_ref:
- argsize = sizeof(struct gnttab_map_grant_ref);
- break;
- case GNTTABOP_unmap_grant_ref:
- argsize = sizeof(struct gnttab_unmap_grant_ref);
- break;
- case GNTTABOP_setup_table:
- {
- struct gnttab_setup_table *setup = op;
-
- argsize = sizeof(*setup);
-
- if (count != 1)
- return -EINVAL;
- rc = xencomm_create_mini
- (xc_area, nbr_area,
- xen_guest_handle(setup-frame_list),
- setup-nr_frames
- * sizeof(*xen_guest_handle(setup-frame_list)),
- desc1);
- if (rc)
- return rc;
- set_xen_guest_handle(setup-frame_list, (void *)desc1);
- break;
- }
- case GNTTABOP_dump_table:
- argsize = sizeof(struct gnttab_dump_table);
- break;
- case GNTTABOP_transfer:
- argsize = sizeof(struct gnttab_transfer);
- break;
- default:
- printk(%s:
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Aron However on ia64 this isn't sufficient. We need either for the modules to load *earlier* (such as in the initramfs) or we need to use dom0_mem=1G (for example) I have some questions, though: 1. On x86, all of the memory is assigned to dom0, then it balloons to give memory to unpriv'd domains. Why does ia64 give only 512M to dom0 instead of doing the same as x86? I don't know, but I think this is for historical reasons. Old Xen/IA64 (about 1 year ago) used only about 2GB. So I think dom0_mem was defined to 512MB. I made the patch, but the patch have a problem. I'm debug it now. 2. Juan says that he can boot x86 xen with only 128M of memory, and there's still enough physically contiguous to load blkbk and netbk when xend loads. So why does ia64 need 8x the memory to do avoid fragmentation? It seems like we must be doing something wrong for memory to fragment so quickly...! I also don't know about it. This is strange, but insmod blkbk will fail in the following case on x86. 1. chkconfig xend off 2. and do many operations after boot 3. then service xend start --- insmod blkbk fail (probably) On PAE the problem was fixed by loading blkbk/netbk in /etc/init.d/xend. This moves the module load early enough in the system boot to fix it on that arch. So the above solution is not good. If we choice the early module load solution, we should add it into rc.sysinit. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Aron I checked the fragmentation on xen/ia64 with on xen/x86. The following data is /proc/budddyinfo after starting each daemons. 1. buddyinfo of ia64 at the boottime. (dom0_mem=512MB) Mon Oct 2 20:42:24 JST 2006 --iptables--- Node 0, zone DMA 1 2 1 1 1 1 0 0 0 1 9 --iptables--- --portmap--- Node 0, zone DMA 0 1 1 1 1 0 1 0 1 0 1 --portmap--- --ssh--- Node 0, zone DMA 1 3 9 3 1 1 1 1 0 0 0 --ssh--- --sendmail--- Node 0, zone DMA 19 7 5 1 5 1 0 1 0 0 0 --sendmail--- --haldaemon--- Node 0, zone DMA 20 10 5 1 4 0 1 1 0 0 0 --haldaemon--- 2. buddyinfo of x86 at the boottime. (dom0_mem=128MB) Mon Oct 2 21:22:29 JST 2006 --iptables--- Node 0, zone DMA 47 11 4 1 0 1 8 4 1 0 11 --iptables--- --portmap--- Node 0, zone DMA 3 2 0 1 0 0 1 0 1 1 9 --portmap--- --ssh--- Node 0, zone DMA 23 3 1 1 1 1 1 3 2 0 3 --ssh--- --sendmail--- Node 0, zone DMA 26 5 4 0 0 0 4 3 3 1 1 --sendmail--- --haldaemon--- Node 0, zone DMA 44 14 23 14 2 1 1 0 1 0 0 --haldaemon--- --before stating xend--- Node 0, zone DMA 22 25 24 14 2 1 1 0 1 0 0 --before stating xend--- I think fragmentations of ia64 is a little quickly. But allocate of oder:8 is hard on also x86 at the starting of xend. My Xen/IA64 environment have 16 cpus(4 sockets, 8cores, 16threads), and Xen/x86 environment have 2core cpus(1 sockets, 2cores). The difference of the fragmentations may be caused by the number of cpus. What do you think about it? Best Regards, Akio Takebe Akio Takebe wrote: [Fri Sep 29 2006, 11:41:57AM EDT] Hmmm... But this issue was happened on x86-PAE. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201796 Actually with dom0_mem=512M on FC6-ia64, we can success installing blkbk on rare occasions. On PAE the problem was fixed by loading blkbk/netbk in /etc/init.d/xend. This moves the module load early enough in the system boot to fix it on that arch. However on ia64 this isn't sufficient. We need either for the modules to load *earlier* (such as in the initramfs) or we need to use dom0_mem=1G (for example) I have some questions, though: 1. On x86, all of the memory is assigned to dom0, then it balloons to give memory to unpriv'd domains. Why does ia64 give only 512M to dom0 instead of doing the same as x86? 2. Juan says that he can boot x86 xen with only 128M of memory, and there's still enough physically contiguous to load blkbk and netbk when xend loads. So why does ia64 need 8x the memory to do avoid fragmentation? It seems like we must be doing something wrong for memory to fragment so quickly...! Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Akio Takebe wrote: [Mon Oct 02 2006, 08:45:22AM EDT] The following data is /proc/budddyinfo after starting each daemons. 1. buddyinfo of ia64 at the boottime. (dom0_mem=512MB) Mon Oct 2 20:42:24 JST 2006 ---iptables---Node 0, zone DMA 1 2 1 1 1 1 0 0 0 1 9 ---portmap--- Node 0, zone DMA 0 1 1 1 1 0 1 0 1 0 1 ---ssh--- Node 0, zone DMA 1 3 9 3 1 1 1 1 0 0 0 ---sendmail---Node 0, zone DMA 19 7 5 1 5 1 0 1 0 0 0 ---haldaemon--- Node 0, zone DMA 20 10 5 1 4 0 1 1 0 0 0 These numbers seem considerably smaller than x86, even from the start! 2. buddyinfo of x86 at the boottime. (dom0_mem=128MB) ---iptables---Node 0, zone DMA 47 11 4 1 0 1 8 4 1 0 11 ---portmap--- Node 0, zone DMA 3 2 0 1 0 0 1 0 1 1 9 ---ssh--- Node 0, zone DMA 23 3 1 1 1 1 1 3 2 0 3 ---sendmail---Node 0, zone DMA 26 5 4 0 0 0 4 3 3 1 1 ---haldaemon--- Node 0, zone DMA 44 14 23 14 2 1 1 0 1 0 0 ---before xend--- Node 0, zone DMA 22 25 24 14 2 1 1 0 1 0 0 x86 should also have a Normal zone (i.e. non-DMA) which probably has even more available, but doesn't appear in this output. I'm guessing that the netbk and blkbk drivers aren't limited to DMA-capable pages. I think fragmentations of ia64 is a little quickly. But allocate of oder:8 is hard on also x86 at the starting of xend. My Xen/IA64 environment have 16 cpus(4 sockets, 8cores, 16threads), and Xen/x86 environment have 2core cpus(1 sockets, 2cores). The difference of the fragmentations may be caused by the number of cpus. What do you think about it? My ia64 test machine has only 2 cpus, so I don't think that's the only factor. But your data is very interesting, thanks for collecting it! Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Le Vendredi 29 Septembre 2006 16:14, Aron Griffis a écrit : Hi Tristan, Tristan Gingold wrote: [Thu Sep 28 2006, 07:33:28AM EDT] My tests were booting dom0+2*dom_U (using netbk, blkbk and netloop as modules), and doing ping+wget from domU_1. I tested these patches on the Fedora rawhide kernel, but I still see the memory allocation failure when trying to load the netbk or blkbk modules in dom0. I am not sure this is a related issue. I thought that these patches would solve this problem, but the netbk module isn't touched. Could you comment? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Aron
I think this issue do not relate xencomm and copy_from/to_user.
This issue is caused by page_alloc of net/blkbk module.
order:8 is too big.
After forked and terminated some process,
alloc_page() of oder:8 almost fail.
So builtin module don't have this issue because none of process is created
before initialization of these module.
The solutions of this issue are:
1. fix memory allocation of blkbk, netbk
2. builtin blkbk, netbk
3. allocate big memory to dom0
See the following code.
static int __init blkif_init(void)
{
struct page *page;
int i;
if (!is_running_on_xen())
return -ENODEV;
mmap_pages= blkif_reqs * BLKIF_MAX_SEGMENTS_PER_REQUEST;
too big
page = balloon_alloc_empty_page_range(mmap_pages); alloc_page()
if (page == NULL)
return -ENOMEM;
mmap_vstart = (unsigned long)pfn_to_kaddr(page_to_pfn(page));
Best Regards,
Akio Takebe
Hi Tristan,
Tristan Gingold wrote: [Thu Sep 28 2006, 07:33:28AM EDT]
My tests were booting dom0+2*dom_U (using netbk, blkbk and netloop as
modules), and doing ping+wget from domU_1.
I tested these patches on the Fedora rawhide kernel, but I still see
the memory allocation failure when trying to load the netbk or blkbk
modules in dom0.
I thought that these patches would solve this problem, but the netbk
module isn't touched. Could you comment?
Thanks,
Aron
modprobe: page allocation failure. order:8, mode:0xd0
Call Trace:
[a0010001c8e0] show_stack+0x40/0xa0
sp=e0001fdffc20 bsp=e0001fdf9240
[a0010001c970] dump_stack+0x30/0x60
sp=e0001fdffdf0 bsp=e0001fdf9228
[a0010010b220] __alloc_pages+0x500/0x540
sp=e0001fdffdf0 bsp=e0001fdf91b0
[a0010010b310] __get_free_pages+0xb0/0x140
sp=e0001fdffe00 bsp=e0001fdf9188
[a001003c7400] balloon_alloc_empty_page_range+0x80/0x400
sp=e0001fdffe00 bsp=e0001fdf9140
[a002000cc190] netback_init+0x190/0x5c0 [netbk]
sp=e0001fdffe30 bsp=e0001fdf9108
[a001000d1dc0] sys_init_module+0x180/0x400
sp=e0001fdffe30 bsp=e0001fdf9098
[a00100014100] ia64_ret_from_syscall+0x0/0x40
sp=e0001fdffe30 bsp=e0001fdf9098
[a0010620] __start_ivt_text+0x00010620/0x400
sp=e0001fe0 bsp=e0001fdf9098
Mem-info:
DMA per-cpu:
cpu 0 hot: high 42, batch 7 used:14
cpu 0 cold: high 14, batch 3 used:13
DMA32 per-cpu: empty
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages: 22416kB (0kB HighMem)
Active:5579 inactive:9841 dirty:269 writeback:0 unstable:0 free:1401 slab:
1139 mapped:1143 pagetables:151
DMA free:22416kB min:2896kB low:3616kB high:4336kB active:89264kB inactive:
157456kB present:524288kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:
0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
HighMem free:0kB min:512kB low:512kB high:512kB active:0kB inactive:0kB
present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 169*16kB 96*32kB 50*64kB 21*128kB 8*256kB 5*512kB 4*1024kB 1*2048kB 0*
4096kB 0*8192kB 0*16384kB = 22416kB
DMA32: empty
Normal: empty
HighMem: empty
Swap cache: add 0, delete 0, find 0/0, race 0+0
Free swap = 2031584kB
Total swap = 2031584kB
Free swap: 2031584kB
32768 pages of RAM
13277 reserved pages
5037 pages shared
0 pages swap cached
13 pages in page table cache
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Le Vendredi 29 Septembre 2006 16:35, Akio Takebe a écrit : Hi, Aron I think this issue do not relate xencomm and copy_from/to_user. This issue is caused by page_alloc of net/blkbk module. order:8 is too big. After forked and terminated some process, alloc_page() of oder:8 almost fail. So builtin module don't have this issue because none of process is created before initialization of these module. The solutions of this issue are: 1. fix memory allocation of blkbk, netbk 2. builtin blkbk, netbk 3. allocate big memory to dom0 Hi, thank you for explaining this bug. Does this bug occur on x86 ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Tristan Gingold wrote: [Fri Sep 29 2006, 10:44:48AM EDT] Does this bug occur on x86 ? No. Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Aron Tristan Gingold wrote: [Fri Sep 29 2006, 10:44:48AM EDT] Does this bug occur on x86 ? No. Aron Hmmm... But this issue was happened on x86-PAE. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201796 Actually with dom0_mem=512M on FC6-ia64, we can success installing blkbk on rare occasions. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Akio Takebe wrote: [Fri Sep 29 2006, 11:41:57AM EDT] Hmmm... But this issue was happened on x86-PAE. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201796 Actually with dom0_mem=512M on FC6-ia64, we can success installing blkbk on rare occasions. On PAE the problem was fixed by loading blkbk/netbk in /etc/init.d/xend. This moves the module load early enough in the system boot to fix it on that arch. However on ia64 this isn't sufficient. We need either for the modules to load *earlier* (such as in the initramfs) or we need to use dom0_mem=1G (for example) I have some questions, though: 1. On x86, all of the memory is assigned to dom0, then it balloons to give memory to unpriv'd domains. Why does ia64 give only 512M to dom0 instead of doing the same as x86? 2. Juan says that he can boot x86 xen with only 128M of memory, and there's still enough physically contiguous to load blkbk and netbk when xend loads. So why does ia64 need 8x the memory to do avoid fragmentation? It seems like we must be doing something wrong for memory to fragment so quickly...! Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm [2]
Hi, Tristan I tried to test your patches. And I don't meet the network issue. good work!!! I'll try to test my network load test. I had some unaligned access message. For your infomation, I show the log. PING 10.124.36.60 (10.124.36.60) 56(84) bytes of data. kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d681 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d751 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093d800 kernel unaligned access to 0xe00019247a2e, ip=0xa0010093da10 kernel unaligned access to 0xe00019247a1e, ip=0xa0010093da90 64 bytes from 10.124.36.60: icmp_seq=0 ttl=126 time=42.7 ms 64 bytes from 10.124.36.60: icmp_seq=1 ttl=126 time=2.31 ms 64 bytes from 10.124.36.60: icmp_seq=2 ttl=126 time=2.28 ms 64 bytes from 10.124.36.60: icmp_seq=3 ttl=126 time=2.29 ms 64 bytes from 10.124.36.60: icmp_seq=4 ttl=126 time=2.30 ms 64 bytes from 10.124.36.60: icmp_seq=5 ttl=126 time=2.29 ms kernel unaligned access to 0xe0001918d21e, ip=0xa0010093d681 kernel unaligned access to 0xe0001918d21e, ip=0xa0010093d751 kernel unaligned access to 0xe0001918d21e, ip=0xa0010093d800 kernel unaligned access to 0xe0001918d22e, ip=0xa0010093da10 kernel unaligned access to 0xe0001918ca1e, ip=0xa0010093d681 64 bytes from 10.124.36.60: icmp_seq=6 ttl=126 time=32.6 ms 64 bytes from 10.124.36.60: icmp_seq=7 ttl=126 time=2.24 ms 64 bytes from 10.124.36.60: icmp_seq=8 ttl=126 time=2.38 ms 64 bytes from 10.124.36.60: icmp_seq=9 ttl=126 time=2.26 ms 64 bytes from 10.124.36.60: icmp_seq=10 ttl=126 time=2.25 ms 64 bytes from 10.124.36.60: icmp_seq=11 ttl=126 time=2.24 ms Best Regards, Akio Takebe Hi, thanks to Alex and Akio for more torough testing. I have fixed the xentop issue. I think I have also fixed the network issue: during the tests I never hit it. My tests were booting dom0+2*dom_U (using netbk, blkbk and netloop as modules), and doing ping+wget from domU_1. Tristan. ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: xencomm
Hi, Tristan I tested your patch. But after I enabled network on domU and pinged another machine, the following message is shown, then domU hang up. I try to check your patches. [EMAIL PROTECTED] ~]# BUG: soft lockup detected on CPU#0! Modules linked in: netloop xennet xenblk Pid: 0, CPU 0, comm: swapper psr : 021008026030 ifs : 830b ip : [a0010006d9e1] Not tainted ip is at xencomm_mini_hypercall_memory_op+0x1a1/0x1e0 unat: pfs : 830b rsc : 0008 rnat: bsps: pr : 00055a65 ldrs: ccv : fpsr: 0009804c0270033f csd : ssd : b0 : a0010006d9b0 b6 : a0010006d8b0 b7 : a00100693aa0 f6 : 0 f7 : 1003e6db6db6db6db6db7 f8 : 1003e0002e750 f9 : 1003e6a30 f10 : 1003e0002e750 f11 : 1003e6db6db6db6db6db7 r1 : a00101035240 r2 : 000c r3 : 5fff r8 : r9 : 3fff r10 : a00100c13a88 r11 : 04c13a80 r12 : a00100c13a30 r13 : a00100c0c000 r14 : 0001 r15 : 04c13a80 r16 : 0003 r17 : a00100c13ac8 r18 : a00100c13af1 r19 : a00100c13b80 r20 : a00100c13a84 r21 : 0001 r22 : 0002 r23 : 0002 r24 : a00100c13a98 r25 : a00100c13a90 r26 : 0002 r27 : 58434f4d r28 : r29 : 0001 r30 : a000 r31 : a00100c0c318 Call Trace: [a0010001af50] show_stack+0x50/0xa0 sp=a00100c13680 bsp=a00100c0d6c0 [a0010001b820] show_regs+0x820/0x840 sp=a00100c13850 bsp=a00100c0d678 [a001000d7f10] softlockup_tick+0x150/0x180 sp=a00100c13850 bsp=a00100c0d648 [a001000a1190] do_timer+0x990/0x9c0 sp=a00100c13860 bsp=a00100c0d600 [a00100040500] timer_interrupt+0x200/0x3c0 sp=a00100c13860 bsp=a00100c0d5b8 [a001000d8690] handle_IRQ_event+0x190/0x280 sp=a00100c13860 bsp=a00100c0d578 [a001000d8a40] __do_IRQ+0x2c0/0x3e0 sp=a00100c13860 bsp=a00100c0d528 [a00100692600] evtchn_do_upcall+0x160/0x240 sp=a00100c13860 bsp=a00100c0d4a0 [a001000684a0] xen_leave_kernel+0x0/0x3b0 sp=a00100c13860 bsp=a00100c0d4a0 [a0010006d9e0] xencomm_mini_hypercall_memory_op+0x1a0/0x1e0 sp=a00100c13a30 bsp=a00100c0d448 [a00100068e70] ia64_xenmem_reservation_op+0xf0/0x1e0 sp=a00100c13ac0 bsp=a00100c0d410 [a00200049f10] network_alloc_rx_buffers+0x890/0xa00 [xennet] sp=a00100c13af0 bsp=a00100c0d3a0 [a0020004d380] netif_poll+0x1700/0x1b80 [xennet] sp=a00100c13b20 bsp=a00100c0d298 [a00100904310] net_rx_action+0x310/0x6c0 sp=a00100c13ba0 bsp=a00100c0d238 [a00100092db0] __do_softirq+0x1f0/0x380 sp=a00100c13bb0 bsp=a00100c0d1a8 [a00100093080] do_softirq+0x140/0x2a0 sp=a00100c13bb0 bsp=a00100c0d140 [a001000933f0] irq_exit+0x70/0xa0 sp=a00100c13bb0 bsp=a00100c0d128 [a00100692610] evtchn_do_upcall+0x170/0x240 sp=a00100c13bb0 bsp=a00100c0d0a0 [a001000684a0] xen_leave_kernel+0x0/0x3b0 sp=a00100c13bb0 bsp=a00100c0d0a0 [e810] 0xe810 sp=a00100c13d80 bsp=a00100c0d050 [a00100068c10] xen_pal_call_static+0xd0/0x100 sp=a00100c13d80 bsp=a00100c0d030 Its cset is the below. # xm info host : tiger154 release: 2.6.16.29-xen version: #2 SMP Thu Sep 28 10:34:55 JST 2006 machine:
[Xen-ia64-devel] PATCH: xencomm - kernel side
Hi,
taking into account Hollis comments I now submit this patch.
IA64 specific stuff will be posted to xen-ia64-unstable after merge.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID ba96f5f81464dc3db80af0454fb05c73de620637
# Parent cc7a78171c811b9caa5587a0141d8c8477d10ce8
Xencomm support in linux kernel:
* descriptor creation and destruction
* transformation of kernels hypercalls
* transformation of privcmd issued hypercalls.
It must be enabled by architecture config.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r cc7a78171c81 -r ba96f5f81464 linux-2.6-xen-sparse/drivers/xen/Kconfig
--- a/linux-2.6-xen-sparse/drivers/xen/Kconfig Wed Aug 23 12:23:05 2006 +0200
+++ b/linux-2.6-xen-sparse/drivers/xen/Kconfig Wed Aug 23 12:28:12 2006 +0200
@@ -257,4 +257,7 @@ config XEN_SMPBOOT
default y
depends on SMP
+config XEN_XENCOMM
+ bool
+ default n
endif
diff -r cc7a78171c81 -r ba96f5f81464 linux-2.6-xen-sparse/drivers/xen/core/Makefile
--- a/linux-2.6-xen-sparse/drivers/xen/core/Makefile Wed Aug 23 12:23:05 2006 +0200
+++ b/linux-2.6-xen-sparse/drivers/xen/core/Makefile Wed Aug 23 12:28:12 2006 +0200
@@ -11,3 +11,4 @@ obj-$(CONFIG_XEN_SKBUFF) += skbuff.o
obj-$(CONFIG_XEN_SKBUFF) += skbuff.o
obj-$(CONFIG_XEN_REBOOT) += reboot.o
obj-$(CONFIG_XEN_SMPBOOT) += smpboot.o
+obj-$(CONFIG_XEN_XENCOMM) += xencomm.o xencomm_hcall.o
diff -r cc7a78171c81 -r ba96f5f81464 linux-2.6-xen-sparse/drivers/xen/privcmd/Makefile
--- a/linux-2.6-xen-sparse/drivers/xen/privcmd/Makefile Wed Aug 23 12:23:05 2006 +0200
+++ b/linux-2.6-xen-sparse/drivers/xen/privcmd/Makefile Wed Aug 23 12:28:12 2006 +0200
@@ -1,1 +1,3 @@ obj-y:= privcmd.o
obj-y:= privcmd.o
+
+obj-$(CONFIG_XEN_XENCOMM) += xencomm.o
diff -r cc7a78171c81 -r ba96f5f81464 linux-2.6-xen-sparse/drivers/xen/core/xencomm.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux-2.6-xen-sparse/drivers/xen/core/xencomm.c Wed Aug 23 12:28:12 2006 +0200
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2006 Hollis Blanchard [EMAIL PROTECTED], IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/gfp.h
+#include linux/mm.h
+#include asm/page.h
+#include xen/xencomm.h
+#include xen/interface/xen.h
+#include asm/xen/xencomm.h
+
+static int xencomm_debug;
+
+/* translate virtual address to physical address.
+ This is the generic version. Architectures must declare
+ xen_vaddr_to_paddr in asm/xen/xencomm.h, which may be a macro.
+*/
+static unsigned long xen_generic_vaddr_to_paddr(unsigned long vaddr)
+{
+ struct page *page;
+ struct vm_area_struct *vma;
+
+ if (vaddr TASK_SIZE) {
+ /* kernel address */
+ return __pa(vaddr);
+ }
+
+ /* XXX double-check (lack of) locking */
+ vma = find_extend_vma(current-mm, vaddr);
+ if (!vma)
+ return ~0UL;
+
+ page = follow_page(vma, vaddr, 0);
+ if (!page)
+ return ~0UL;
+
+ return (page_to_pfn(page) PAGE_SHIFT) | (vaddr ~PAGE_MASK);
+}
+
+static int xencomm_init(struct xencomm_desc *desc,
+ void *buffer, unsigned long bytes)
+{
+ unsigned long recorded = 0;
+ int i = 0;
+
+ BUG_ON((buffer == NULL) (bytes 0));
+
+ /* record the physical pages used */
+ if (buffer == NULL)
+ desc-nr_addrs = 0;
+
+ while ((recorded bytes) (i desc-nr_addrs)) {
+ unsigned long vaddr = (unsigned long)buffer + recorded;
+ unsigned long paddr;
+ int offset;
+ int chunksz;
+
+ offset = vaddr % PAGE_SIZE; /* handle partial pages */
+ chunksz = min(PAGE_SIZE - offset, bytes - recorded);
+
+ paddr = xen_vaddr_to_paddr(vaddr);
+ if (paddr == ~0UL) {
+ printk(%s: couldn't translate vaddr %lx\n,
+ __func__, vaddr);
+ return -EINVAL;
+ }
+
+ desc-address[i++] = paddr;
+ recorded += chunksz;
+ }
+
+ if (recorded bytes) {
+ printk(%s: could only translate %ld of %ld bytes\n,
+ __func__, recorded, bytes);
+ return -ENOSPC;
+ }
+
+ /* mark remaining addresses invalid (just for safety) */
+ while (i desc-nr_addrs)
+ desc-address[i++] = XENCOMM_INVALID;
+
+ desc-magic = XENCOMM_MAGIC;
+
+ return 0;
+}
+
+static struct xencomm_desc *xencomm_alloc(gfp_t gfp_mask)
+{
+ struct xencomm_desc *desc;
+
+ /* XXX could we call this from irq context? */
+ desc = (struct xencomm_desc *)__get_free_page(gfp_mask);
+ if (desc == NULL) {
+ panic(%s: page
