All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
@ 2017-11-06 20:17 Tom Lendacky
  2017-11-06 20:25 ` Tom Lendacky
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Tom Lendacky @ 2017-11-06 20:17 UTC (permalink / raw)
  To: x86
  Cc: Peter Zijlstra, linux-kernel, Ingo Molnar, Borislav Petkov,
	H. Peter Anvin, Thomas Gleixner, Tomeu Vizoso

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@tomeuvizoso.net>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/kernel/mpparse.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index 5cbb317..c3d3094 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -430,6 +430,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
 }
 
 static unsigned long mpf_base;
+static bool mpf_found;
 
 static unsigned long __init get_mpc_size(unsigned long physptr)
 {
@@ -503,7 +504,7 @@ void __init default_get_smp_config(unsigned int early)
 	if (!smp_found_config)
 		return;
 
-	if (!mpf_base)
+	if (!mpf_found)
 		return;
 
 	if (acpi_lapic && early)
@@ -592,6 +593,7 @@ static int __init smp_scan_config(unsigned long base, unsigned long length)
 			smp_found_config = 1;
 #endif
 			mpf_base = base;
+			mpf_found = true;
 
 			pr_info("found SMP MP-table at [mem %#010lx-%#010lx] mapped at [%p]\n",
 				base, base + sizeof(*mpf) - 1, mpf);
@@ -857,7 +859,7 @@ static int __init update_mp_table(void)
 	if (!enable_update_mptable)
 		return 0;
 
-	if (!mpf_base)
+	if (!mpf_found)
 		return 0;
 
 	mpf = early_memremap(mpf_base, sizeof(*mpf));

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-06 20:17 [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0 Tom Lendacky
@ 2017-11-06 20:25 ` Tom Lendacky
  2017-11-06 21:41 ` H. Peter Anvin
  2017-11-17 15:25 ` [tip:x86/urgent] " tip-bot for Tom Lendacky
  2 siblings, 0 replies; 11+ messages in thread
From: Tom Lendacky @ 2017-11-06 20:25 UTC (permalink / raw)
  To: x86
  Cc: Peter Zijlstra, linux-kernel, Ingo Molnar, Borislav Petkov,
	H. Peter Anvin, Thomas Gleixner, Tomeu Vizoso

On 11/6/2017 2:17 PM, 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@tomeuvizoso.net>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

I forgot to add a Fixes tag. If the patch is acceptable as is, let me know
if you would prefer another version with the Fixes tag or if you can add
it when merged:

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

Thanks,
Tom

> ---
>   arch/x86/kernel/mpparse.c |    6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
> index 5cbb317..c3d3094 100644
> --- a/arch/x86/kernel/mpparse.c
> +++ b/arch/x86/kernel/mpparse.c
> @@ -430,6 +430,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
>   }
>   
>   static unsigned long mpf_base;
> +static bool mpf_found;
>   
>   static unsigned long __init get_mpc_size(unsigned long physptr)
>   {
> @@ -503,7 +504,7 @@ void __init default_get_smp_config(unsigned int early)
>   	if (!smp_found_config)
>   		return;
>   
> -	if (!mpf_base)
> +	if (!mpf_found)
>   		return;
>   
>   	if (acpi_lapic && early)
> @@ -592,6 +593,7 @@ static int __init smp_scan_config(unsigned long base, unsigned long length)
>   			smp_found_config = 1;
>   #endif
>   			mpf_base = base;
> +			mpf_found = true;
>   
>   			pr_info("found SMP MP-table at [mem %#010lx-%#010lx] mapped at [%p]\n",
>   				base, base + sizeof(*mpf) - 1, mpf);
> @@ -857,7 +859,7 @@ static int __init update_mp_table(void)
>   	if (!enable_update_mptable)
>   		return 0;
>   
> -	if (!mpf_base)
> +	if (!mpf_found)
>   		return 0;
>   
>   	mpf = early_memremap(mpf_base, sizeof(*mpf));
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-06 20:17 [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0 Tom Lendacky
  2017-11-06 20:25 ` Tom Lendacky
@ 2017-11-06 21:41 ` H. Peter Anvin
  2017-11-06 22:01   ` Tom Lendacky
  2017-11-17 15:25 ` [tip:x86/urgent] " tip-bot for Tom Lendacky
  2 siblings, 1 reply; 11+ messages in thread
From: H. Peter Anvin @ 2017-11-06 21:41 UTC (permalink / raw)
  To: Tom Lendacky, x86
  Cc: Peter Zijlstra, linux-kernel, Ingo Molnar, Borislav Petkov,
	Thomas Gleixner, Tomeu Vizoso

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@tomeuvizoso.net>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-06 21:41 ` H. Peter Anvin
@ 2017-11-06 22:01   ` Tom Lendacky
  2017-11-06 23:00     ` Tom Lendacky
                       ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Tom Lendacky @ 2017-11-06 22:01 UTC (permalink / raw)
  To: H. Peter Anvin, x86
  Cc: Peter Zijlstra, linux-kernel, Ingo Molnar, Borislav Petkov,
	Thomas Gleixner, Tomeu Vizoso

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@tomeuvizoso.net>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> 
> 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.

Thanks,
Tom

> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-06 22:01   ` Tom Lendacky
@ 2017-11-06 23:00     ` Tom Lendacky
  2017-11-16 11:40       ` Borislav Petkov
  2017-11-08  8:37     ` Tomeu Vizoso
  2017-11-17 13:03     ` Thomas Gleixner
  2 siblings, 1 reply; 11+ messages in thread
From: Tom Lendacky @ 2017-11-06 23:00 UTC (permalink / raw)
  To: H. Peter Anvin, x86
  Cc: Peter Zijlstra, linux-kernel, Ingo Molnar, Borislav Petkov,
	Thomas Gleixner, Tomeu Vizoso

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@tomeuvizoso.net>
>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>
>> 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
> 
>>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-06 22:01   ` Tom Lendacky
  2017-11-06 23:00     ` Tom Lendacky
@ 2017-11-08  8:37     ` Tomeu Vizoso
  2017-11-16  9:16       ` Tomeu Vizoso
  2017-11-17 13:03     ` Thomas Gleixner
  2 siblings, 1 reply; 11+ messages in thread
From: Tomeu Vizoso @ 2017-11-08  8:37 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: H. Peter Anvin, x86, Peter Zijlstra, linux-kernel, Ingo Molnar,
	Borislav Petkov, Thomas Gleixner

On 6 November 2017 at 23:01, Tom Lendacky <thomas.lendacky@amd.com> 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@tomeuvizoso.net>
>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>
>>
>> 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.

Do I understand correctly that the best we can do right now is
reverting 5997efb96756?

Thanks,

Tomeu

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-08  8:37     ` Tomeu Vizoso
@ 2017-11-16  9:16       ` Tomeu Vizoso
  2017-11-16  9:20         ` Tomeu Vizoso
  0 siblings, 1 reply; 11+ messages in thread
From: Tomeu Vizoso @ 2017-11-16  9:16 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: H. Peter Anvin, x86, Peter Zijlstra, linux-kernel, Ingo Molnar,
	Borislav Petkov, Thomas Gleixner, regression, Guenter Roeck,
	Zach Reizner

Adding regression@leemhuis.info to CC so this regression is tracked.

Regards,

Tomeu

On 8 November 2017 at 09:37, Tomeu Vizoso <tomeu@tomeuvizoso.net> wrote:
> On 6 November 2017 at 23:01, Tom Lendacky <thomas.lendacky@amd.com> 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@tomeuvizoso.net>
>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>
>>>
>>> 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.
>
> Do I understand correctly that the best we can do right now is
> reverting 5997efb96756?
>
> Thanks,
>
> Tomeu

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-16  9:16       ` Tomeu Vizoso
@ 2017-11-16  9:20         ` Tomeu Vizoso
  0 siblings, 0 replies; 11+ messages in thread
From: Tomeu Vizoso @ 2017-11-16  9:20 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: H. Peter Anvin, x86, Peter Zijlstra, linux-kernel, Ingo Molnar,
	Borislav Petkov, Thomas Gleixner, Guenter Roeck, Zach Reizner,
	regressions

And now with the correct email.

Sorry about that,

Tomeu

On 16 November 2017 at 10:16, Tomeu Vizoso <tomeu@tomeuvizoso.net> wrote:
> Adding regression@leemhuis.info to CC so this regression is tracked.
>
> Regards,
>
> Tomeu
>
> On 8 November 2017 at 09:37, Tomeu Vizoso <tomeu@tomeuvizoso.net> wrote:
>> On 6 November 2017 at 23:01, Tom Lendacky <thomas.lendacky@amd.com> 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@tomeuvizoso.net>
>>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>>
>>>>
>>>> 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.
>>
>> Do I understand correctly that the best we can do right now is
>> reverting 5997efb96756?
>>
>> Thanks,
>>
>> Tomeu

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-06 23:00     ` Tom Lendacky
@ 2017-11-16 11:40       ` Borislav Petkov
  0 siblings, 0 replies; 11+ messages in thread
From: Borislav Petkov @ 2017-11-16 11:40 UTC (permalink / raw)
  To: Tom Lendacky, H. Peter Anvin
  Cc: x86, Peter Zijlstra, linux-kernel, Ingo Molnar, Thomas Gleixner,
	Tomeu Vizoso

On Mon, Nov 06, 2017 at 05:00:31PM -0600, Tom Lendacky wrote:
> 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.

Dunno, should we support any braindead vm implementation which puts
stuff in the low megabyte?

I mean, the fix is simple enough and we probably don't care all that
much whatever potent sh*t people are smoking as long as it is all the
same to the kernel...

IMO.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-06 22:01   ` Tom Lendacky
  2017-11-06 23:00     ` Tom Lendacky
  2017-11-08  8:37     ` Tomeu Vizoso
@ 2017-11-17 13:03     ` Thomas Gleixner
  2 siblings, 0 replies; 11+ messages in thread
From: Thomas Gleixner @ 2017-11-17 13:03 UTC (permalink / raw)
  To: Tom Lendacky
  Cc: H. Peter Anvin, x86, Peter Zijlstra, linux-kernel, Ingo Molnar,
	Borislav Petkov, Tomeu Vizoso

On Mon, 6 Nov 2017, 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@tomeuvizoso.net>
> > > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> > 
> > 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.

This goes back to Linux 1.1.x

/*
 * Physical page 0 is special; it's not touched by Linux since BIOS
 * and SMM (for laptops with [34]86/SL chips) may need it.  It is read
 * and write protected to detect null pointer references in the
 * kernel.
 * It may also hold the MP configuration table when we are booting SMP.
 */

and then got changed in 2.3.40 to:

	/*
	 * FIXME: Linux assumes you have 640K of base ram..
	 * this continues the error...
	 *
	 * 1) Scan the bottom 1K for a signature
	 * 2) Scan the top 1K of base RAM
	 * 3) Scan the 64K of bios
	 */
	if (smp_scan_config(0x0, 0x400) ||
	    smp_scan_config(639 * 0x400, 0x400) ||
	    smp_scan_config(0xF0000, 0x10000))
		return;

which is what we still have completely unmodified.

What hpa considers to be epic fail was added 20+ years ago and probably
with a reason. We carried that along forever and now someone looked for a
place to stick MP config in for his VM thingy and picked the first place
which is checked. Not a big surprise.

So we are stuck with it, whether we like it or not.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [tip:x86/urgent] x86/boot: Fix boot failure when SMP MP-table is based at 0
  2017-11-06 20:17 [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0 Tom Lendacky
  2017-11-06 20:25 ` Tom Lendacky
  2017-11-06 21:41 ` H. Peter Anvin
@ 2017-11-17 15:25 ` tip-bot for Tom Lendacky
  2 siblings, 0 replies; 11+ messages in thread
From: tip-bot for Tom Lendacky @ 2017-11-17 15:25 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: thomas.lendacky, peterz, tglx, linux-kernel, bp, tomeu, mingo, hpa

Commit-ID:  ac5292e9a294618cecb31109d1ba265e3d027ba2
Gitweb:     https://git.kernel.org/tip/ac5292e9a294618cecb31109d1ba265e3d027ba2
Author:     Tom Lendacky <thomas.lendacky@amd.com>
AuthorDate: Mon, 6 Nov 2017 14:17:53 -0600
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 17 Nov 2017 15:30:33 +0100

x86/boot: Fix boot failure when SMP MP-table is based at 0

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.

Fixes: 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: regression@leemhuis.info
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20171106201753.23059.86674.stgit@tlendack-t1.amdoffice.net

---
 arch/x86/kernel/mpparse.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index 410c5da..3a4b128 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -431,6 +431,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
 }
 
 static unsigned long mpf_base;
+static bool mpf_found;
 
 static unsigned long __init get_mpc_size(unsigned long physptr)
 {
@@ -504,7 +505,7 @@ void __init default_get_smp_config(unsigned int early)
 	if (!smp_found_config)
 		return;
 
-	if (!mpf_base)
+	if (!mpf_found)
 		return;
 
 	if (acpi_lapic && early)
@@ -593,6 +594,7 @@ static int __init smp_scan_config(unsigned long base, unsigned long length)
 			smp_found_config = 1;
 #endif
 			mpf_base = base;
+			mpf_found = true;
 
 			pr_info("found SMP MP-table at [mem %#010lx-%#010lx] mapped at [%p]\n",
 				base, base + sizeof(*mpf) - 1, mpf);
@@ -858,7 +860,7 @@ static int __init update_mp_table(void)
 	if (!enable_update_mptable)
 		return 0;
 
-	if (!mpf_base)
+	if (!mpf_found)
 		return 0;
 
 	mpf = early_memremap(mpf_base, sizeof(*mpf));

^ permalink raw reply related	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2017-11-17 15:31 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-06 20:17 [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0 Tom Lendacky
2017-11-06 20:25 ` Tom Lendacky
2017-11-06 21:41 ` H. Peter Anvin
2017-11-06 22:01   ` Tom Lendacky
2017-11-06 23:00     ` Tom Lendacky
2017-11-16 11:40       ` Borislav Petkov
2017-11-08  8:37     ` Tomeu Vizoso
2017-11-16  9:16       ` Tomeu Vizoso
2017-11-16  9:20         ` Tomeu Vizoso
2017-11-17 13:03     ` Thomas Gleixner
2017-11-17 15:25 ` [tip:x86/urgent] " tip-bot for Tom Lendacky

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.