WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

[Xen-ia64-devel] [patch 05/11] ia64: kexec: Define macros for EFI RID

To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-ia64-devel] [patch 05/11] ia64: kexec: Define macros for EFI RID
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Thu, 20 Mar 2008 15:52:53 +0900
Cc: Aron Griffis <aron@xxxxxx>, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>
Delivery-date: Thu, 20 Mar 2008 00:13:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080320065248.456511629@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: quilt/0.46-1
Macros to be called by PAL, SAL and EFI to switch into
and out of EFI RID.

Cc: Tristan Gingold <tgingold@xxxxxxx>
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Cc: Alex Williamson <alex.williamson@xxxxxx>
Cc: Aron Griffis <aron@xxxxxx>
Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>

--- 

Thu, 22 Nov 2007 00:20:54 -0700
* Add XEN_EFI_RR_DECLARE to help consistent declarations
* Fix up vairous compile errors in the !XEN case
* Pass unsigned long as the second argement to to ia64_rid
  to ensure that it is wide enough

Mon, 03 Dec 2007 17:29:04 +0900
* Shift VRN 61 bits to the left when calling ia64_get_rr() and
  ia64_set_rr()


Thu, 24 Jan 2008 12:15:55 +0900
* Use set_one_rr_efi() instead of set_rr() so
  that TR (TLB) entries are repined as neccessary.
* Do not enable VHPT in EFI RID.
  - There seems to be no good reason to enable it,
    and the current code dies if it is enabled.
    Perhaps the VHPT TR would need to be repined?

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     
2008-02-05 16:18:41.000000000 +0900
+++ xen-unstable.hg/xen/include/asm-ia64/linux-xen/linux/efi.h  2008-02-05 
16:18:52.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,104 @@ 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, which is also the minimum
+ * width. Each small block is by default 1/64 the width of a large block,
+ * which is also the maximum devision. In other words each small block is
+ * at least 12 bits wide.
+ *
+ * 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 18 and 24 bits.
+ *
+ * As we are only using the first 4 bits (3 bits in area d and 1 bit in
+ * area e) of RID space it easily fits inside the 0th small block, which
+ * is 12 bits wide.
+ *
+ * For EFI we use the following RID
+ *
+ * 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.
+ *
+ * It would actually be possible to just use a IA64_REGION_ID_KERNEL
+ * based RID for EFI use. The important thing is that it is in the 0th
+ * small block, and that not available to domains. But as we have
+ * lots of space, its seems to be nice and clean to just use a separate
+ * RID for EFI.
+ *
+ * This can be trivially changed by updating the definition of XEN_EFI_RID.
+ */
+
+#define XEN_EFI_RR_SAVE(rr6, rr7) do {                 \
+       rr6 = ia64_get_rr(6UL << 61);                   \
+       rr7 = ia64_get_rr(7UL << 61);                   \
+       set_one_rr_efi(6UL << 61, XEN_EFI_RID);         \
+       set_one_rr_efi(7UL << 61, XEN_EFI_RID);         \
+       ia64_srlz_d();                                  \
+} while (0)
+
+#define XEN_EFI_RR_RESTORE(rr6, rr7) do {              \
+       set_one_rr_efi(6UL << 61, rr6);                 \
+       set_one_rr_efi(7UL << 61, rr7);                 \
+       ia64_srlz_d();                                  \
+} while (0)
+
+#else
+/* Just use rr6 and rr7 in a dummy fashion here to get
+ * rid of compiler warnings - a better solution should
+ * be found if this code is ever actually used */
+#define XEN_EFI_RR_SAVE(rr6, rr7)       do { rr6 = 0; rr7 = 0; } while (0)
+#define XEN_EFI_RR_RESTORE(rr6, rr7)    do {} while (0)
+#endif /* XEN */
+
+#define XEN_EFI_RR_DECLARE(rr6, rr7)   unsigned long rr6, rr7;
+
+#endif /* !__ASSEMBLY__ */
+
+#ifdef XEN
+#include <asm/mmu_context.h> /* For IA64_REGION_ID_EFI and ia64_rid() */
+#include <asm/pgtable.h>     /* IA64_GRANULE_SHIFT */
+#ifdef __ASSEMBLY__
+#define XEN_EFI_RID_NO 0
+#else
+#define XEN_EFI_RID_NO 0UL
+#endif
+#define XEN_EFI_RID ((ia64_rid(XEN_IA64_REGION_ID_EFI, XEN_EFI_RID_NO) << 8) |\
+                    (IA64_GRANULE_SHIFT << 2))
+#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     2008-02-05 
16:18:41.000000000 +0900
+++ xen-unstable.hg/xen/include/asm-ia64/mmu_context.h  2008-02-05 
16:18:52.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


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