Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

From: Tom Lendacky
Date: Mon Nov 06 2017 - 18:00:45 EST


On 11/6/2017 4:01 PM, Tom Lendacky wrote:
On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
On 11/06/17 12:17, Tom Lendacky wrote:
When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
at physical address 0x0. This causes mpf_base to be set to 0 and a
subsequent "if (!mpf_base)" check in default_get_smp_config() results in
the MP-table not being parsed. Further into the boot this results in an
oops when attempting a read_apic_id().

Add a boolean variable that is set to true when the MP-table is found.
Use this variable for testing if the MP-table was found so that even a
value of 0 for mpf_base will result in continued parsing of the MP-table.

Reported-by: Tomeu Vizoso <tomeu@xxxxxxxxxxxxxxx>
Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>

Ahem... did anyone ever tell you that this is an epicly bad idea on your
part? The low megabyte of physical memory has very special meaning on
x86, and deviating from the standard use of this memory is a *very*
dangerous thing to do, and imposing on the kernel a "fake null pointer"
requirement that exists only for the convenience of your particular
brokenness is not okay.

ÂÂÂÂ-hpa

That was my initial thought... what was something doing down at the start
of memory. But when I looked at default_find_smp_config() it specifically
scans the bottom 1K for a an MP-table signature. I was hoping to get some
feedback as to whether this would really be an acceptable thing to do. So
I'm good with this patch being rejected, but the change I made in

5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")

does break something that was working before.

Btw, it was working before because instead of saving off the physical
address as 5997efb96756 now does, it saved off a virtual address that
pointed to physical address 0 (0xffff880000000000) and used that in the
conditional.

Thanks,
Tom



Thanks,
Tom