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] [patch 1/1] Kexec: Accept TR to be unpinned by relocate

To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-ia64-devel] [patch 1/1] Kexec: Accept TR to be unpinned by relocate_new_kernel as an array
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Fri, 25 Jan 2008 17:19:59 +0900
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Delivery-date: Fri, 25 Jan 2008 00:40:14 -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>
References: <20080125081958.191499586@xxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: quilt/0.46-1
This accepts an array that describes all the TR entries to
be unpinned by relocate_new_kernel. As it stands relocate_new_kernel
makes several false assumptions about constants in xen-linux
being the same as xen, and fails to unpin several entries.
This is desipite heavy additions of #ifdef XEN code.

In order to pass all the required arguments to relocate_new_kernel,
aproximately 15 parameters would be needed. This is untidy.
And furthermore, only the first 8 parameters seem to get passed correctly.

Instead of this, the vaules are packed into an array, and
the base address of the array is passed.

I am still concerned about the TC (TLB cache) entry clearing
code in relocate_new_kernel, as it still makes assumptions
about xen-linux and xen having the same contants - however
these assumptions are currently valid.

I believe that it should be possible to further restructure things
such that the TR and TC unpinning portions of relocate_new_kernel are
replaced by code supplied by xen. This should be possible
because this code is run before the segmentation relocation takes place,
and thus xen memory should be accessable at this time. Such an
approach should be able to make use of ia64_do_tlb_purge,
reducing the both the ammount of code and maintenence overhead
in the future.

The construction of such a change would likely remove all of
the code incoporated in this patch. So I'm not aiming to have
this change merged until I investigate the code-in-xen idea.

There is also a xen portion to this patch.

Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>

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-01-25 
16:41:25.000000000 +0900
+++ linux-2.6.18-xen.hg/arch/ia64/kernel/relocate_kernel.S      2008-01-25 
16:41:45.000000000 +0900
@@ -21,7 +21,7 @@
 #ifdef CONFIG_XEN
-       alloc r31=ar.pfs,8,0,0,0
+       alloc r31=ar.pfs,5,0,0,0
        alloc r31=ar.pfs,4,0,0,0
@@ -66,6 +66,8 @@ GLOBAL_ENTRY(relocate_new_kernel)
        //physical mode code begin
        mov b6=in1
 #ifdef CONFIG_XEN
+       // XXX: This appears to work, but it assumes
+       // that the offsets are the same in linux and xen-linux
        dep r28=0,in2,60,4      //to physical address
        dep r28=0,in2,61,3      //to physical address
@@ -74,7 +76,7 @@ GLOBAL_ENTRY(relocate_new_kernel)
        // 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
+       mov r2=in3                      // load phys addr of cpu_info into r2
         GET_THIS_PADDR(r2, cpu_info)    // load phys addr of cpu_info into r2
@@ -110,12 +112,45 @@ GLOBAL_ENTRY(relocate_new_kernel)
-       //purge TR entry for kernel text and data
 #ifdef CONFIG_XEN
-       mov r16=in5
+       /* Array format is a list of control, vaddr pairs
+        * control: bits 0-1:   zero
+        *          bits 2-7:   log_2 page size
+        *          bits 8-62:  ignored
+        *          bit 63:     purge itlb if set
+        *          bit 62:     purge dtlb if set
+        * vaddr:
+        * ...
+        * Null control is the loop terminator
+        */
+       dep in4=0,in4,60,4              //to physical address
+       ;;
+       ld8 r2=[in4],8
+       ;;
+       cmp.eq p7,p0=r2,r0
+(p7)   br.cond.sptk.few tr_loop_end
+       ;;
+       extr r19=r2,62,1
+       extr r20=r2,63,1
+       ;;
+       cmp.ne p7,p0=r19,r0
+       cmp.ne p8,p0=r20,r0
+       ld8 r16=[in4],8
+       dep r18=0,r2,8,56
+       ;;
+(p8)   ptr.i r16, r18
+(p7)   ptr.d r16, r18
+       ;;
+(p8)   srlz.i
+(p7)   srlz.d
+       ;;
+       br.cond.sptk.few tr_loop
+       ;;
+#else /* !CONFIG_XEN */
+       //purge TR entry for kernel text and data
         movl r16=KERNEL_START
         mov r18=KERNEL_TR_PAGE_SHIFT<<2
         ptr.i r16, r18
@@ -146,11 +181,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 +190,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>