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/
Home Products Support Community News


[Xen-changelog] [xen-unstable] [IA64] kexec: Map EFI regions into the sa

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-unstable] [IA64] kexec: Map EFI regions into the same place they are maped into in Linux
From: Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 11 Aug 2008 05:50:35 -0700
Delivery-date: Mon, 11 Aug 2008 05:51:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
# Date 1216696502 -32400
# Node ID 2fd648307ad1f00a43914203656596bfc26382a8
# Parent  7da7b53b21397951103fe04bd27ce158b6919c8e
[IA64] kexec: Map EFI regions into the same place they are maped into in Linux

Map EFI regions into the same place they are maped into in Linux

This is because of an unfortunate problem with the way that EFI interacts
with Kexec. The call to map the EFI regions may only be made once. This
means that after Kexec the EFI regions must be mapped into the same region
that they were mapped into prior to Kexec.

This is not usually a problem when kexecing from xen to xen or from linux
to linux, as the mapping will be the same. However when kexecing from xen
to linux or linux to xen, the mapping is different, and the problem

So far Magnus Damm and I have come up with three different ideas for
resolving this problem.

1. Leave the EFI in physical mode
   - This is nice and simple
   - There is a potential performance hit, but PAL calls are not
     made very often, so it shouldn't be a problem
   - I have patches to do this, some of which are in the
     series that accompany this patch.
   - The SGI people tell me that it won't work on SN because
     it allows the OS to provide EFI (or SAL?) code.

2. Always map EFI into the space that Linux uses
   - Not so simple
   - Requires Xen to jump through some hoops
   - But leaves Linux unmodified
   - But it will break if Linux ever changes its mapping
   - This patch series implements this change

3. Always map EFI to some agreed space
   - Similar to 2. but less likely to break in the future
   - But it requires Xen and Linux to agree on a space to be used
   - Reqires both Xen and Linux to be modified

Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Cc: Tristan Gingold <tgingold@xxxxxxx>
Cc: Alex Williamson <alex.williamson@xxxxxx>
Cc: Aron Griffis <aron@xxxxxx>
Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
 xen/arch/ia64/linux-xen/efi.c  |   12 ++++++++++++
 xen/include/asm-ia64/xenpage.h |    7 -------
 2 files changed, 12 insertions(+), 7 deletions(-)

diff -r 7da7b53b2139 -r 2fd648307ad1 xen/arch/ia64/linux-xen/efi.c
--- a/xen/arch/ia64/linux-xen/efi.c     Tue Jul 22 12:15:02 2008 +0900
+++ b/xen/arch/ia64/linux-xen/efi.c     Tue Jul 22 12:15:02 2008 +0900
@@ -641,6 +641,17 @@ efi_enter_virtual_mode (void)
        for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
                md = p;
+#ifdef XEN
+               if (md->attribute & EFI_MEMORY_RUNTIME) {
+                       if (md->attribute & EFI_MEMORY_WB)
+                               md->virt_addr = __IA64_EFI_CACHED_OFFSET|
+                                               md->phys_addr;
+                       else if (md->attribute & (EFI_MEMORY_UC|EFI_MEMORY_WC|
+                                                 EFI_MEMORY_WT))
+                               md->virt_addr = __IA64_EFI_UNCACHED_OFFSET|
+                                               md->phys_addr;
+               }
                if (md->attribute & EFI_MEMORY_RUNTIME) {
                         * Some descriptors have multiple bits set, so the 
order of
@@ -673,6 +684,7 @@ efi_enter_virtual_mode (void)
        status = efi_call_phys(__va(runtime->set_virtual_address_map),
diff -r 7da7b53b2139 -r 2fd648307ad1 xen/include/asm-ia64/xenpage.h
--- a/xen/include/asm-ia64/xenpage.h    Tue Jul 22 12:15:02 2008 +0900
+++ b/xen/include/asm-ia64/xenpage.h    Tue Jul 22 12:15:02 2008 +0900
@@ -97,14 +97,7 @@ static inline u64 pa_clear_uc(u64 paddr)
 /* It is sometimes very useful to have unsigned long as result.  */
 #define __va_ul(x)     ({xen_va _v; _v.l = (long) (x); _v.f.reg = -1; _v.l;})
-/* __va_efi() should just call __va() until the use of
- * __IA64_EFI_CACHED_OFFSET is activated in efi_enter_virtual_mode()
- */
-#if 0
 #define __va_efi(x)    ((void*)((unsigned long)(x) | __IA64_EFI_CACHED_OFFSET))
-#define __va_efi(x)    __va(x)
 #endif /* _ASM_IA64_XENPAGE_H */

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-unstable] [IA64] kexec: Map EFI regions into the same place they are maped into in Linux, Xen patchbot-unstable <=