This is used by paches that move the EFI runtime regions into what is normally guest space. A description of why this mapping is made is included in the patch that makes the mapping.
Cc: Tristan Gingold <[EMAIL PROTECTED]> Cc: Isaku Yamahata <[EMAIL PROTECTED]> Cc: Alex Williamson <[EMAIL PROTECTED]> Cc: Aron Griffis <[EMAIL PROTECTED]> Signed-off-by: Simon Horman <[EMAIL PROTECTED]> --- Sat, 8 Sep 2007 06:06:30 +0200 Tristan Gingold has rasied the point that mapping EFI memory as facilitated by this and subsequent patches may cause a security problem, allowing VTI domains to access memory that they shouldn't. This needs further analysis. Index: xen-unstable.hg/xen/include/asm-ia64/xensystem.h =================================================================== --- xen-unstable.hg.orig/xen/include/asm-ia64/xensystem.h 2008-02-05 16:18:40.000000000 +0900 +++ xen-unstable.hg/xen/include/asm-ia64/xensystem.h 2008-02-05 16:18:58.000000000 +0900 @@ -33,6 +33,12 @@ #define KERNEL_START 0xf400000004000000 #define GATE_ADDR KERNEL_START +/* In order for Kexec between Xen and Linux to work EFI needs + * to be mapped into the same place by both. It seems most convenient + * to make Xen do the dirty work here */ +#define __IA64_EFI_UNCACHED_OFFSET 0xc000000000000000UL +#define __IA64_EFI_CACHED_OFFSET 0xe000000000000000UL + #define IS_VMM_ADDRESS(addr) ((((addr) >> 60) ^ ((addr) >> 59)) & 1) #endif // _ASM_IA64_XENSYSTEM_H -- -- Horms _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel