This patch is some preliminary work for assigning a special RID for use
with EFI mappings. It just creates some macros that will switch the RID if
XEN is defined. A subsequent patch makes use of these macros.
The basic idea of this approach is to switch to this RID, which is in the
range reserved for the hypervisor, before making EFI, PAL or SAL calls. The
page fault handler where the identity mapping checks for this RID, if
present it does the identity mapping, else it just follows the normal
mapping rules. In this way, VMX domains should not be able to access this
memory, and they should be able to use the virtual addresses that are used
by EFI for their own purposes.
Cc: Tristan Gingold <tgingold@xxxxxxx>
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
Index: xen-unstable.hg/xen/include/asm-ia64/linux-xen/linux/efi.h
===================================================================
--- xen-unstable.hg.orig/xen/include/asm-ia64/linux-xen/linux/efi.h
2007-10-23 16:20:06.000000000 +0900
+++ xen-unstable.hg/xen/include/asm-ia64/linux-xen/linux/efi.h 2007-10-23
16:33:41.000000000 +0900
@@ -1,6 +1,8 @@
#ifndef _LINUX_EFI_H
#define _LINUX_EFI_H
+#ifndef __ASSEMBLY__
+
/*
* Extensible Firmware Interface
* Based on 'Extensible Firmware Interface Specification' version 0.9, April
30, 1999
@@ -419,4 +421,95 @@ struct efi_generic_dev_path {
u16 length;
} __attribute ((packed));
+#ifdef XEN
+/*
+ * According to xen/arch/ia64/xen/regionreg.c the RID space is broken
+ * up into chunks, one per domain, and 0th block is for Xen. The 0th block
+ * is broken up into small blocks, which are used for metaphisical mappins,
+ * except for the 0th small block which is used by Xen.
+ *
+ * By default each large block is 18 bits wide. And each small block is
+ * 1/64 the width of a large block, or in other words, 12 bits wide. These
+ * default values are the ones that end up being used on an HP RX2620 box.
+ *
+ * What isn't obvious to me is how the 0th small block is divided up.
+ * While xen/arch/ia64/xen/regionreg.c seems to handle allocating RIDs for
+ * domains, they hypervisor's RIDs seem to be handled in a bit more of an
+ * ad-hoc fashion.
+ *
+ * In xen/include/asm-ia64/mmu_context.h there is IA64_REGION_ID_KERNEL.
+ * This is used to form an RID in the follwing way:
+ *
+ * a: bit 0: VHPT
+ * b: bit 1: reserved (0)
+ * c: bits 2-7: log 2 page_size
+ * d: bits 8-10: Region (0-7, corresponding to the 8 region registers)
+ * e: bits 10-N: IA64_REGION_ID_KERNEL (0)
+ * f: bits N-53: reserved (0)
+ *
+ * N is defined by the platform. Areas c and d above form the RID, it just
+ * happens to be further divided in two due to the way that its value is
+ * calculated buy the code. This subdivision does not reflect any hardware
+ * limitation. The hardware sets the limit of the with of this area to
+ * between 17 and 24 bits. I I believe that on Itanium it is 17 and on
+ * Itanium2 it is 24 and an HP RX2620 box seems to have 24 bits. This means
+ * that N should always between 25 (8+17) and 32 (8+24).
+ *
+ * As we are only using the first 4 bits (3 bits in area d and 1 bit in
+ * area e) of RID space, and our small-block should have 12 bits, this
+ * should be fine - which is nice because these are the IDs that
+ * the hypervisor is using, as set in _start().
+ *
+ * I couldn't find a place where the hypervisor gave itself additional RIDs
+ * to play with that weren't realated to a domain, so I just took the next
+ * slot by defining IA64_REGION_ID_EFI=1, so we can use the following RIDs.
+ *
+ * a: bit 0: VHPT (1)
+ * b: bit 1: reserved (0)
+ * c: bits 2-7: log 2 page_size
+ * d: bits 8-10: Region (0-7, corresponding to the 8 region registers) +
+ * e: bits 10-N: IA64_REGION_ID_KERNEL (1)
+ * f: bits N-53: reserved (0)
+ *
+ * + Only 0 is used as we only need one RID. Its not really important
+ * what this number is, so long as its between 0 and 7.
+ *
+ * The nice thing about this is that we are still only using 4 bits of RID
+ * space, so it shouldn't have any chance of running into an adjacent
+ * small-block.
+ *
+ * However, I am not entirely convinced that this avoids an RID collision.
+ * Mostly because I'm not entirely convinced that other RIDs aren't being
+ * used. If so, then I guess there is an allocation mechanism that I
+ * haven't managed to find yet.
+ */
+
+#define XEN_EFI_RR_SAVE(rr6, rr7) do { \
+ rr6 = ia64_get_rr(6); \
+ rr7 = ia64_get_rr(7); \
+ ia64_set_rr(6, XEN_EFI_RID); \
+ ia64_set_rr(7, XEN_EFI_RID); \
+ ia64_srlz_d(); \
+} while (0)
+
+#define XEN_EFI_RR_RESTORE(rr6, rr7) do { \
+ ia64_set_rr(6, rr6); \
+ ia64_set_rr(7, rr7); \
+ ia64_srlz_d(); \
+} while (0)
+
+#else
+#define XEN_EFI_RR_SAVE() do {} while (0)
+#define XEN_EFI_RR_RESTORE() do {} while (0)
+#endif /* XEN */
+
+#endif /* !__ASSEMBLY__ */
+
+#ifdef XEN
+#include <asm/mmu_context.h> /* For IA64_REGION_ID_EFI and ia64_rid() */
+#include <asm/pgtable.h> /* IA64_GRANULE_SHIFT */
+#define XEN_EFI_RID ((ia64_rid(XEN_IA64_REGION_ID_EFI, 0) << 8) | \
+ (IA64_GRANULE_SHIFT << 2) | 1)
+#endif /* XEN */
+
#endif /* _LINUX_EFI_H */
Index: xen-unstable.hg/xen/include/asm-ia64/mmu_context.h
===================================================================
--- xen-unstable.hg.orig/xen/include/asm-ia64/mmu_context.h 2007-10-23
16:20:06.000000000 +0900
+++ xen-unstable.hg/xen/include/asm-ia64/mmu_context.h 2007-10-23
16:23:01.000000000 +0900
@@ -3,6 +3,7 @@
//dummy file to resolve non-arch-indep include
#ifdef XEN
#define IA64_REGION_ID_KERNEL 0
+#define XEN_IA64_REGION_ID_EFI 1
#define ia64_rid(ctx,addr) (((ctx) << 3) | (addr >> 61))
#ifndef __ASSEMBLY__
--
--
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