# HG changeset patch
# User Alex Williamson <alex.williamson@xxxxxx>
# Date 1204301661 25200
# Node ID ee7015727bd15e80e17e725f70c0a5336e45607a
# Parent 423662c822832d8dc4b0cb31ae3be59a454663c3
[IA64] kexec: Unpin TLB in the hypervisor
In the case where kexec is being run for a xen dom0 or hypervisor,
this code, present in dom0, will be called from the hypervisor
after ia64_machine_kexec and before going into purgatory.
This code makes a large number of assumptions about various compile
time constants, and thus assumes that these constants are the
same for the hypervisor and dom0. Despite extensive #ifdef work this
has proved to be both fragile and incomplete.
This patch changes things around so that the unpinning work is done
by code provided by the hypervisor, reusing existing code there.
Apart from being a solution that works, its also likely
a much more maintainable solution, as as TLB changes in the hypervisor
code are made, the code paths in the hypervisor are much more likely
to be checked than this one which lies in a completely different tree.
With this change, and the corresponding change to the hypervisor,
the CPU will be running in "physical mode" when it enters this
relocate_new_kernel code. Previously the code was called with the
CPU in "virtual mode". This is still the case when the code is
called from a regular Linux kernel.
Code that switches the CPU into "physical mode" is still called.
This is primarily left in tact to ensure that the register stack
(bspstore) and stack (sp) are updated correctly. It could probably
be trimmed down a bit, but there seems little point.
When called from the hypervisor, in3 is ignored. The number
of parameters could hence be shrunk from 4 to 3, but again,
there seems little point.
This code still assumes that PAGE_SIZE and PAGE_MASK are the
same in the hypervisor and dom0. I am reluctant to fix this
as I think that it is unlikely this will change. But if it does,
the fix should be as easy as passing PAGE_SIZE as in3. I am quite
happy to create a patch if/when it is needed.
As noted above, there is a hypervisor portion of this patch
Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
arch/ia64/kernel/relocate_kernel.S | 38 +------------------------------------
1 files changed, 2 insertions(+), 36 deletions(-)
diff -r 423662c82283 -r ee7015727bd1 arch/ia64/kernel/relocate_kernel.S
--- a/arch/ia64/kernel/relocate_kernel.S Fri Feb 29 09:06:15 2008 -0700
+++ b/arch/ia64/kernel/relocate_kernel.S Fri Feb 29 09:14:21 2008 -0700
@@ -20,11 +20,7 @@
- alloc r31=ar.pfs,8,0,0,0
@@ -37,11 +33,7 @@ GLOBAL_ENTRY(relocate_new_kernel)
- dep r2=0,r2,60,4 //to physical address
dep r2=0,r2,61,3 //to physical address
//first switch to physical mode
add r3=1f-.reloc_entry, r2
@@ -66,18 +58,13 @@ 1:
//physical mode code begin
- dep r28=0,in2,60,4 //to physical address
+ mov r28=in2 //already a physical address
dep r28=0,in2,61,3 //to physical address
// purge all TC entries
#define O(member) IA64_CPUINFO_##member##_OFFSET
- mov r2=in4 // load phys addr of cpu_info into r2
GET_THIS_PADDR(r2, cpu_info) // load phys addr of cpu_info into r2
@@ -111,11 +98,7 @@ 4:
//purge TR entry for kernel text and data
- mov r16=in5
ptr.i r16, r18
@@ -146,11 +129,7 @@ 4:
- mov r19=in6
@@ -159,20 +138,7 @@ 4:
- /* XXX: Is this neccessary ??? */
- // purge TR entry for VHPT
- mov r16=in7
- dep r16=0,r16,0,IA64_GRANULE_SHIFT
- mov r18=IA64_GRANULE_SHIFT<<2
- ptr.d r16,r18
+#endif /* ! CONFIG_XEN */
Xen-changelog mailing list