Re: pvops dom0 work roadmap

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 08/19/09 10:35, M A Young wrote:
> On Wed, 19 Aug 2009, Jeremy Fitzhardinge wrote:
>
>> On 08/19/09 08:27, M A Young wrote:
>>> On Tue, 18 Aug 2009, Jeremy Fitzhardinge wrote:
>>>
>>>>    * make sure rebase/master is fairly functional and somewhat stable
>>>>    * rename rebase/* to xen/*
>>>>    * use it as the baseline dom0 and domU kernel in xen-unstable
>>>
>>> I have had problems booting rebase/master on i686 for some time now.
>>> The most recent crash looks different, and might be a STACKPROTECTOR
>>> issue (which I just turned back on). The log ends
>>
>> What happens before then?  What stage is it at?
>
> The previous problem gets a bit further, then reboots (in earlier
> builds I think it hung) after
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to Xen)
> (XEN) Freed 116kB init memory.
> mapping kernel into physical memory
> Xen: setup ISA identity maps
> about to get started...
> (XEN) ioapic_guest_write: apic=0, pin=0, old_irq=0, new_irq=-1
> (XEN) ioapic_guest_write: old_entry=000009f0, new_entry=00010900
> (XEN) ioapic_guest_write: Attempt to remove IO-APIC pin of in-use IRQ!
> (XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=-1
> (XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00010900
> (XEN) ioapic_guest_write: Attempt to remove IO-APIC pin of in-use IRQ!
>
>
>>> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>>> input to Xen)
>>> (XEN) Freed 116kB init memory.
>>> (XEN) d0:v0: unhandled page fault (ec=0000)
>>> (XEN) Pagetable walk from 00000014:
>>> (XEN)  L3[0x000] = 000000001bc03001 00001c03
>>> (XEN)  L2[0x000] = 0000000000000000 ffffffff
>>> (XEN) domain_crash_sync called from entry.S (ff1b1cbe)
>>> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
>>> (XEN) ----[ Xen-3.4.1  x86_32p  debug=n  Not tainted ]----
>>> (XEN) CPU:    0
>>> (XEN) EIP:    e019:[<c0aaa9d0>]
>>
>> What does this correspond to?
>
> (gdb) x/i 0xc0aaa9d0
> 0xc0aaa9d0 <xen_init_irq_ops+23>:    mov    %gs:0x14,%eax

Ah, right, stackprotector.  Please try the patches below (or try current
rebase/master).

    J

>From 3576935da8f4eeb0de6a3d7bd31b2422d39de30d Mon Sep 17 00:00:00 2001
From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date: Mon, 17 Aug 2009 12:25:41 -0700
Subject: [PATCH] x86: make sure load_percpu_segment has no stackprotector

load_percpu_segment() is used to set up the per-cpu segment registers,
which are also used for -fstack-protector.  Make sure that the
load_percpu_segment() function doesn't have stackprotector enabled.

[ Impact: allow percpu setup before calling stack-protected functions ]

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 3efcb2b..c1f253d 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -7,6 +7,10 @@ ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_common.o = -pg
 endif
 
+# Make sure load_percpu_segment has no stackprotector
+nostackp := $(call cc-option, -fno-stack-protector)
+CFLAGS_common.o		:= $(nostackp)
+
 obj-y			:= intel_cacheinfo.o addon_cpuid_features.o
 obj-y			+= proc.o capflags.o powerflags.o common.o
 obj-y			+= vmware.o hypervisor.o


>From ea1ea74befd78dc8386bc9619ebc045de69a4b3c Mon Sep 17 00:00:00 2001
From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date: Mon, 17 Aug 2009 12:26:53 -0700
Subject: [PATCH] xen: rearrange things to fix stackprotector

Make sure the stack-protector segment registers are properly set up
before calling any functions which may have stack-protection compiled
into them.

[ Impact: prevent Xen early-boot crash when stack-protector is enabled ]
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 172438f..7410640 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -5,6 +5,10 @@ CFLAGS_REMOVE_time.o = -pg
 CFLAGS_REMOVE_irq.o = -pg
 endif
 
+# Make sure early boot has no stackprotector
+nostackp := $(call cc-option, -fno-stack-protector)
+CFLAGS_enlighten.o		:= $(nostackp)
+
 obj-y		:= enlighten.o setup.o multicalls.o mmu.o irq.o \
 			time.o xen-asm.o xen-asm_$(BITS).o \
 			grant-table.o suspend.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 121f272..c55ea67 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -984,10 +984,6 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
-	BUG_ON(memcmp(xen_start_info->magic, "xen-3", 5) != 0);
-
-	xen_setup_features();
-
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
@@ -996,8 +992,15 @@ asmlinkage void __init xen_start_kernel(void)
 	pv_apic_ops = xen_apic_ops;
 	pv_mmu_ops = xen_mmu_ops;
 
-	xen_init_irq_ops();
+#ifdef CONFIG_X86_64
+	/*
+	 * Setup percpu state.  We only need to do this for 64-bit
+	 * because 32-bit already has %fs set properly.
+	 */
+	load_percpu_segment(0);
+#endif
 
+	xen_init_irq_ops();
 	xen_init_cpuid_mask();
 
 #ifdef CONFIG_X86_LOCAL_APIC
@@ -1007,6 +1010,8 @@ asmlinkage void __init xen_start_kernel(void)
 	set_xen_basic_apic_ops();
 #endif
 
+	xen_setup_features();
+
 	if (xen_feature(XENFEAT_mmu_pt_update_preserve_ad)) {
 		pv_mmu_ops.ptep_modify_prot_start = xen_ptep_modify_prot_start;
 		pv_mmu_ops.ptep_modify_prot_commit = xen_ptep_modify_prot_commit;
@@ -1014,13 +1019,6 @@ asmlinkage void __init xen_start_kernel(void)
 
 	machine_ops = xen_machine_ops;
 
-#ifdef CONFIG_X86_64
-	/*
-	 * Setup percpu state.  We only need to do this for 64-bit
-	 * because 32-bit already has %fs set properly.
-	 */
-	load_percpu_segment(0);
-#endif
 	/*
 	 * The only reliable way to retain the initial address of the
 	 * percpu gdt_page is to remember it here, so we can go and