[XenPPC] Re: xencomm porting and inline handles

2006-09-29 Thread Tristan Gingold 
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: xencomm porting and inline handles

2006-09-28 Thread Tristan Gingold 
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!

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

[XenPPC] Re: xencomm porting and inline handles

2006-09-27 Thread Tristan Gingold 
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.

Tristan.


___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

[XenPPC] Re: xencomm porting and inline handles

2006-09-26 Thread Tristan Gingold 
Le Mardi 12 Septembre 2006 20:37, Hollis Blanchard a écrit :
 Hi Tristan, I've just implemented your inline handle idea.

 The Xen changes are committed to xenppc-unstable.hg . In Xen,
 architectures need to provide:
 - XENCOMM_INLINE_FLAG in arch-foo.h
 - paddr_to_maddr(). I'm open to alternative names, but a standard
 function seems useful outside xencomm. (I wish we had one for Linux.)
 - asm/guest_access.h that just #includes xen/xencomm.h

 Once you have IA64-specific implementations for the above, I will submit
 the whole thing to xen-devel. (Note that Linux doesn't actually have to
 use it right now; it won't break anything.)

 The Linux are committed to linux-ppc-2.6.hg . I think for Linux
 architectures just need to supply:
 - XENCOMM_INLINE_FLAG in arch-foo.h
 - xencomm_vtop()

 I did end up sticking with a separate xencomm_create_inline() function
 because inline handles aren't kernel-accessible pointers, yet normal
 handles are. It does also simplify the code not to have to deal with
 free, as you pointed out. However, notice the problem in
 HYPERVISOR_xen_version(). :(

 We still need to figure out how to share
 arch/powerpc/platforms/xen/hcall.c . If you have any changes you need
 for IA64, please send them to me as individual patches so I can
 incrementally merge them into linux-ppc-2.6.hg. (That will make it much
 easier to understand than the patches you sent out before.)

 There's no rush; this code is working fine for PowerPC so I won't worry
 about IA64 unless/until you have time for it.
Hi,

sorry for the late reply.  I am just back from holidays.

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.

I have have to check performances.  If mini xencomm is good compared to 
inline, we could drop inline.

We are really converging!

Tristan.



___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [Xen-devel] Re: [XenPPC] [RFC][PATCH] Isolating ACM's architecture-dependent parts

2006-09-26 Thread Tristan Gingold 
Le Mardi 26 Septembre 2006 13:56, Stefan Berger a écrit :
 Tristan Gingold [EMAIL PROTECTED] wrote on 09/26/2006 07:54:27
[...]
  Hi,
 
  sorry for the late reply, I am just back from holidays.
 
  It seems you patch has not yet been merged.  Is there any reason ?
  I'd like to see it in the repository, it will help me to enable ACM on
 ia64.

 We wanted to wait for the 3.0.3 close and submit them soon after that.
Sound reasonnable.
Thanks.

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

[XenPPC] Re: [Xen-devel] RFC: xencomm in common

2006-08-24 Thread Tristan Gingold 
Le Jeudi 24 Août 2006 03:44, Isaku Yamahata a écrit :
 Hi Tristan.
 Since I looked the patch very roughly, I might be wrong and parania though.

 xencomm_copy_from_guest(), xencomm_copy_to_guest() converts
 address, then acessses a page.
 The Xen/IA64 P2M table is lockless so that the page can be freed
 by another cpu and used for other purpose at the same time.
 (Actually such a guest behaviour doesn't make sense, but possible.)
 get_page()/put_page() are necessary to prevent such a situation.
 Actually Xen/IA64's vcpu_get_domain_bundle() and
 efi_translate_domain_addr() do it.
Ok, I have to add get_page/put_page.
Thank you for the comment.

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [XenPPC] PATCH: xencomm - kernel side

2006-08-24 Thread Tristan Gingold 
Le Mercredi 23 Août 2006 18:39, Hollis Blanchard a écrit :
 On Wed, 2006-08-23 at 14:31 +0200, Tristan Gingold wrote:
  taking into account Hollis comments I now submit this patch.
 
  IA64 specific stuff will be posted to xen-ia64-unstable after merge.

 NAK pending outcome of other comments.

 Also, please let me add my own Signed-off-by line -- that way we'll know
 that I agree the patch is in fact final (which I don't right now).

 There is at least a /* XXX could we call this from irq context? */
 comment that needs removal. I didn't check the rest of the patch to see
 if you'd followed all my other suggestions.
I think the comment could be removed as this is never call during irq.

Here are the full patches (common and ia64).  Only the common patches (mainly 
11059) was formally submitted.

Tristan.

# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 80137e1a97cf27e026e6eb6a51a5757e160e979a
# Parent  f32793cae274028d939dba4909be280c9df712a5
linux-ia64

diff -r f32793cae274 -r 80137e1a97cf linux-2.6-xen-sparse/arch/ia64/Kconfig
--- a/linux-2.6-xen-sparse/arch/ia64/Kconfig	Wed Aug 23 11:12:25 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/Kconfig	Wed Aug 23 11:17:06 2006 +0200
@@ -530,6 +530,9 @@ config XEN_REBOOT
 
 config XEN_SMPBOOT
 	default n
+
+config XEN_XENCOMM
+	default y
 endif
 
 source drivers/xen/Kconfig
diff -r f32793cae274 -r 80137e1a97cf linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c	Wed Aug 23 11:12:25 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c	Wed Aug 23 11:17:06 2006 +0200
@@ -76,6 +76,8 @@ 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)
 {
@@ -433,6 +435,7 @@ setup_arch (char **cmdline_p)
 
 #ifdef CONFIG_XEN
 	if (is_running_on_xen()) {
+		kernel_start_pa = KERNEL_START - ia64_tpa (KERNEL_START);
 		setup_xen_features();
 		/* Register a call for panic conditions. */
 		notifier_chain_register(panic_notifier_list, xen_panic_block);
diff -r f32793cae274 -r 80137e1a97cf linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c	Wed Aug 23 11:12:25 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c	Wed Aug 23 11:17:06 2006 +0200
@@ -70,7 +70,7 @@ ia64_xenmem_reservation_op(unsigned long
 		reservation.nr_extents = nr_extents;
 
 		dummy = frame_list[0];// re-install tlb entry before hypercall
-		tmp_ret = HYPERVISOR_memory_op(op, reservation);
+		tmp_ret = xencomm_hypercall_memory_op(op, reservation);
 		if (tmp_ret  0) {
 			if (ret == 0) {
 ret = tmp_ret;
@@ -371,8 +371,6 @@ int
 int
 HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
 {
-	__u64 va1, va2, pa1, pa2;
-
 	if (cmd == GNTTABOP_map_grant_ref) {
 		unsigned int i;
 		for (i = 0; i  count; i++) {
@@ -380,29 +378,7 @@ HYPERVISOR_grant_table_op(unsigned int c
 (struct gnttab_map_grant_ref*)uop + i);
 		}
 	}
-	va1 = (__u64)uop  PAGE_MASK;
-	pa1 = pa2 = 0;
-	if ((REGION_NUMBER(va1) == 5) 
-	((va1 - KERNEL_START) = KERNEL_TR_PAGE_SIZE)) {
-		pa1 = ia64_tpa(va1);
-		if (cmd = GNTTABOP_transfer) {
-			static uint32_t uop_size[GNTTABOP_transfer + 1] = {
-sizeof(struct gnttab_map_grant_ref),
-sizeof(struct gnttab_unmap_grant_ref),
-sizeof(struct gnttab_setup_table),
-sizeof(struct gnttab_dump_table),
-sizeof(struct gnttab_transfer),
-			};
-			va2 = (__u64)uop + (uop_size[cmd] * count) - 1;
-			va2 = PAGE_MASK;
-			if (va1 != va2) {
-/* maximum size of uop is 2pages */
-BUG_ON(va2  va1 + PAGE_SIZE);
-pa2 = ia64_tpa(va2);
-			}
-		}
-	}
-	return HYPERVISOR_grant_table_op(cmd, uop, count, pa1, pa2);
+	return xencomm_hypercall_grant_table_op(cmd, uop, count);
 }
 EXPORT_SYMBOL(HYPERVISOR_grant_table_op);
 
diff -r f32793cae274 -r 80137e1a97cf linux-2.6-xen-sparse/include/asm-ia64/hypercall.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Wed Aug 23 11:12:25 2006 +0200
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Wed Aug 23 11:17:06 2006 +0200
@@ -33,11 +33,12 @@
 #ifndef __HYPERCALL_H__
 #define __HYPERCALL_H__
 
-#include linux/string.h /* memcpy() */
-
 #ifndef __HYPERVISOR_H__
 # error please don't include this file directly
 #endif
+
+#include xen/xencomm_hcall.h
+struct xencomm_handle;
 
 /*
  * Assembler stubs for hyper-calls.
@@ -157,16 +158,10 @@
 	(type)__res;\
 })
 
-static inline int
-HYPERVISOR_sched_op_compat(
-int cmd, unsigned long arg)
-{
-	return _hypercall2(int, sched_op_compat, cmd, arg);
-}
-
-static inline int
-HYPERVISOR_sched_op(
-	int cmd, void *arg)
+
+static inline int
+xencomm_arch_hypercall_sched_op(
+	int cmd, struct xencomm_handle *arg)
 {
 	return _hypercall2(int, sched_op, cmd, arg);
 }
@@ -181,25 +176,22 @@ HYPERVISOR_set_timer_op(
 }
 
 static inline int
-HYPERVISOR_dom0_op(
-dom0_op_t

[XenPPC] Re: [Xen-devel] RFC: xencomm in common

2006-08-23 Thread Tristan Gingold 
Le Lundi 21 Août 2006 11:41, Keir Fraser a écrit :
 On 21/8/06 10:20 am, Tristan Gingold [EMAIL PROTECTED] wrote:
  Fine in principle. Specific comments:
   * powerpc should be cleaned up at the same time to use the common
  infrastructure. I don't want duplicated code hanging around in
  arch/powerpc
 
  I have attached a blindly-made patch again powerpc files.
  If ppc people could check this, I'd be happy.
 
   * The code you add to common/ should obey the coding style of other
  files in that directory
   * Arguably we should have an asm-generic for the xencomm guest-access
  macros. That's a Linux-ism which I think fits well in this particular
  case.
 
  Taken into account in this updated patch.

 Looks better. I assume you'll resend with signed-off-by when you want these
 applied.
Hi,

here are the signed-off-by patches for xen.
I took the liberty to add Hollis Blanchard in signed-off-by of the first patch 
because he is the primary author of these files.

I don't know wether or not these patches should be put off beacause of the 
freeze, but they are a no-op for x86.

Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID cbe47a6938d17983c29d6baab5b6f81b9485451a
# Parent  91169603a8e8dded9eba6cb6c3421b5d58a85a97
Xencomm in common code.

Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]

diff -r 91169603a8e8 -r cbe47a6938d1 xen/common/Makefile
--- a/xen/common/Makefile	Tue Aug 22 14:45:49 2006 -0600
+++ b/xen/common/Makefile	Wed Aug 23 08:08:14 2006 +0200
@@ -26,6 +26,8 @@ obj-y += vsprintf.o
 obj-y += vsprintf.o
 obj-y += xmalloc.o
 
+obj-$(HAS_XENCOMM) += xencomm.o
+
 obj-$(perfc)   += perfc.o
 obj-$(crash_debug) += gdbstub.o
 
diff -r 91169603a8e8 -r cbe47a6938d1 xen/include/public/xencomm.h
--- a/xen/include/public/xencomm.h	Tue Aug 22 14:45:49 2006 -0600
+++ b/xen/include/public/xencomm.h	Wed Aug 23 08:08:14 2006 +0200
@@ -34,4 +34,15 @@ struct xencomm_desc {
 uint64_t address[0];
 };
 
+/* Inline Xencomm.
+   If the inline flag is set, the descriptor is simply a the flagged
+   physical address of the buffer which is known to be contiguous in
+   physical memory.  Because the kernels are often 1:1 mapped, this is
+   interesting for kernel issued hypercalls.  */
+/* These macros should be defined by arch-xxx.h:
+   XENCOMM_IS_INLINE(addr): true if ADDR is an inline address.
+   XENCOMM_INLINE_ADDR(addr): extract the physical address (as an unsigned).
+   XENCOMM_INLINE_MAKE(addr): flag ADDR and returns an unsigned.
+*/
+
 #endif /* _XEN_XENCOMM_H_ */
diff -r 91169603a8e8 -r cbe47a6938d1 xen/common/xencomm.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +
+++ b/xen/common/xencomm.c	Wed Aug 23 08:08:14 2006 +0200
@@ -0,0 +1,348 @@
+/*
+ * 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-generic/xencomm_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
+
+/**
+ * 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 )
+printf(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

[XenPPC] PATCH: xencomm - kernel side

2006-08-23 Thread Tristan Gingold 
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

Re: [Xen-devel] Re: [XenPPC] Xencomm for xen/ia64

2006-08-22 Thread Tristan Gingold 
Le Lundi 21 Août 2006 18:24, Hollis Blanchard a écrit :
 On Mon, 2006-08-21 at 08:46 +0200, Tristan Gingold wrote:
  Le Vendredi 18 Août 2006 18:39, Hollis Blanchard a écrit :
   On Fri, 2006-08-18 at 11:04 +0200, Tristan Gingold wrote:
Le Jeudi 17 Août 2006 20:35, Hollis Blanchard a écrit :
  
   I'm not sure how it simplifies hcall.c. You always need to create
   xencomm descriptors, unless you're manually guaranteeing that the
   dom0_op structures do not cross page boundaries (in which case they are
   not linear in memory). Is that what you're doing?
 
  For hypercalls issued through privcmd, xencomm descriptors are always
  created. For hypercalls directly issued by kernel inline xencomm is
  prefered.

 How do you guarantee that kernel-created data structures are not
 crossing page boundaries? The patch you sent does not do this. Without
 that, xencomm_inline() simply cannot work except by luck.
Kernel-created structures are linear in guest physical space, so it doesn't 
matter if they cross page boundaries.

 We need to do one more thing though: we *also* need to change fix
 up the size of longs and pointers in our code (since 32-bit
 userland is passing structures to a 64-bit kernel). So perhaps
 these two fixup passes could be split: we could share the xencomm
 conversion in common code, and PPC arch code could contain the size
 munging.
   
Are structure sizes different on 32 and 64 bits ?
  
   Yes, in particular longs and pointers.
 
  But are longs and pointers used directly in Xen hypercalls ?  I though
  only sized types (uintNN_t  others) are used.

 I have put a lot of work into converting types to be explicitly sized,
 but there are still missing pieces. I think Jimi got tired of it, and
 started doing the Linux compat32 conversion. For example, see
 drivers/xen/privcmd/compat_privcmd.c .
Ok.

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [XenPPC] RFC: xencomm - linux side

2006-08-22 Thread Tristan Gingold 
Le Lundi 21 Août 2006 21:07, Hollis Blanchard a écrit :
 On Mon, 2006-08-21 at 17:18 +0200, Tristan Gingold wrote:
  I am posting the linux xencomm code for review.  I'd plan to submit soon
  unless comments/remarks.

 NAK. I'm still waiting to hear back about how you can use
 xencomm_inline() without worrying about page boundaries.
More elaborated answer:

On linux/ia64, kernel is linearly mapped into guest physical memory.  The same 
is true for process kernel stacks.  Therefore all kernels structure are 
linear in guest physical memory.

Kernel data may of course cross page boundaries.  But Xen can correctly handle 
this using only the guest physical address.

Is something wrong ?  Is something that don't apply on powerpc ?

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [Xen-devel] Re: [XenPPC] Xencomm for xen/ia64

2006-08-21 Thread Tristan Gingold 
Le Vendredi 18 Août 2006 18:39, Hollis Blanchard a écrit :
 On Fri, 2006-08-18 at 11:04 +0200, Tristan Gingold wrote:
  Le Jeudi 17 Août 2006 20:35, Hollis Blanchard a écrit :
If we agree on using xencomm we will have to work with xen/ppc people
in order not to duplicate the code.  Hopefully it is rather small.  I
have enhanced the xencomm code so that the kernel may not use xencomm
area but pass the guest physical address with a flag to know the
space is linear in memory.
   
At this time I can boot dom0 with xencomm.  I will publish the patch
later.
  
   I'll be very interested to see your patch. I guess the flag is a
   reserved bit in the (physical) address passed from kernel to
   hypervisor?
 
  Yes.
 
   Does that really gain much performance?
 
  I don't think performance will be decreased.  But it simplifies hcall.c a
  lot!

 I'm not sure how it simplifies hcall.c. You always need to create
 xencomm descriptors, unless you're manually guaranteeing that the
 dom0_op structures do not cross page boundaries (in which case they are
 not linear in memory). Is that what you're doing?
For hypercalls issued through privcmd, xencomm descriptors are always created.
For hypercalls directly issued by kernel inline xencomm is prefered.

  Using xencomm_create (and __get_free_page) is tricky: it doesn't work all
  the time and at least it doesn't work very early duing kernel boot.
  Using xencomm_create_mini is possible but rather heavy.

 Heavy meaning what? It adds almost no CPU overhead (just checking for
 crossing page boundaries), and the stack space used is 64 bytes.
It is cumbersome: you have to declare the stack space, to do the call and to 
check the result.  Using inline xencomm is just a call.

 The only reason it's not the preferred API is that a) it's a little
 cumbersome to use (in that the caller must manually allocate stack
 space), and b) it handles only up to two pages worth of data.

   I guess you will need to do the same thing we need to with privcmd
   ioctl handling, i.e. copy and modify the pointers in the dom0_op data
   structures passed to the kernel. :(
 
  Yes.  hcall.c *has* to be shared between ppc and ia64.
 
   We need to do one more thing though: we *also* need to change fix up
   the size of longs and pointers in our code (since 32-bit userland is
   passing structures to a 64-bit kernel). So perhaps these two fixup
   passes could be split: we could share the xencomm conversion in common
   code, and PPC arch code could contain the size munging.
 
  Are structure sizes different on 32 and 64 bits ?

 Yes, in particular longs and pointers.
But are longs and pointers used directly in Xen hypercalls ?  I though only 
sized types (uintNN_t  others) are used.

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [XenPPC] Xencomm on ia64 - The patches

2006-08-21 Thread Tristan Gingold 
Le Vendredi 18 Août 2006 23:21, Hollis Blanchard a écrit :
 On Fri, 2006-08-18 at 18:02 +0200, Tristan Gingold wrote:
  these are the patches to port xencomm on ia64.  This is just an RFC.  I
  have to clean-up the code so that it could be shared between ia64 and
  ppc.

 Great! Your patches were a little noisy though; they had some unrelated
 and whitespace changes.

  I have added the xencomm_inline feature which makes (IMHO) hcall.c more
  readable and safer (particularly at boot time).  Wether or not
  xencomm_mini should be deprecated is a question for ppc people
  (xencomm_mini is buggy: the area should be reserved as an array of struct
  xencomm_mini for alignment).

 Good point.

  I have also fixed a few bugs in guest_access.h

 Do you think you could split those out as a diff to
 xen/include/asm-powerpc/guest_access.h, to be applied before we move it?
Ok.

  Many files should be shared between ia64 and ppc.
  In xen:
  * guest_access.h should be the same.  I will propose to put as
  include/xen/xencomm_access.h

 And then xen/include/asm-{powerpc,ia64}/guest_access.h would just
 #include xen/xencomm_access.h? Sounds good to me.
Ok.

  * usercopy.c sould be shared too.  The paddr_to_maddr() function should
  be defined in arch files as xencomm_paddr_to_maddr.  I will propose to
  put this file into xen/common/xencomm.c

 Agreed.

  In linux:
  * drivers/xen/core/xencomm.c should be shared.  We just need to agree on
  xen_pa().  On linux-ia64, __pa() doesn't work for this use. 
  asm/xencomm.h should define this macro/function.

 We got rid of __kern_paddr entirely, so __pa() shouldn't be a problem.
 If you check the current PPC tree (specifically changeset 0b82e0cba7d3),
 you'll find we always use the follow_vma() routine now. Please make sure
 you pull down that changeset, as I'd hate to lose changes because you
 were working from something older.
Ok, I will updated.

  * hcall.c should be shared because it is the biggest and the most boring
  file. This won't be that easy, but it will try to made a proposal soon.

 Sure.

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [XenPPC] Xencomm on ia64 - The patches

2006-08-21 Thread Tristan Gingold 
Le Vendredi 18 Août 2006 23:21, Hollis Blanchard a écrit :
 On Fri, 2006-08-18 at 18:02 +0200, Tristan Gingold wrote:
[...]
  I have also fixed a few bugs in guest_access.h

 Do you think you could split those out as a diff to
 xen/include/asm-powerpc/guest_access.h, to be applied before we move it?
Here is the patch.

Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 102ff2fdb6db6449ae8402932422039c7b59872e
# Parent  d42e9a6f537883c707ee5f7dd2a2c980881934c8
Bug fix for field macros.
Use _d/_s local variables rather than _x/_y (more readable).

Signed-off-by: Tristan Gingold [EMAIL PROTECTED]

diff -r d42e9a6f5378 -r 102ff2fdb6db xen/include/asm-powerpc/guest_access.h
--- a/xen/include/asm-powerpc/guest_access.h	Fri Aug 18 15:01:04 2006 -0600
+++ b/xen/include/asm-powerpc/guest_access.h	Mon Aug 21 07:45:22 2006 +0200
@@ -16,6 +16,7 @@
  * Copyright (C) IBM Corp. 2006
  *
  * Authors: Hollis Blanchard [EMAIL PROTECTED]
+ *  Tristan Gingold [EMAIL PROTECTED]
  */
 
 #ifndef __PPC_GUEST_ACCESS_H__
@@ -74,29 +75,29 @@ extern int xencomm_handle_is_null(void *
 __copy_field_from_guest(ptr, hnd, field)
 
 #define __copy_to_guest_offset(hnd, idx, ptr, nr) ({\
-const typeof(ptr) _x = (hnd).p; \
-const typeof(ptr) _y = (ptr);   \
-xencomm_copy_to_guest(_x, _y, sizeof(*_x)*(nr), sizeof(*_x)*(idx)); \
+const typeof(ptr) _d = (hnd).p; \
+const typeof(ptr) _s = (ptr);   \
+xencomm_copy_to_guest(_d, _s, sizeof(*_s)*(nr), sizeof(*_s)*(idx)); \
 })
 
 #define __copy_field_to_guest(hnd, ptr, field) ({   \
-const int _off = offsetof(typeof(*ptr), field);  \
-const typeof((ptr)-field) _x = (hnd).p-field;   \
-const typeof((ptr)-field) _y = (ptr)-field; \
-xencomm_copy_to_guest(_x, _y, sizeof(*_x), sizeof(*_x)*(_off)); \
+const int _off = offsetof(typeof(*ptr), field); \
+const typeof(ptr) _d = (hnd).p; \
+const typeof((ptr)-field) _s = (ptr)-field; \
+xencomm_copy_to_guest(_d, _s, sizeof(*_s), _off); \
 })
 
 #define __copy_from_guest_offset(ptr, hnd, idx, nr) ({  \
-const typeof(ptr) _x = (hnd).p; \
-const typeof(ptr) _y = (ptr);   \
-xencomm_copy_from_guest(_y, _x, sizeof(*_x)*(nr), sizeof(*_x)*(idx));  \
+const typeof(ptr) _s = (hnd).p; \
+const typeof(ptr) _d = (ptr);   \
+xencomm_copy_from_guest(_d, _s, sizeof(*_s)*(nr), sizeof(*_s)*(idx));  \
 })
 
 #define __copy_field_from_guest(ptr, hnd, field) ({ \
 const int _off = offsetof(typeof(*ptr), field); \
-const typeof((ptr)-field) _x = (hnd).p-field;   \
-const typeof((ptr)-field) _y = (ptr)-field; \
-xencomm_copy_to_guest(_y, _x, sizeof(*_x), sizeof(*_x)*(_off)); \
+const typeof(ptr) _s = (hnd).p; \
+const typeof((ptr)-field) _d = (ptr)-field; \
+xencomm_copy_from_guest(_d, _s, sizeof(*_d), _off); \
 })
 
 #endif /* __PPC_GUEST_ACCESS_H__ */
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [XenPPC] Xencomm on ia64 - The patches

2006-08-21 Thread Tristan Gingold 
Le Lundi 21 Août 2006 13:13, Jimi Xenidis a écrit :
 On Aug 21, 2006, at 3:47 AM, Tristan Gingold wrote:
  Le Vendredi 18 Août 2006 23:21, Hollis Blanchard a écrit :
  On Fri, 2006-08-18 at 18:02 +0200, Tristan Gingold wrote:
 
  [...]
 
  I have also fixed a few bugs in guest_access.h
 
  Do you think you could split those out as a diff to
  xen/include/asm-powerpc/guest_access.h, to be applied before we
  move it?
 
  Here is the patch.

 your patch inlined below, does not do anything other than rename
 _x,_y to _d,_s.. am I missing something?
Yes.  See below.

  #define __copy_field_to_guest(hnd, ptr, field) ({   \
  -const int _off = offsetof(typeof(*ptr),
  field);  \
  -const typeof((ptr)-field) _x = (hnd).p-field;   \
  -const typeof((ptr)-field) _y = (ptr)-field; \
  -xencomm_copy_to_guest(_x, _y, sizeof(*_x), sizeof(*_x)*(_off)); \
  +const int _off = offsetof(typeof(*ptr), field); \
  +const typeof(ptr) _d = (hnd).p; \
  +const typeof((ptr)-field) _s = (ptr)-field; \
  +xencomm_copy_to_guest(_d, _s, sizeof(*_s), _off); \
Cf how _x/_d are declared and the parameters of xencomm_copy_to_guest.

  #define __copy_field_from_guest(ptr, hnd, field) ({ \
   const int _off = offsetof(typeof(*ptr), field); \
  -const typeof((ptr)-field) _x = (hnd).p-field;   \
  -const typeof((ptr)-field) _y = (ptr)-field; \
  -xencomm_copy_to_guest(_y, _x, sizeof(*_x), sizeof(*_x)*(_off)); \
  +const typeof(ptr) _s = (hnd).p; \
  +const typeof((ptr)-field) _d = (ptr)-field; \
  +xencomm_copy_from_guest(_d, _s, sizeof(*_d), _off); \
Idem.

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

[XenPPC] Xencomm on ia64 - The patches

2006-08-18 Thread Tristan Gingold 
Hi,

these are the patches to port xencomm on ia64.  This is just an RFC.  I have 
to clean-up the code so that it could be shared between ia64 and ppc.

I have added the xencomm_inline feature which makes (IMHO) hcall.c more 
readable and safer (particularly at boot time).  Wether or not xencomm_mini 
should be deprecated is a question for ppc people (xencomm_mini is buggy: the 
area should be reserved as an array of struct xencomm_mini for alignment).

I have also fixed a few bugs in guest_access.h

Many files should be shared between ia64 and ppc.
In xen:
* guest_access.h should be the same.  I will propose to put as 
include/xen/xencomm_access.h
* usercopy.c sould be shared too.  The paddr_to_maddr() function should be 
defined in arch files as xencomm_paddr_to_maddr.  I will propose to put this 
file into xen/common/xencomm.c

In linux:
* drivers/xen/core/xencomm.c should be shared.  We just need to agree on
xen_pa().  On linux-ia64, __pa() doesn't work for this use.  asm/xencomm.h 
should define this macro/function.
* hcall.c should be shared because it is the biggest and the most boring file.  
This won't be that easy, but it will try to made a proposal soon.

Tristan.
diff -r 8c6bb45901e7 linux-2.6-xen-sparse/arch/ia64/Kconfig
--- a/linux-2.6-xen-sparse/arch/ia64/Kconfig	Wed Aug 16 14:28:57 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/Kconfig	Fri Aug 18 14:26:09 2006 +0200
@@ -530,6 +530,9 @@ config XEN_REBOOT
 
 config XEN_SMPBOOT
 	default n
+
+config XEN_XENCOMM
+	default y
 endif
 
 source drivers/xen/Kconfig
diff -r 8c6bb45901e7 linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c	Wed Aug 16 14:28:57 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c	Fri Aug 18 14:26:09 2006 +0200
@@ -433,6 +433,9 @@ setup_arch (char **cmdline_p)
 
 #ifdef CONFIG_XEN
 	if (is_running_on_xen()) {
+		extern unsigned long kernel_start_pa;
+
+		kernel_start_pa = KERNEL_START - ia64_tpa (KERNEL_START);
 		setup_xen_features();
 		/* Register a call for panic conditions. */
 		notifier_chain_register(panic_notifier_list, xen_panic_block);
diff -r 8c6bb45901e7 linux-2.6-xen-sparse/arch/ia64/xen/Makefile
--- a/linux-2.6-xen-sparse/arch/ia64/xen/Makefile	Wed Aug 16 14:28:57 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/Makefile	Fri Aug 18 14:26:09 2006 +0200
@@ -3,6 +3,6 @@
 #
 
 obj-y := hypercall.o xenivt.o xenentry.o xensetup.o xenpal.o xenhpski.o \
-	 hypervisor.o pci-dma-xen.o util.o
+	 hypervisor.o pci-dma-xen.o util.o hcall.o
 
 pci-dma-xen-y := ../../i386/kernel/pci-dma-xen.o
diff -r 8c6bb45901e7 linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c	Wed Aug 16 14:28:57 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/hypervisor.c	Fri Aug 18 14:26:09 2006 +0200
@@ -371,8 +371,6 @@ int
 int
 HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count)
 {
-	__u64 va1, va2, pa1, pa2;
-
 	if (cmd == GNTTABOP_map_grant_ref) {
 		unsigned int i;
 		for (i = 0; i  count; i++) {
@@ -380,29 +378,7 @@ HYPERVISOR_grant_table_op(unsigned int c
 (struct gnttab_map_grant_ref*)uop + i);
 		}
 	}
-	va1 = (__u64)uop  PAGE_MASK;
-	pa1 = pa2 = 0;
-	if ((REGION_NUMBER(va1) == 5) 
-	((va1 - KERNEL_START) = KERNEL_TR_PAGE_SIZE)) {
-		pa1 = ia64_tpa(va1);
-		if (cmd = GNTTABOP_transfer) {
-			static uint32_t uop_size[GNTTABOP_transfer + 1] = {
-sizeof(struct gnttab_map_grant_ref),
-sizeof(struct gnttab_unmap_grant_ref),
-sizeof(struct gnttab_setup_table),
-sizeof(struct gnttab_dump_table),
-sizeof(struct gnttab_transfer),
-			};
-			va2 = (__u64)uop + (uop_size[cmd] * count) - 1;
-			va2 = PAGE_MASK;
-			if (va1 != va2) {
-/* maximum size of uop is 2pages */
-BUG_ON(va2  va1 + PAGE_SIZE);
-pa2 = ia64_tpa(va2);
-			}
-		}
-	}
-	return HYPERVISOR_grant_table_op(cmd, uop, count, pa1, pa2);
+	return HYPERVISOR_grant_table_op(cmd, uop, count);
 }
 EXPORT_SYMBOL(HYPERVISOR_grant_table_op);
 
diff -r 8c6bb45901e7 linux-2.6-xen-sparse/drivers/xen/Kconfig
--- a/linux-2.6-xen-sparse/drivers/xen/Kconfig	Wed Aug 16 14:28:57 2006 -0600
+++ b/linux-2.6-xen-sparse/drivers/xen/Kconfig	Fri Aug 18 14:26:09 2006 +0200
@@ -257,4 +257,7 @@ config XEN_SMPBOOT
 	default y
 	depends on SMP
 
+config XEN_XENCOMM
+	bool
+	default n
 endif
diff -r 8c6bb45901e7 linux-2.6-xen-sparse/drivers/xen/core/Makefile
--- a/linux-2.6-xen-sparse/drivers/xen/core/Makefile	Wed Aug 16 14:28:57 2006 -0600
+++ b/linux-2.6-xen-sparse/drivers/xen/core/Makefile	Fri Aug 18 14:26:09 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
diff -r 8c6bb45901e7 linux-2.6-xen-sparse/drivers/xen/privcmd/privcmd.c
--- a/linux-2.6-xen-sparse/drivers/xen/privcmd/privcmd.c	Wed Aug 16 14:28:57 2006 -0600
+++

[XenPPC] Xencomm for xen/ia64

2006-08-16 Thread Tristan Gingold 
Hi,

[xen-ppc-devel is on CC just for info]

I am porting xen-ppc's xencomm to xen/ia64.
Currently on xen/ia64 copy_from/to_guest uses guest virtual address.  This 
works well as long as the virtual addresses are in the TLB.  When not in TLB 
(or vTLB) the hypercall can't success without domain help.  The possible 
solution is either to touch the memory areas before doing the hypercall 
and/or restarting the hypercall.

Touching the memory area is an hack and we can't be sure it works.
Restarting the hypercall is not always possible (some hypercalls are atomic: 
DOM0_SHADOW_CONTROL_OP_CLEAN) or can result in a live-lock.

The most simple solution is to use guest physical addresses instead of virtual 
addresses.

For hypercalls directly issued by the kernel, the translation is very easy.  
For hypercalls (indirectly) issued by dom0 though the ioctl, kernel has to do 
the translation.  Because it may not be linear in guest physical memory the 
parameter is a pointer to a list of page (xencomm).

The pros of such approach is simplicity and reliability.

The main cons is maybe speed.  Hopefully the most frequent hypercalls (dom0vp 
and eoi) either don't use in memory parameters (dom0vp) or may be modified so 
that they pass parameters through registers (eoi).  IMHO speed won't be 
affected.

Access to guest memory is also performed during vcpu_translate (to read vhpt) 
or EFI/PAL/SAL calls.  We can either do not change that code (ie both 
mechanisms are not exclusive) or change the code.  This point will be 
postpone.

Comments are welcome (I won't work tomorrow, so you have more time).

If we agree on using xencomm we will have to work with xen/ppc people in order 
not to duplicate the code.  Hopefully it is rather small.  I have enhanced 
the xencomm code so that the kernel may not use xencomm area but pass the 
guest physical address with a flag to know the space is linear in memory.

At this time I can boot dom0 with xencomm.  I will publish the patch later.

Tristan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel