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-ia64-devel] xen: ia64: kexec: Unpin TLB in the hypervisor

To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-ia64-devel] xen: ia64: kexec: Unpin TLB in the hypervisor
From: horms@xxxxxxxxxxxx (Horms)
Date: Fri, 29 Feb 2008 13:16:53 +0900 (JST)
Cc: Alex Williamson <alex.williamson@xxxxxx>
Delivery-date: Thu, 28 Feb 2008 20:17:12 -0800
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
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
supplied separately.

Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>


 arch/ia64/kernel/relocate_kernel.S |   38 +-----------------------------------
 1 file changed, 2 insertions(+), 36 deletions(-)
Index: linux-2.6.18-xen.hg/arch/ia64/kernel/relocate_kernel.S
--- linux-2.6.18-xen.hg.orig/arch/ia64/kernel/relocate_kernel.S 2008-02-05 
18:32:39.000000000 +0900
+++ linux-2.6.18-xen.hg/arch/ia64/kernel/relocate_kernel.S      2008-02-06 
12:25:03.000000000 +0900
@@ -20,11 +20,7 @@
-#ifdef CONFIG_XEN
-       alloc r31=ar.pfs,8,0,0,0
        alloc r31=ar.pfs,4,0,0,0
@@ -37,11 +33,7 @@ GLOBAL_ENTRY(relocate_new_kernel)
-#ifdef CONFIG_XEN
-       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 @@ GLOBAL_ENTRY(relocate_new_kernel)
        //physical mode code begin
        mov b6=in1
 #ifdef CONFIG_XEN
-       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
-#ifdef CONFIG_XEN
-       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
         addl r17=O(PTCE_STRIDE),r2
         addl r2=O(PTCE_BASE),r2
@@ -111,11 +98,7 @@ GLOBAL_ENTRY(relocate_new_kernel)
        //purge TR entry for kernel text and data
-#ifdef CONFIG_XEN
-       mov r16=in5
         movl r16=KERNEL_START
         mov r18=KERNEL_TR_PAGE_SHIFT<<2
         ptr.i r16, r18
@@ -146,11 +129,7 @@ GLOBAL_ENTRY(relocate_new_kernel)
         mov r16=IA64_KR(CURRENT_STACK)
         shl r16=r16,IA64_GRANULE_SHIFT
-#ifdef CONFIG_XEN
-       mov r19=in6
         movl r19=PAGE_OFFSET
         add r16=r19,r16
         mov r18=IA64_GRANULE_SHIFT<<2
@@ -159,20 +138,7 @@ GLOBAL_ENTRY(relocate_new_kernel)
-#ifdef XEN
-       /* 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
-        ;;
-        srlz.i
-       ;;
+#endif /* ! CONFIG_XEN */
        //copy segments
        movl r16=PAGE_MASK

Xen-ia64-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>