Currently the EFI code will fall back to making real mode calls if the call
to map the EFI code fails. Unfortunately this only takes into account EFI
calls, but if EFI calls are made in physical mode SAL calls also need to be
made in physical mode. On a Tiger2 at least, forcing EFI to stay in
physical mode caues the boot to oops in a SAL call.
This patch changes things around by adding code to allow SAL calls to be
made in physical mode. I then makes this the path that is allways followed
- that is SAL calls are always physical with this patch.
This patch fixes things up so that physical SAL calls are made when
physical EFI calls are in operation, and virtual SAL calls when virtual EFI
calls are in poration.
Curiously on my Tiger2, it seems that having SAL always physical, regadless
of if EFI is physical or virtual, actually works.
Signed-Off-By: Simon Horman <horms@xxxxxxxxxxxx>
Index: xen-ia64-unstable-14854/xen/arch/ia64/linux-xen/sal.c
===================================================================
--- xen-ia64-unstable-14854.orig/xen/arch/ia64/linux-xen/sal.c 2007-04-17
11:00:55.000000000 +0900
+++ xen-ia64-unstable-14854/xen/arch/ia64/linux-xen/sal.c 2007-04-17
11:44:03.000000000 +0900
@@ -384,3 +384,30 @@ ia64_sal_oemcall_reentrant(struct ia64_s
return 0;
}
EXPORT_SYMBOL(ia64_sal_oemcall_reentrant);
+
+#ifdef XEN
+
+/* In practice this seems to be needed for at least SAL_GET_STATE_INFO
+ * Tested on a Tiger 2 box */
+struct ia64_sal_retval sal_call_phys(ia64_sal_handler ia64_sal,
+ unsigned long a0, unsigned long a1,
+ unsigned long a2, unsigned long a3,
+ unsigned long a4, unsigned long a5,
+ unsigned long a6, unsigned long a7)
+{
+ switch (a0) {
+ case SAL_GET_STATE_INFO:
+ a3 = __pa(a3);
+ break;
+ case SAL_MC_SET_PARAMS:
+ if (a2 == 0x2) /* It is a memory address */
+ a3 = __pa(a3);
+ break;
+ case SAL_UPDATE_PAL:
+ a1 = __pa(a1);
+ a2 = __pa(a2);
+ break;
+ }
+ return __sal_call_phys(ia64_sal, a0, a1, a2, a3, a4, a5, a6, a7);
+}
+#endif
Index: xen-ia64-unstable-14854/xen/arch/ia64/linux-xen/sal_stub.S
===================================================================
--- xen-ia64-unstable-14854.orig/xen/arch/ia64/linux-xen/sal_stub.S
2007-04-17 11:44:03.000000000 +0900
+++ xen-ia64-unstable-14854/xen/arch/ia64/linux-xen/sal_stub.S 2007-04-17
11:44:03.000000000 +0900
@@ -42,7 +42,7 @@
* r8..r11 = return
*/
-GLOBAL_ENTRY(sal_call_phys)
+GLOBAL_ENTRY(__sal_call_phys)
.prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(9)
alloc loc1=ar.pfs,9,8,8,0
ld8 r2=[in0],8 // load SAL function's entry point
Index: xen-ia64-unstable-14854/xen/include/asm-ia64/linux/asm/sal.h
===================================================================
--- xen-ia64-unstable-14854.orig/xen/include/asm-ia64/linux/asm/sal.h
2007-04-17 11:44:03.000000000 +0900
+++ xen-ia64-unstable-14854/xen/include/asm-ia64/linux/asm/sal.h
2007-04-17 11:44:03.000000000 +0900
@@ -62,16 +62,27 @@ struct ia64_sal_retval {
typedef struct ia64_sal_retval (*ia64_sal_handler) (u64, ...);
/* SAL spec _requires_ eight args for each call. */
+#ifndef XEN
struct ia64_sal_retval sal_call_phys(ia64_sal_handler ia64_sal, ...);
-#ifdef XEN
+#define __SAL_CALL(result,a0,a1,a2,a3,a4,a5,a6,a7) \
+ result = (*ia64_sal)(ia64_sal,a0,a1,a2,a3,a4,a5,a6,a7);
+#else
+struct ia64_sal_retval sal_call_phys(ia64_sal_handler ia64_sal,
+ unsigned long a0, unsigned long a1,
+ unsigned long a2, unsigned long a3,
+ unsigned long a4, unsigned long a5,
+ unsigned long a6, unsigned long a7);
+struct ia64_sal_retval __sal_call_phys(ia64_sal_handler ia64_sal,
+ unsigned long a0, unsigned long a1,
+ unsigned long a2, unsigned long a3,
+ unsigned long a4, unsigned long a5,
+ unsigned long a6, unsigned long a7);
+
#define __SAL_CALL(result,a0,a1,a2,a3,a4,a5,a6,a7) \
result = efi.mapped ? \
(*ia64_sal)(a0,a1,a2,a3,a4,a5,a6,a7) : \
sal_call_phys(ia64_sal,a0,a1,a2,a3,a4,a5,a6,a7);
-#else
-#define __SAL_CALL(result,a0,a1,a2,a3,a4,a5,a6,a7) \
- result = (*ia64_sal)(ia64_sal,a0,a1,a2,a3,a4,a5,a6,a7);
#endif
# define SAL_CALL(result,args...) do { \
--
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home