Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpuarea

From: Jeremy Fitzhardinge
Date: Fri Jul 25 2008 - 16:13:09 EST


Mike Travis wrote:
Jeremy Fitzhardinge wrote:
...
Last time it was doing this, it was a result of a triple-fault caused by
loading %ds with an all-zero gdt. I modified Xen to dump the CPU state
on triple-faults, so it was easy to pinpoint. I can do that again if it
helps.

J

Hi Jeremy,

There are two question marks for my patchset. The first is in

arch/x86/xen/smp.c:xen_cpu_up()

287 #ifdef CONFIG_X86_64
288 /* Allocate node local memory for AP pdas */
289 WARN_ON(cpu == 0);
290 if (cpu > 0) {
291 rc = get_local_pda(cpu);
292 if (rc)
293 return rc;
294 }
295 #endif

and the second is at:

arch/x86/xen/enlighten.c:xen_start_kernel()

1748 #ifdef CONFIG_X86_64
1749 /* Disable until direct per-cpu data access. */
1750 have_vcpu_info_placement = 0;
1751 x86_64_init_pda();
1752 #endif

I believe with the pda folded into the percpu area, get_local_pda()
and x86_64_init_pda() have been removed, so these are no longer
required, yes?

Well, presumably they need to be replaced with whatever setup you need to do now.

xen_start_kernel() is the first function called after a Xen kernel boot, and so it must make sure the early percpu setup is done before it can start using percpu variables.

xen_cpu_up() needs to do whatever initialization needed for a new cpu's percpu area (presumably whatever do_boot_cpu() does).

Also, arch/x86/kernel/acpi/sleep.c:acpi_save_state_mem() sets up
the startup code address with:

102 initial_code = (unsigned long)wakeup_long64;
103 saved_magic = 0x123456789abcdef0;

Should the pda and gdt_page address also be setup as is done in
smpboot.c:do_boot_cpu():

(CONFIG_X86_64)
801 initial_pda = (unsigned long)get_cpu_pda(cpu);
802 #endif
803 early_gdt_descr.address = (unsigned long)get_cpu_gdt_table(cpu);
804 initial_code = (unsigned long)start_secondary;
I don't think so. It looks like it's doing its own gdt save/restore.

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/