[Xen-ia64-devel] [patch 03/11] ia64: kexec: Header changes in preparation for EFI RID
The EFI RID patches require pal.h to (directly or indirectly) have access to GRANULE_SIZE which is defined in pgtable.h. This effectively causes a header loop as pgtable.h includes system.h and system.h includes pal.h. This patch breaks that loop by not including pal.h in system.h if XEN is defined, which is the only time the loop will occur. There are two side effects of this: 1. regionreg.c makes use of some symbols declared in pal.h but does not include it directly. This is resolved by including it, which doesn't seem to cause any additional problems. 2. system.h makes use of ia64_pal_halt_light which is defined in pal.h. #define safe_halt() ia64_pal_halt_light() This is probably the reason that pal.h is included in system.h. However this does not seem to manifest as any sort of build problem, presumably because either nothing in xen uses safe_halt, or because those that do include pal.h by some other means. In any case the change seems safe, though hackish. 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] Index: xen-unstable.hg/xen/arch/ia64/xen/regionreg.c === --- xen-unstable.hg.orig/xen/arch/ia64/xen/regionreg.c 2008-02-05 16:18:51.0 +0900 +++ xen-unstable.hg/xen/arch/ia64/xen/regionreg.c 2008-02-05 16:18:51.0 +0900 @@ -16,6 +16,7 @@ #include asm/vhpt.h #include asm/vcpu.h #include asm/percpu.h +#include asm/pal.h /* Defined in xemasm.S */ extern void ia64_new_rr7(unsigned long rid, void *shared_info, void *shared_arch_info, unsigned long shared_info_va, unsigned long va_vhpt); Index: xen-unstable.hg/xen/include/asm-ia64/linux-xen/asm/system.h === --- xen-unstable.hg.orig/xen/include/asm-ia64/linux-xen/asm/system.h 2008-02-05 16:18:41.0 +0900 +++ xen-unstable.hg/xen/include/asm-ia64/linux-xen/asm/system.h 2008-02-05 16:18:51.0 +0900 @@ -16,7 +16,9 @@ #include asm/kregs.h #include asm/page.h +#ifndef XEN #include asm/pal.h +#endif #include asm/percpu.h #ifndef XEN -- -- Horms ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch 00/11] ia64: kexec: Map EFI memory in the same location as Linux (v20080320)
Hi, here is another spin of the kexec EFI patches. I think we are getting very close if we aren't there already. Standard Intro: This series is what I believe to be a fairly complete set of patches to map EFI memory into the same location that Linux does. The memory is protected by an RID so that it doesn't conflict with domain memory - which also protects it from malicious access from HVM domains. The primary motivation for this is that EFI memory can only be mapped once - a restriction in the EFI specification. Thus for kexec betwen Xen and Linux, including kdump of Xen (into Linux), EFI memory needs to be mapped in the same location in both Xen and Linux. The first goal of these patches it to create a kexec enabled xen ia64 without regressions. The second is to create a working kexec for ia64. I believe that this series is very close to reaching the first goal, and driver issues aside (more below), also very close to reaching the second goal. I have tested these patches on a Tiger 4, Tiger 2, RX rx2620 and HP rx3600. Thanks to Alex Williamson and HP for making the latter available to me. Thanks to Fujitsu for supplying most of the other machines. I recommend testing these patches using: Xen http://xenbits.xensource.com/ext/ia64/xen-unstbale.hg Revision: 17209:8c921adf4833 Linux-Xen http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg Revision: 471:ba72914de93a Kexec-Tools git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git Revision: 94afdd9f7ab2b07997f80a297741842f9cdbdc25 Linux Revision: 2.6.25-rc3 Notable changes since the last time this series was posted: * Omit patch (formerly 13/15) ia64: kexec: Set page size identity mapping of EFI in alt_itlb_miss This patch causes problems on machines that it is supposed to fix problems on - obviously I made a mistake when collating fixes. * Omit the following patches, as they don't seem to be used, although they don't seem to cause much harm either. ia64: kexec: Add identity mapping of EFI memory to dtlb_miss (formerly 09/15) ia64: kexec: identity mapping of EFI memory to itlb_miss (formerly 10/15) ia64: kexec: Set protection key of identity mapping of EFI in alt_dtlb_miss (formerly 11/15) ia64: kexec: Set protection key of identity mapping of EFI in alt_itlb_miss (formerly 12/15) * Add ia64: kexec: add __va_efi Known problem: The hypervisor boots on all machines mentioned above using these patches. In addition, Alex Williamson has tested a patch set very similar to this one and found it to work on a variety of HP hardware. As for successfully kexecing, I have tested Xen-Xen transitions successfully on the machines mentioned above, with the following caveat. The HP rc3600 has an Intel e100 network card. I have found that kexec hangs at the following position when the eepro100 (original Donald Becker) driver is used. This hang does not occur when either no driver is supplied or the Intel e100 driver is used. Brought up 1 CPUs Total of 1 processors activated (2247.88 BogoMIPS). migration_cost=0 (XEN) mm.c:575:d0 Warning: UC to WB for mpaddr=3fb3a010 DMI 2.3 present. NET: Registered protocol family 16 ACPI: bus type pci registered (XEN) mm.c:575:d0 Warning: UC to WB for mpaddr=3fb2e000 ACPI: Interpreter enabled ACPI: Using IOSAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) I will investigate this problem further, but I do not view it as blocking this patch set as it does not effect the initial boot, only kexec boots, which don't work at all without this patch set. In any case, it is the nature of kexec that driver-specific problems occur, and these can be sensibly weeded out over time as they are observed. -- Horms - on a rainy holiday Thursday ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch 01/11] ia64: kexec: Unpin the correct VHPT TR in ia64_do_tlb_purge
When ia64_do_tlb_purge is called indrectly from play_dead()
GET_VA_VCPU_VHPT_MADDR(r2,r3) does not give the value of the VHPT
pinned into the TLB. I believe that this is because
current is changed between pinning and calling play_dead,
though I am not sure of the exact scemantics.
In any case, by recording the pinned value in a percpu variable,
and unpinning this value, the TR entry is removed and all is well.
Cc: Isaku Yamahata [EMAIL PROTECTED]
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Index: xen-unstable.hg/xen/arch/ia64/linux-xen/mca_asm.S
===
--- xen-unstable.hg.orig/xen/arch/ia64/linux-xen/mca_asm.S 2008-02-05
16:18:42.0 +0900
+++ xen-unstable.hg/xen/arch/ia64/linux-xen/mca_asm.S 2008-02-05
16:18:50.0 +0900
@@ -322,7 +322,9 @@ ia64_do_tlb_purge:
#ifdef XEN
// 5. VHPT
#if VHPT_ENABLED
- GET_VA_VCPU_VHPT_MADDR(r2,r3);;
+ // GET_VA_VCPU_VHPT_MADDR() may not give the
+ // value of the VHPT currently pinned into the TLB
+ GET_THIS_PADDR(r2, inserted_vhpt);;
dep r16=0,r2,0,IA64_GRANULE_SHIFT
mov r18=IA64_GRANULE_SHIFT2
;;
Index: xen-unstable.hg/xen/arch/ia64/xen/regionreg.c
===
--- xen-unstable.hg.orig/xen/arch/ia64/xen/regionreg.c 2008-02-05
16:18:42.0 +0900
+++ xen-unstable.hg/xen/arch/ia64/xen/regionreg.c 2008-02-05
16:18:50.0 +0900
@@ -15,6 +15,7 @@
#include asm/regionreg.h
#include asm/vhpt.h
#include asm/vcpu.h
+#include asm/percpu.h
/* Defined in xemasm.S */
extern void ia64_new_rr7(unsigned long rid, void *shared_info, void
*shared_arch_info, unsigned long shared_info_va, unsigned long va_vhpt);
@@ -227,6 +228,10 @@ set_rr(unsigned long rr, unsigned long r
ia64_srlz_d();
}
+#if VHPT_ENABLED
+DEFINE_PER_CPU(unsigned long, inserted_vhpt);
+#endif
+
// validates and changes a single region register
// in the currently executing domain
// Passing a value of -1 is a (successful) no-op
@@ -260,6 +265,9 @@ int set_one_rr(unsigned long rr, unsigne
if (!PSCB(v,metaphysical_mode))
set_rr(rr,newrrv.rrval);
} else if (rreg == 7) {
+#if VHPT_ENABLED
+ __get_cpu_var(inserted_vhpt) = __va_ul(vcpu_vhpt_maddr(v));
+#endif
ia64_new_rr7(vmMangleRID(newrrv.rrval),v-domain-shared_info,
v-arch.privregs, v-domain-arch.shared_info_va,
__va_ul(vcpu_vhpt_maddr(v)));
--
--
Horms
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch 02/11] ia64: kexec: Unpin shared_info and mapped_regs TR in ia64_do_tlb_purge
Unpinning shared_info and mapped_regs seems to be missing from ia64_do_tlb_purge and seems to be needed for kexec. Like VHPT, the pinned value is recored in a percpu variable so that the correct value can be unpinned. Cc: Isaku Yamahata [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL PROTECTED] Index: xen-unstable.hg/xen/arch/ia64/linux-xen/mca_asm.S === --- xen-unstable.hg.orig/xen/arch/ia64/linux-xen/mca_asm.S 2008-02-05 16:18:50.0 +0900 +++ xen-unstable.hg/xen/arch/ia64/linux-xen/mca_asm.S 2008-02-05 16:18:51.0 +0900 @@ -26,6 +26,7 @@ #include asm/mca.h #ifdef XEN #include asm/vhpt.h +#include public/arch-ia64.h #endif /* @@ -320,7 +321,30 @@ ia64_do_tlb_purge: srlz.i ;; #ifdef XEN - // 5. VHPT + // 5. shared_info + // v-domain-arch.shared_info_va may not be the + // value of shared_info currently pinned into the TLB + GET_THIS_PADDR(r2, inserted_shared_info);; + ld8 r16=[r2] + mov r18=XSI_SHIFT2 + ;; + ptr.d r16,r18 + ;; + srlz.d + ;; + + // 6. mapped_regs + mov r2=XMAPPEDREGS_OFS + mov r18=XMAPPEDREGS_SHIFT2 + ;; + add r16=r16,r2 + ;; + ptr.d r16,r18 + ;; + srlz.d + ;; + + // 7. VHPT #if VHPT_ENABLED // GET_VA_VCPU_VHPT_MADDR() may not give the // value of the VHPT currently pinned into the TLB Index: xen-unstable.hg/xen/arch/ia64/xen/regionreg.c === --- xen-unstable.hg.orig/xen/arch/ia64/xen/regionreg.c 2008-02-05 16:18:50.0 +0900 +++ xen-unstable.hg/xen/arch/ia64/xen/regionreg.c 2008-02-05 16:18:51.0 +0900 @@ -231,6 +231,7 @@ set_rr(unsigned long rr, unsigned long r #if VHPT_ENABLED DEFINE_PER_CPU(unsigned long, inserted_vhpt); #endif +DEFINE_PER_CPU(unsigned long, inserted_shared_info); // validates and changes a single region register // in the currently executing domain @@ -268,6 +269,8 @@ int set_one_rr(unsigned long rr, unsigne #if VHPT_ENABLED __get_cpu_var(inserted_vhpt) = __va_ul(vcpu_vhpt_maddr(v)); #endif + __get_cpu_var(inserted_shared_info) = + v-domain-arch.shared_info_va; ia64_new_rr7(vmMangleRID(newrrv.rrval),v-domain-shared_info, v-arch.privregs, v-domain-arch.shared_info_va, __va_ul(vcpu_vhpt_maddr(v))); -- -- Horms ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch 04/11] ia64: kexec: Repining for EFI RID
A cut down version of set_one_rr (and ia64_new_rr7) for
use when switching to the EFI RID for SAL, PAL and EFI calls.
It seemeeems to be no need to repin: palcode, mapped_regs or vhpt in this
case. If it turns they do need to be repinned then special care needs to
betaken to track the correct value to repin. That is generally the values
that were most recently pinned by ia64_new_rr7.
ia64_new_rr7_efi can probably be merged with ia64_new_rr7,
as they are quite similar, but for testing purposes it seems
easier to keep them separate.
Cc: Isaku Yamahata [EMAIL PROTECTED]
Cc: Alex Williamson [EMAIL PROTECTED]
Cc: Aron Griffis [EMAIL PROTECTED]
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Index: xen-unstable.hg/xen/arch/ia64/xen/regionreg.c
===
--- xen-unstable.hg.orig/xen/arch/ia64/xen/regionreg.c 2008-02-06
15:47:43.0 +0900
+++ xen-unstable.hg/xen/arch/ia64/xen/regionreg.c 2008-02-06
15:47:43.0 +0900
@@ -11,6 +11,7 @@
#include linux/config.h
#include linux/types.h
#include linux/sched.h
+#include linux/percpu.h
#include asm/page.h
#include asm/regionreg.h
#include asm/vhpt.h
@@ -20,6 +21,7 @@
/* Defined in xemasm.S */
extern void ia64_new_rr7(unsigned long rid, void *shared_info, void
*shared_arch_info, unsigned long shared_info_va, unsigned long va_vhpt);
+extern void ia64_new_rr7_efi(unsigned long rid, unsigned long percpu_pte);
/* RID virtualization mechanism is really simple: domains have less rid bits
than the host and the host rid space is shared among the domains. (Values
@@ -281,6 +283,21 @@ int set_one_rr(unsigned long rr, unsigne
return 1;
}
+int set_one_rr_efi(unsigned long rr, unsigned long val)
+{
+ unsigned long rreg = REGION_NUMBER(rr);
+
+ BUG_ON(rreg != 6 rreg != 7);
+
+ if (rreg == 6)
+ set_rr(rr, val);
+ else
+ ia64_new_rr7_efi(val, cpu_isset(smp_processor_id(),
+ percpu_set));
+
+ return 1;
+}
+
void set_virtual_rr0(void)
{
struct vcpu *v = current;
Index: xen-unstable.hg/xen/arch/ia64/xen/xenasm.S
===
--- xen-unstable.hg.orig/xen/arch/ia64/xen/xenasm.S 2008-02-06
15:22:21.0 +0900
+++ xen-unstable.hg/xen/arch/ia64/xen/xenasm.S 2008-02-06 15:47:43.0
+0900
@@ -195,6 +195,144 @@ GLOBAL_ENTRY(ia64_new_rr7)
br.ret.sptk.many rp
END(ia64_new_rr7)
+
+ /* ia64_new_rr7_efi:
+ * in0 = rid
+ * in1 = repin_percpu
+ *
+ * There seems to be no need to repin: palcode, mapped_regs
+ * or vhpt. If they do need to be repinned then special care
+ * needs to betaken to track the correct value to repin.
+ * That is generally the values that were most recently pinned by
+ * ia64_new_rr7.
+ *
+ * This code function could probably be merged with ia64_new_rr7
+ * as it is just a trimmed down version of that function.
+ * However, current can change without repinning occuring,
+ * so simply getting the values from current does not work correctly.
+ */
+
+GLOBAL_ENTRY(ia64_new_rr7_efi)
+ // FIXME? not sure this unwind statement is correct...
+ .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(1)
+ alloc loc1 = ar.pfs, 2, 6, 0, 0
+ movl loc2=PERCPU_ADDR
+1: {
+ mov loc3 = psr// save psr
+ mov loc0 = rp // save rp
+ mov r8 = ip // save ip to compute branch
+ };;
+ .body
+ tpa loc2=loc2 // grab this BEFORE changing rr7
+ adds r8 = 1f-1b,r8 // calculate return address for call
+ ;;
+ movl r17=PSR_BITS_TO_SET
+ mov loc4=ar.rsc // save RSE configuration
+ movl r16=PSR_BITS_TO_CLEAR
+ ;;
+ tpa r8=r8 // convert rp to physical
+ mov ar.rsc=0// put RSE in enforced lazy, LE mode
+ or loc3=loc3,r17// add in psr the bits to set
+ ;;
+ andcm r16=loc3,r16 // removes bits to clear from psr
+ dep loc5=0,r8,0,KERNEL_TR_PAGE_SHIFT // Xen code paddr
+ br.call.sptk.many rp=ia64_switch_mode_phys
+1:
+ movlr26=PAGE_KERNEL
+ // now in physical mode with psr.i/ic off so do rr7 switch
+ dep r16=-1,r0,61,3
+ ;;
+ mov rr[r16]=in0
+ ;;
+ srlz.d
+ ;;
+
+ // re-pin mappings for kernel text and data
+ mov r24=KERNEL_TR_PAGE_SHIFT2
+ movl r17=KERNEL_START
+ ;;
+ ptr.i r17,r24
+ ;;
+ ptr.d r17,r24
+ ;;
+ srlz.i
+ ;;
+ srlz.d
+ ;;
+ mov r16=IA64_TR_KERNEL
+ mov cr.itir=r24
+ mov cr.ifa=r17
+ or r18=loc5,r26
+ ;;
+ itr.i itr[r16]=r18
+ ;;
+ itr.d dtr[r16]=r18
+ ;;
+ srlz.i
+ ;;
+
[Xen-ia64-devel] [patch 05/11] ia64: kexec: Define macros for EFI RID
Macros to be called by PAL, SAL and EFI to switch into
and out of EFI RID.
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]
---
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.0 +0900
+++ xen-unstable.hg/xen/include/asm-ia64/linux-xen/linux/efi.h 2008-02-05
16:18:52.0 +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
[Xen-ia64-devel] [patch 10/11] ia64: kexec: add __va_efi
sal_desc_entry_point() converts physical addresses into virtual
addresses using __va() and these virtual addresses are used
to register the SAL and PAL handlers - which exist in firmware
memory.
As the mapping of firmware memory is being moved from
a PAGE_OFFSET of (0xf 60) to a PAGE_OFFSET of (0xe 60),
__va() does not provide the correct virtual address.
By adding __va_efi(), which uses EFI_PAGE_OFFSET=(0xe 60),
and using this in sal_desc_entry_point(), the correct address is
used.
On an HP rx2600 this eliminates the problem where the SAL rendezvous address
can't be registered and subsequently the boot fails. I suspect it
solves similar problems that have been seen on other HP machines too.
Actually, its rather amazing that the HP rx2620 and Tiger2 that
I have been using work without this fix.
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Index: xen-unstable.hg/xen/arch/ia64/linux-xen/sal.c
===
--- xen-unstable.hg.orig/xen/arch/ia64/linux-xen/sal.c 2008-03-19
11:52:42.0 +0900
+++ xen-unstable.hg/xen/arch/ia64/linux-xen/sal.c 2008-03-19
11:53:03.0 +0900
@@ -121,8 +121,8 @@ static void __init
sal_desc_entry_point (void *p)
{
struct ia64_sal_desc_entry_point *ep = p;
- ia64_pal_handler_init(__va(ep-pal_proc));
- ia64_sal_handler_init(__va(ep-sal_proc), __va(ep-gp));
+ ia64_pal_handler_init(__va_efi(ep-pal_proc));
+ ia64_sal_handler_init(__va_efi(ep-sal_proc), __va_efi(ep-gp));
}
#ifdef CONFIG_SMP
Index: xen-unstable.hg/xen/include/asm-ia64/xenpage.h
===
--- xen-unstable.hg.orig/xen/include/asm-ia64/xenpage.h 2008-03-19
11:52:42.0 +0900
+++ xen-unstable.hg/xen/include/asm-ia64/xenpage.h 2008-03-19
11:54:41.0 +0900
@@ -97,5 +97,14 @@ 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;})
+/* Do __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)((unsigned long)(x) | __IA64_EFI_CACHED_OFFSET)
+#else
+#define __va_efi(x)__va(x)
+#endif
+
#endif
#endif /* _ASM_IA64_XENPAGE_H */
--
--
Horms
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch 07/11] ia64: kexec: Allow EFI_RID to be used in ivt.S
This is a preliminary patch to allow itentity mapping of EFI memory to be handled in the asm page fault handlers. Cc: Isaku Yamahata [EMAIL PROTECTED] Cc: Tristan Gingold [EMAIL PROTECTED] Cc: Alex Williamson [EMAIL PROTECTED] Cc: Aron Griffis [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL PROTECTED] Index: xen-unstable.hg/xen/arch/ia64/xen/ivt.S === --- xen-unstable.hg.orig/xen/arch/ia64/xen/ivt.S2008-02-05 16:18:41.0 +0900 +++ xen-unstable.hg/xen/arch/ia64/xen/ivt.S 2008-02-05 16:18:54.0 +0900 @@ -57,6 +57,7 @@ #include asm/thread_info.h #include asm/unistd.h #include xen/errno.h +#include linux/efi.h #if 1 # define PSR_DEFAULT_BITS psr.ac -- -- Horms ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch 08/11] ia64: kexec: Add identity mapping of EFI memory to alt_dtlb_miss
Cc: Isaku Yamahata [EMAIL PROTECTED] Cc: Tristan Gingold [EMAIL PROTECTED] Cc: Alex Williamson [EMAIL PROTECTED] Cc: Aron Griffis [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL PROTECTED] --- Tue, 04 Dec 2007 22:19:26 +0900 * Remove duplicate comment Thu, 06 Dec 2007 16:09:14 +0900 * rr index should be bitshifted 61 bits to the left Thu, 24 Jan 2008 16:02:33 +0900 * Check rr7 not rr6, as the rr changes don't really take full affect until rr7 is switched - and checking on rr6 doesn't work in alt_dtlb_miss Index: xen-unstable.hg/xen/arch/ia64/xen/ivt.S === --- xen-unstable.hg.orig/xen/arch/ia64/xen/ivt.S2008-02-05 16:18:54.0 +0900 +++ xen-unstable.hg/xen/arch/ia64/xen/ivt.S 2008-02-05 16:18:54.0 +0900 @@ -207,17 +207,37 @@ late_alt_dtlb_miss: (p8) br.cond.sptk frametable_miss ;; #endif // If it is not a Xen address, handle it via page_fault. + //!( ((r22 == 0x18 || r22 == 0x1c) rr7 == XEN_EFI_RID) || + // r22 == 0x1e ) + // Note that rr7 == XEN_EFI_RID implies rr6 == XEN_EFI_RID extr.u r22=r16,59,5 ;; dep r20=0,r20,IA64_ITIR_KEY,IA64_ITIR_KEY_LEN // clear the key - cmp.ne p8,p0=0x1e,r22 -(p8) br.cond.sptk page_fault + movl r23=7 61 ;; + mov r23=rr[r23] + ;; + mov r25=XEN_EFI_RID + cmp.eq p8,p0=0x18,r22 // 0xc... + ;; + cmp.eq.or p8,p0=0x1c,r22// 0xe... + ;; + cmp.eq.and p8,p0=r25,r23// rr7 == XEN_EFI_RID + ;; + cmp.eq.or p8,p0=0x1e,r22// 0xf... +(p8) br.cond.spnt alt_dtlb_miss_identity_map + br.cond.spnt page_fault + ;; +alt_dtlb_miss_identity_map: dep r21=-1,r21,IA64_PSR_ED_BIT,1 or r19=r19,r17 // insert PTE control bits into r19 mov cr.itir=r20 // set itir with cleared key ;; - dep r19=r18,r19,4,1 // set bit 4 (uncached) if access to UC area + cmp.ne p8,p0=r0,r18 // Xen UC bit set + ;; + cmp.eq.or p8,p0=0x18,r22// Region 6 is UC for EFI + ;; +(p8) dep r19=-1,r19,4,1 // set bit 4 (uncached) if access to UC area (p6) mov cr.ipsr=r21 ;; (p7) itc.d r19 // insert the TLB entry -- -- Horms ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch 09/11] ia64: kexec: define EFI offsets for identity mapping
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.0 +0900 +++ xen-unstable.hg/xen/include/asm-ia64/xensystem.h2008-02-05 16:18:58.0 +0900 @@ -33,6 +33,12 @@ #define KERNEL_START0xf4000400 #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 0xc000UL +#define __IA64_EFI_CACHED_OFFSET 0xe000UL + #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
[Xen-ia64-devel] [patch 06/11] ia64: kexec: Use a separate RID for EFI
This activates the use of the EFI RID.
The basic idea 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.
Subsequent patches move EFI memory such that faults to it will
be protected by the EFI RID.
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]
---
Tue, 23 Oct 2007 15:47:27 +0900
* Don't use #ifndef XEN to denote changes to SAL, PAL and EFI macros,
as this means that the macros have to be duplicated which leads to
a very bulky patch. Instead, define the new functionality as
XEN_EFI_RR_SAVE and XEN_EFI_RR_RESTORE (previously EFI_RR_SAV and
EFI_RR_RESTOR) and put these macros straight into the existing macros -
this should be obvious enough for future up-porters.
As suggested by Alex Williamson.
* Break header changes out into a separate patch
* Break macro definitions out into a separate patch and
put them in efi.h instead of pal.h. Documentation of how the
EFI RID is selected is included in this new patch.
* Use a uniform defineition of XEN_EFI_RID in assembly and C code
Mon, 29 Oct 2007 13:43:33 +0900
* Put assembly code into a separate patch
* C code is no longer needed with the new assembly code
Mon, 12 Nov 2007 12:02:59 +0900
* Trivial upport to ia64/xen-unstable.hg 16287:b235b68a0f4f
Thu, 22 Nov 2007 00:19:38 -0700
* Make use of XEN_EFI_RR_DECLARE for consistency
- There were instances of rr6 and rr7 that were declared as int
instead of unsigned long which caused compiler warnings
Fri, 07 Dec 2007 13:44:35 +0900
* Remove stray use of ia64_set_rr
* Relplace stray declaration of rr6 and rr7 with XEN_EFI_RR_DECLARE
Index: xen-unstable.hg/xen/include/asm-ia64/linux/asm/sal.h
===
--- xen-unstable.hg.orig/xen/include/asm-ia64/linux/asm/sal.h 2008-02-05
16:18:41.0 +0900
+++ xen-unstable.hg/xen/include/asm-ia64/linux/asm/sal.h2008-02-05
16:18:53.0 +0900
@@ -52,9 +52,12 @@ extern spinlock_t sal_lock;
# define SAL_CALL(result,args...) do { \
unsigned long __ia64_sc_flags; \
struct ia64_fpreg __ia64_sc_fr[6]; \
+ XEN_EFI_RR_DECLARE(rr6, rr7); \
ia64_save_scratch_fpregs(__ia64_sc_fr); \
spin_lock_irqsave(sal_lock, __ia64_sc_flags); \
+ XEN_EFI_RR_SAVE(rr6, rr7); \
__SAL_CALL(result, args); \
+ XEN_EFI_RR_RESTORE(rr6, rr7); \
spin_unlock_irqrestore(sal_lock, __ia64_sc_flags); \
ia64_load_scratch_fpregs(__ia64_sc_fr); \
} while (0)
@@ -62,18 +65,24 @@ extern spinlock_t sal_lock;
# define SAL_CALL_NOLOCK(result,args...) do { \
unsigned long __ia64_scn_flags; \
struct ia64_fpreg __ia64_scn_fr[6]; \
+ XEN_EFI_RR_DECLARE(rr6, rr7); \
ia64_save_scratch_fpregs(__ia64_scn_fr);\
local_irq_save(__ia64_scn_flags); \
+ XEN_EFI_RR_SAVE(rr6, rr7); \
__SAL_CALL(result, args); \
+ XEN_EFI_RR_RESTORE(rr6, rr7); \
local_irq_restore(__ia64_scn_flags);\
ia64_load_scratch_fpregs(__ia64_scn_fr);\
} while (0)
# define SAL_CALL_REENTRANT(result,args...) do { \
struct ia64_fpreg __ia64_scs_fr[6]; \
+ XEN_EFI_RR_DECLARE(rr6, rr7); \
ia64_save_scratch_fpregs(__ia64_scs_fr);\
preempt_disable(); \
+ XEN_EFI_RR_SAVE(rr6, rr7); \
__SAL_CALL(result, args); \
+ XEN_EFI_RR_RESTORE(rr6, rr7); \
preempt_enable(); \
ia64_load_scratch_fpregs(__ia64_scs_fr);\
} while (0)
Index: xen-unstable.hg/xen/arch/ia64/linux-xen/efi.c
===
--- xen-unstable.hg.orig/xen/arch/ia64/linux-xen/efi.c 2008-02-05
16:18:41.0 +0900
+++ xen-unstable.hg/xen/arch/ia64/linux-xen/efi.c 2008-02-05
16:18:53.0 +0900
@@ -65,11 +65,14 @@ prefix##_get_time (efi_time_t *tm, efi_t
struct ia64_fpreg fr[6];
\
[Xen-ia64-devel] [patch 11/11] 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
manifests.
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 [EMAIL PROTECTED]
Cc: Tristan Gingold [EMAIL PROTECTED]
Cc: Alex Williamson [EMAIL PROTECTED]
Cc: Aron Griffis [EMAIL PROTECTED]
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Index: xen-unstable.hg/xen/arch/ia64/linux-xen/efi.c
===
--- xen-unstable.hg.orig/xen/arch/ia64/linux-xen/efi.c 2008-03-19
11:52:41.0 +0900
+++ xen-unstable.hg/xen/arch/ia64/linux-xen/efi.c 2008-03-19
11:54:55.0 +0900
@@ -638,6 +638,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;
+ }
+#else
if (md-attribute EFI_MEMORY_RUNTIME) {
/*
* Some descriptors have multiple bits set, so the
order of
@@ -670,6 +681,7 @@ efi_enter_virtual_mode (void)
#endif
}
}
+#endif
}
status = efi_call_phys(__va(runtime-set_virtual_address_map),
Index: xen-unstable.hg/xen/include/asm-ia64/xenpage.h
===
--- xen-unstable.hg.orig/xen/include/asm-ia64/xenpage.h 2008-03-19
11:55:02.0 +0900
+++ xen-unstable.hg/xen/include/asm-ia64/xenpage.h 2008-03-19
11:55:16.0 +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;})
-/* Do __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)((unsigned long)(x) | __IA64_EFI_CACHED_OFFSET)
-#else
-#define __va_efi(x)__va(x)
-#endif
#endif
#endif /* _ASM_IA64_XENPAGE_H */
--
--
Horms
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Where to compile additional IVT.S
Dong, Eddie wrote: Alex/Isaku: Current the make file is to compile additional ivt.S at kernel/., another approach is to compile in xen/.. The later one has following benfit: 1: Easy to read for Makefile and easy to extend for more hypervisors. 2: Xen specific ministate.h can be in arch/ia64/xen/, like the one under arch/ia64/kernel. I am not a makefile expert, just use this example to explain idea, suggestion? thanks, eddie Here is the formal patch for this. Thanks, eddie Move 2nd compile of ivt.S to per hypervisor sub dir. Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED] diff --git a/arch/ia64/kernel/Makefile b/arch/ia64/kernel/Makefile index 3e9a162..78ec040 100644 --- a/arch/ia64/kernel/Makefile +++ b/arch/ia64/kernel/Makefile @@ -80,16 +80,3 @@ $(obj)/gate-data.o: $(obj)/gate.so # AFLAGS_ivt.o += -D__IA64_ASM_PARAVIRTUALIZED_NATIVE -# xen multi compile -$(obj)/xen_%.o: $(src)/%.S FORCE - $(call if_changed_dep,as_o_S) - -# -# xenivt.o -# -obj-$(CONFIG_XEN) += xen_ivt.o -ifeq ($(CONFIG_XEN), y) -targets += xen_ivt.o -$(obj)/build-in.o: xen_ivt.o -endif -AFLAGS_xen_ivt.o += -D__IA64_ASM_PARAVIRTUALIZED_XEN diff --git a/arch/ia64/xen/Makefile b/arch/ia64/xen/Makefile index 87e29d2..605b757 100644 --- a/arch/ia64/xen/Makefile +++ b/arch/ia64/xen/Makefile @@ -2,7 +2,11 @@ # Makefile for Xen components # +KBUILD_AFLAGS += -D__IA64_ASM_PARAVIRTUALIZED_XEN + obj-y := hypercall.o time.o xenivt.o xensetup.o xen_pv_ops.o irq_xen.o \ hypervisor.o util.o xencomm.o xcom_hcall.o xcom_asm.o paravirt_xen.o +obj-y += ../kernel/ivt.o + obj-$(CONFIG_IA64_GENERIC) += machvec.o diff --git a/arch/ia64/xen/xenivt.S b/arch/ia64/xen/xenivt.S index c688aaa..2d509f2 100644 --- a/arch/ia64/xen/xenivt.S +++ b/arch/ia64/xen/xenivt.S @@ -13,7 +13,6 @@ #include asm/kregs.h #include asm/pgtable.h -#define __IA64_ASM_PARAVIRTUALIZED_XEN #include asm/xen/inst.h #include asm/xen/minstate.h #include ../kernel/minstate.h ivt_simplify.patch Description: ivt_simplify.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen common code across architecture
Jeremy all: Current xen kernel codes are in arch/x86/xen, but xen dynamic irqchip (events.c) are common for other architectures such as IA64. We are in progress with enabling pv_ops for IA64 now and want to reuse same code, do we need to move the code to some place common? suggestions? Thanks, eddie ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] linux: need to set psr.ac in page_fault
On Wed, 2008-03-19 at 22:46 +0900, Akio Takebe wrote: Hi, This patch fixes a different behavior from the original code. We need to set psr.ac. diff -r ba72914de93a arch/ia64/xen/xenivt.S --- a/arch/ia64/xen/xenivt.SWed Mar 05 17:29:05 2008 + +++ b/arch/ia64/xen/xenivt.SThu Mar 20 06:53:32 2008 +0900 @@ -696,16 +696,19 @@ ENTRY(page_fault) st4 [r3]=r14// vpsr.ic = 1 adds r3=8,r2// set up second base pointer ;; +#ifdef PSR_DEFAULT_BITS + sum PSR_DEFAULT_BITS +#endif How would we ever get here w/o PSR_DEFAULT_BITS defined? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] fix TLB miss behavior with physical mode
On Mon, 2008-03-17 at 20:30 +0900, Kouya Shimura wrote: The emulation of physical mode will be more precise with this patch. (The previous patch implies a bug. Windows 2003 can't boot.) Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] increase hv memory reservation
On Tue, 2008-03-18 at 17:07 -0400, Jarod Wilson wrote: Not sure if this is actually relevant for hg tip anymore, but with Red Hat's rebase to xen 3.1.2, that if we try to allocate all memory to dom0, we're not leaving enough for the hypervisor anymore. Our quick fix was to simply increase the reservation guestimate by 128M. This does still seem to be relevant, I can make my system unbootable by specifying max_addr=1G dom0_mem=1G. With the patch, it boots up and I can even still create a 256M domU. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: new SIOEMU interface
On Thu, 2008-03-20 at 07:11 +0100, [EMAIL PROTECTED] wrote: Hi, this patch changes the SIOEMU callback interface. The old method was flawed: the callback data were lost if occuring during an hypercall. This new interface is not backward compatible. I think it is not an issue since sioemu is not widely deployed. As currently committed, the sioemu fw should work with this new interface (e1000 is even available). But I still have one xen patch to submit before generating a binary fw for sioemu. Applied. I agree, I don't think we need to worry about sioemu backwards compatibility just yet. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
