From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934100AbdKPJVb (ORCPT ); Thu, 16 Nov 2017 04:21:31 -0500 Received: from mail-io0-f177.google.com ([209.85.223.177]:37859 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934078AbdKPJVJ (ORCPT ); Thu, 16 Nov 2017 04:21:09 -0500 X-Google-Smtp-Source: AGs4zMZQsChQm+uEtmhIKvsnIgy1AYrao6JrQIlpQrd9hie/ERpHaJ+IVp6hciYsbMfaNZYaAJkACA== MIME-Version: 1.0 In-Reply-To: References: <20171106201753.23059.86674.stgit@tlendack-t1.amdoffice.net> <17a1c480-d0aa-b272-7ca3-5dd2cf2fd7dc@amd.com> From: Tomeu Vizoso Date: Thu, 16 Nov 2017 10:20:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0 To: Tom Lendacky Cc: "H. Peter Anvin" , x86@kernel.org, Peter Zijlstra , "linux-kernel@vger.kernel.org" , Ingo Molnar , Borislav Petkov , Thomas Gleixner , Guenter Roeck , Zach Reizner , regressions@leemhuis.info Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org And now with the correct email. Sorry about that, Tomeu On 16 November 2017 at 10:16, Tomeu Vizoso wrote: > Adding regression@leemhuis.info to CC so this regression is tracked. > > Regards, > > Tomeu > > On 8 November 2017 at 09:37, Tomeu Vizoso wrote: >> On 6 November 2017 at 23:01, 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 >>>>> Signed-off-by: Tom Lendacky >>>> >>>> >>>> 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