[PATCH] Linux: 6 arguments hypercall v3

[PATCH] Linux: 6 arguments hypercall v3

[Jean Guyader]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

Hi,

This patch implements the 6 arguments hypercalls.
The sixth argument is passed using ebp or r9.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>

http://lists.xensource.com/archives/html/xen-devel/2010-12/msg00945.html

Jean

[-- Attachment #2: 6arg-hypercall.patch --]
[-- Type: text/plain, Size: 3684 bytes --]

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index d240ea9..5c99ebc 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -74,8 +74,7 @@
  *     - clobber the rest
  *
  * The result certainly isn't pretty, and it really shows up cpp's
- * weakness as as macro language.  Sorry.  (But let's just give thanks
- * there aren't more than 5 arguments...)
+ * weakness as as macro language.  Sorry.
  */
 
 extern struct { char _entry[32]; } hypercall_page[];
@@ -91,6 +90,18 @@ extern struct { char _entry[32]; } hypercall_page[];
 #define __HYPERCALL_ARG3REG	"edx"
 #define __HYPERCALL_ARG4REG	"esi"
 #define __HYPERCALL_ARG5REG	"edi"
+
+/*
+ * On 32b we are out of free registers to pass in
+ * the 6th argument of the hypercall, the last one
+ * available is ebp.
+ * %ebp is already being used by linux so we save it
+ * then we move %eax which is the 6th argument in %ebp.
+ * On the way back of the hypercall we restore %ebp.
+ */
+#define __HYPERCALL_ARG6REG	"eax"
+#define __HYPERCALL6_PRE        "push %%ebp ; mov %%eax, %%ebp ; "
+#define __HYPERCALL6_POST       ";" "pop %%ebp"
 #else
 #define __HYPERCALL_RETREG	"rax"
 #define __HYPERCALL_ARG1REG	"rdi"
@@ -98,6 +109,9 @@ extern struct { char _entry[32]; } hypercall_page[];
 #define __HYPERCALL_ARG3REG	"rdx"
 #define __HYPERCALL_ARG4REG	"r10"
 #define __HYPERCALL_ARG5REG	"r8"
+#define __HYPERCALL_ARG6REG	"r9"
+#define __HYPERCALL6_PRE        ""
+#define __HYPERCALL6_POST       ""
 #endif
 
 #define __HYPERCALL_DECLS						\
@@ -106,7 +120,8 @@ extern struct { char _entry[32]; } hypercall_page[];
 	register unsigned long __arg2 asm(__HYPERCALL_ARG2REG) = __arg2; \
 	register unsigned long __arg3 asm(__HYPERCALL_ARG3REG) = __arg3; \
 	register unsigned long __arg4 asm(__HYPERCALL_ARG4REG) = __arg4; \
-	register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5;
+	register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5; \
+	register unsigned long __arg6 asm(__HYPERCALL_ARG6REG) = __arg6;
 
 #define __HYPERCALL_0PARAM	"=r" (__res)
 #define __HYPERCALL_1PARAM	__HYPERCALL_0PARAM, "+r" (__arg1)
@@ -114,6 +129,7 @@ extern struct { char _entry[32]; } hypercall_page[];
 #define __HYPERCALL_3PARAM	__HYPERCALL_2PARAM, "+r" (__arg3)
 #define __HYPERCALL_4PARAM	__HYPERCALL_3PARAM, "+r" (__arg4)
 #define __HYPERCALL_5PARAM	__HYPERCALL_4PARAM, "+r" (__arg5)
+#define __HYPERCALL_6PARAM	__HYPERCALL_5PARAM, "+r" (__arg6)
 
 #define __HYPERCALL_0ARG()
 #define __HYPERCALL_1ARG(a1)						\
@@ -126,7 +142,10 @@ extern struct { char _entry[32]; } hypercall_page[];
 	__HYPERCALL_3ARG(a1,a2,a3)	__arg4 = (unsigned long)(a4);
 #define __HYPERCALL_5ARG(a1,a2,a3,a4,a5)				\
 	__HYPERCALL_4ARG(a1,a2,a3,a4)	__arg5 = (unsigned long)(a5);
+#define __HYPERCALL_6ARG(a1,a2,a3,a4,a5,a6)				\
+	__HYPERCALL_5ARG(a1,a2,a3,a4,a5) __arg6 = (unsigned long)(a6);
 
+#define __HYPERCALL_CLOBBER6	"memory"
 #define __HYPERCALL_CLOBBER5	"memory"
 #define __HYPERCALL_CLOBBER4	__HYPERCALL_CLOBBER5, __HYPERCALL_ARG5REG
 #define __HYPERCALL_CLOBBER3	__HYPERCALL_CLOBBER4, __HYPERCALL_ARG4REG
@@ -200,6 +219,17 @@ extern struct { char _entry[32]; } hypercall_page[];
 	(type)__res;							\
 })
 
+#define _hypercall6(type, name, a1, a2, a3, a4, a5, a6)			\
+({									\
+	__HYPERCALL_DECLS;						\
+	__HYPERCALL_6ARG(a1, a2, a3, a4, a5, a6);			\
+	asm volatile (__HYPERCALL6_PRE __HYPERCALL __HYPERCALL6_POST	\
+		      : __HYPERCALL_6PARAM				\
+		      : __HYPERCALL_ENTRY(name)				\
+		      : __HYPERCALL_CLOBBER6);				\
+	(type)__res;							\
+})
+
 static inline long
 privcmd_call(unsigned call,
 	     unsigned long a1, unsigned long a2,

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] Linux: 6 arguments hypercall v3

[Jeremy Fitzhardinge]

On 06/24/2011 08:13 AM, Jean Guyader wrote:
> Hi,
>
> This patch implements the 6 arguments hypercalls.
> The sixth argument is passed using ebp or r9.
>
> Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
> Reviewed-by: Ian Campbell <ian.campbell@citrix.com>

Looks OK, but I am still a bit worried about triggering compiler bugs
with register pressure.  What compilers have you tested?

What hypercalls have 6 args?

    J

Re: [PATCH] Linux: 6 arguments hypercall v3

[Jean Guyader]

On 24/06 06:26, Jeremy Fitzhardinge wrote:
> On 06/24/2011 08:13 AM, Jean Guyader wrote:
> > Hi,
> >
> > This patch implements the 6 arguments hypercalls.
> > The sixth argument is passed using ebp or r9.
> >
> > Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
> > Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Looks OK, but I am still a bit worried about triggering compiler bugs
> with register pressure.  What compilers have you tested?
> 

I only tested it gcc 4.4.

We could still use the v2 which is not as nice, but it doesn't try to
load eax twice. Let me know which one you will feel better about.

> What hypercalls have 6 args?
> 

I'm planning on upstream v4v which is a inter vm memory transport
based on hypervisor memcpy. The send hypercall takes 6 arguments.

Jean

Re: [PATCH] Linux: 6 arguments hypercall v3

[Jeremy Fitzhardinge]

On 06/24/2011 03:15 PM, Jean Guyader wrote:
> I only tested it gcc 4.4.
>
> We could still use the v2 which is not as nice, but it doesn't try to
> load eax twice. Let me know which one you will feel better about.

I feel best about the one you've successfully tested with a number of
older compilers ;)

>> What hypercalls have 6 args?
>>
> I'm planning on upstream v4v which is a inter vm memory transport
> based on hypervisor memcpy. The send hypercall takes 6 arguments.

Does it have to?  Couldn't it take a pointer to a struct or something?

    J

Re: Re: [PATCH] Linux: 6 arguments hypercall v3

[James]

On Fri, Jun 24, 2011 at 03:43:18PM -0700, Jeremy Fitzhardinge wrote:
> On 06/24/2011 03:15 PM, Jean Guyader wrote:
> > I only tested it gcc 4.4.
> >
> > We could still use the v2 which is not as nice, but it doesn't try to
> > load eax twice. Let me know which one you will feel better about.

Given "that loading r0 twice" is in the gcc documentation as an
example at

http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#index-extended-_0040code_007basm_007d-2601

I think it's fair to use that.

> I feel best about the one you've successfully tested with a number of
> older compilers ;)

what compilers work to build modern linux? We'll give a goodly set of them
a try if that makes everyone feel better.

> Does it have to?  Couldn't it take a pointer to a struct or something?

Yes we could change the API, make sure the struct is visible on all
CPUs, making it incompatible with the existing code, but I think that
misses the point: Xen is written to support 6 argument hypercalls, but
32 bit dom0 is missing the functionality to call them. Surely that's 
something we should fix?

James.

Re: Re: [PATCH] Linux: 6 arguments hypercall v3

[Jeremy Fitzhardinge]

On 06/27/2011 09:19 PM, James wrote:
> On Fri, Jun 24, 2011 at 03:43:18PM -0700, Jeremy Fitzhardinge wrote:
>> On 06/24/2011 03:15 PM, Jean Guyader wrote:
>>> I only tested it gcc 4.4.
>>>
>>> We could still use the v2 which is not as nice, but it doesn't try to
>>> load eax twice. Let me know which one you will feel better about.
> Given "that loading r0 twice" is in the gcc documentation as an
> example at
>
> http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#index-extended-_0040code_007basm_007d-2601
>
> I think it's fair to use that.
>
>> I feel best about the one you've successfully tested with a number of
>> older compilers ;)
> what compilers work to build modern linux? We'll give a goodly set of them
> a try if that makes everyone feel better.

HPA says:
> For x86, we support 3.4, 4.0 and 4.1.2 and above (not sure if 4.0.x
> actually works).



>> Does it have to?  Couldn't it take a pointer to a struct or something?
> Yes we could change the API, make sure the struct is visible on all
> CPUs, making it incompatible with the existing code, but I think that
> misses the point: Xen is written to support 6 argument hypercalls, but
> 32 bit dom0 is missing the functionality to call them. Surely that's 
> something we should fix?

The nominal ability of 6 arg hypercalls is moot if there aren't actually
any hypercalls which have 6 args.  The fact that 6 args uses ebp on
32-bit is incredibly awkward, and it seems better to just say that it in
fact only supports 5, and adjust the v4v call(s) accordingly.

    J

Re: Re: [PATCH] Linux: 6 arguments hypercall v3

[Ian Campbell]

On Mon, 2011-06-27 at 21:19 +0100, James wrote:
> On Fri, Jun 24, 2011 at 03:43:18PM -0700, Jeremy Fitzhardinge wrote:
> > Does it have to?  Couldn't it take a pointer to a struct or something?
> 
> Yes we could change the API, make sure the struct is visible on all
> CPUs,

FWIW the struct only needs to be visible on the CPU actually making the
hypercall. Many (most?) Xen hypercalls take a pointer to an argument
structure in this way.

Ian.

Re: [PATCH] Linux: 6 arguments hypercall v3 / V4V

[Pasi Kärkkäinen]

On Sun, Jul 03, 2011 at 12:16:01PM +0100, Ian Campbell wrote:
> On Mon, 2011-06-27 at 21:19 +0100, James wrote:
> > On Fri, Jun 24, 2011 at 03:43:18PM -0700, Jeremy Fitzhardinge wrote:
> > > Does it have to?  Couldn't it take a pointer to a struct or something?
> > 
> > Yes we could change the API, make sure the struct is visible on all
> > CPUs,
> 
> FWIW the struct only needs to be visible on the CPU actually making the
> hypercall. Many (most?) Xen hypercalls take a pointer to an argument
> structure in this way.
> 

.. what was the end result of this? 

I'm wondering if V4V will be upstreamed, or if the new libvchan can replace V4V?
I assume XenClient is still using V4V ..

-- Pasi