Message ID | 1683816877-10747-1-git-send-email-ssengar@linux.microsoft.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp4464220vqo; Thu, 11 May 2023 08:28:32 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6ef8JD+2NQvRgOv6ry194LOQnWSRT4H9WOy538ANZBcLuzZeZVRiPPp2A4vIc8O6xVfLdl X-Received: by 2002:a05:6a00:189a:b0:646:7234:cbfc with SMTP id x26-20020a056a00189a00b006467234cbfcmr18458182pfh.27.1683818912219; Thu, 11 May 2023 08:28:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683818912; cv=none; d=google.com; s=arc-20160816; b=jCmT9khjyPuzZXjl16eFQE2H3BU1En2fhypBpZBP/Wgejr9BAk/lheFXYf4Qqq54Ha x8tVgIomdKh8NL0p4LdYyf4Swrbt5ZW6k2Mm0Nes2CaDjaNPOIAclANAAMb53jaqS9xe G1T1OVHHv/Ev1alOxZO/iK9Ecvk3Gia4U/1kH9gmQDa6jQUMqXZyFWoz/g0aoZ3/OEyQ M3LTGbtYsVsnMNUeqGYWTLfwzefP8UBFz8KSZdXg1aAbnjL8CfhoXdLSr4z4R2QceKrl jNCp3u627MB91j+Y59N3zx6tPQgHF3r/adiVIffPn514vK283SR0gXfK2vDZqxQB01ei Y70w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature:dkim-filter; bh=yPkGjv6ed/fR0LYuHkAbjAvBuGZ9KC73Q4xkdpS6J4U=; b=KnE4MOP4WxQ5kgRhsX46TL+u9rbjnkt5FawU77epq/8a9QsReo2rE77E7JDjznhdHV XTW+XQtkiKP/7v7qPWD/69C7vb4q5qpjxUjIkoXdtQbmDtZnF4TxpEFOENe+gT9zj6cF kz1Fk3+WVxz4ll7KR+ac2GuLSzWtWk9iiE5x0X5095fJvdo1GWKbv8zfUHkIttzrc/zk +A5uYvBnwXAxqX7wD8vITlFz3j729M69EYCqePl5/EFQhqPdrHO7r9VLoM+TC/lllZVV c5DJEEI15QCtSOBcWHKXs3yziVA38fQX4E+Mc1qXBvpv0ol2h/Uv/oGLPSUh5ssB7VbT J3Pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=IYosbuCT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z23-20020a63b917000000b0050aea0375afsi6849323pge.765.2023.05.11.08.28.19; Thu, 11 May 2023 08:28:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=IYosbuCT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238387AbjEKPJE (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Thu, 11 May 2023 11:09:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237939AbjEKPJC (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 11 May 2023 11:09:02 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6B1EF3A8C; Thu, 11 May 2023 08:08:52 -0700 (PDT) Received: from linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net (linux.microsoft.com [13.77.154.182]) by linux.microsoft.com (Postfix) with ESMTPSA id 8601420EAB68; Thu, 11 May 2023 07:55:00 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8601420EAB68 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1683816900; bh=yPkGjv6ed/fR0LYuHkAbjAvBuGZ9KC73Q4xkdpS6J4U=; h=From:To:Cc:Subject:Date:From; b=IYosbuCT9JurD1ivRhMVFDjjzAm+9Jv3zwmDhlxO8ZRT90nvglRA9mq9h30SDo0KW x6LGTDoHVEx/Ex4ba/KEGMEWN9HIZ7Hw96e5RTStfVltZR2Y1BKOGfw8yQXadopSXe N/Npk2vxZBUw/dLbex5bsDGzdHqQ0ZVmnwaMatuc= From: Saurabh Sengar <ssengar@linux.microsoft.com> To: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, mikelley@microsoft.com, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org Cc: ssengar@microsoft.com Subject: [PATCH 1/2] x86/Kconfig: Allow CONFIG_X86_MPPARSE disable for OF platforms Date: Thu, 11 May 2023 07:54:36 -0700 Message-Id: <1683816877-10747-1-git-send-email-ssengar@linux.microsoft.com> X-Mailer: git-send-email 1.8.3.1 X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765612099232793595?= X-GMAIL-MSGID: =?utf-8?q?1765612099232793595?= |
Series |
[1/2] x86/Kconfig: Allow CONFIG_X86_MPPARSE disable for OF platforms
|
|
Commit Message
Saurabh Singh Sengar
May 11, 2023, 2:54 p.m. UTC
X86_MPPARSE is only selectable when ACPI is enabled. However,
on Devicetree platforms where ACPI is disabled, it is always
enabled. Allow X86_MPPARSE to be selected by OF platforms as
well.
Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
From: Saurabh Sengar <ssengar@linux.microsoft.com> Sent: Thursday, May 11, 2023 7:55 AM > > X86_MPPARSE is only selectable when ACPI is enabled. However, > on Devicetree platforms where ACPI is disabled, it is always > enabled. Allow X86_MPPARSE to be selected by OF platforms as > well. > > Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> > --- > arch/x86/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 53bab123a8ee..e60315397399 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -469,7 +469,7 @@ config X86_X2APIC > If you don't know what to do here, say N. > > config X86_MPPARSE > - bool "Enable MPS table" if ACPI > + bool "Enable MPS table" if ACPI || OF > default y > depends on X86_LOCAL_APIC > help > -- > 2.34.1 Reviewed-by: Michael Kelley <mikelley@microsoft.com>
On 5/11/23 07:54, Saurabh Sengar wrote: > X86_MPPARSE is only selectable when ACPI is enabled. However, > on Devicetree platforms where ACPI is disabled, it is always > enabled. Allow X86_MPPARSE to be selected by OF platforms as > well. I'm finding this changelog really hard to read. In Kconfig, you can "select FOO". But in this changelog, it means something different. I think "selectable" here means that there's a user prompt for the option. Could you please rephrase this to be less confusing? This is also one of those patches where I wonder: Why do _you_ care about this? Are you just trying to be nice? Is this intended as some kind of cleanup?
> -----Original Message----- > From: Dave Hansen <dave.hansen@intel.com> > Sent: Tuesday, May 23, 2023 11:23 PM > To: Saurabh Sengar <ssengar@linux.microsoft.com>; tglx@linutronix.de; > mingo@redhat.com; bp@alien8.de; dave.hansen@linux.intel.com; > x86@kernel.org; hpa@zytor.com; KY Srinivasan <kys@microsoft.com>; > Haiyang Zhang <haiyangz@microsoft.com>; wei.liu@kernel.org; Dexuan Cui > <decui@microsoft.com>; Michael Kelley (LINUX) <mikelley@microsoft.com>; > linux-kernel@vger.kernel.org; linux-hyperv@vger.kernel.org > Cc: Saurabh Singh Sengar <ssengar@microsoft.com> > Subject: [EXTERNAL] Re: [PATCH 1/2] x86/Kconfig: Allow > CONFIG_X86_MPPARSE disable for OF platforms > > On 5/11/23 07:54, Saurabh Sengar wrote: > > X86_MPPARSE is only selectable when ACPI is enabled. However, on > > Devicetree platforms where ACPI is disabled, it is always enabled. > > Allow X86_MPPARSE to be selected by OF platforms as well. > > I'm finding this changelog really hard to read. > > In Kconfig, you can "select FOO". But in this changelog, it means something > different. I think "selectable" here means that there's a user prompt for the > option. > > Could you please rephrase this to be less confusing? Thanks for your review. Currently, in the absence of ACPI, it is impossible to disable X86_MPPARSE. In the case of ACPI being enabled, one has the option to either enable or disable X86_MPARSE. My intention is to permit X86_MPPARSE=n for OF platforms where ACPI=n. To describe the capability of choosing any desired value for MPPARSE, I used the term 'selectable.' Perhaps 'configurable' would be a more appropriate word in this context? I can fix this and include it in V2. > > This is also one of those patches where I wonder: Why do _you_ care about > this? Are you just trying to be nice? Is this intended as some kind of cleanup? It solves an issue for Hyper-V VBS setup, please refer to the 2/2 of this patch series. Regards, Saurabh
On 5/24/23 09:23, Saurabh Singh Sengar wrote: >> Could you please rephrase this to be less confusing? > > Thanks for your review. Currently, in the absence of ACPI, it is impossible to > disable X86_MPPARSE. In the case of ACPI being enabled, one has the > option to either enable or disable X86_MPARSE. My intention is to permit > X86_MPPARSE=n for OF platforms where ACPI=n. To describe the capability > of choosing any desired value for MPPARSE, I used the term 'selectable.' > Perhaps 'configurable' would be a more appropriate word in this context? > I can fix this and include it in V2. OK, so this particular Hyper-V setup doesn't run normal normal distro kernels? It requires a very specialized kernel? Or it's just _better_ that the kernel is configured this way? >> This is also one of those patches where I wonder: Why do _you_ care about >> this? Are you just trying to be nice? Is this intended as some kind of cleanup? > > It solves an issue for Hyper-V VBS setup, please refer to the 2/2 of this patch > series. Heh, that changelog is even more confusing than _this_ one. It doesn't say that there's a problem, only that it removes "not required" code. I'm still confused by this whole thing.
> -----Original Message----- > From: Dave Hansen <dave.hansen@intel.com> > Sent: Wednesday, May 24, 2023 11:33 PM > To: Saurabh Singh Sengar <ssengar@microsoft.com>; Saurabh Sengar > <ssengar@linux.microsoft.com>; tglx@linutronix.de; mingo@redhat.com; > bp@alien8.de; dave.hansen@linux.intel.com; x86@kernel.org; > hpa@zytor.com; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang > <haiyangz@microsoft.com>; wei.liu@kernel.org; Dexuan Cui > <decui@microsoft.com>; Michael Kelley (LINUX) <mikelley@microsoft.com>; > linux-kernel@vger.kernel.org; linux-hyperv@vger.kernel.org > Subject: Re: [EXTERNAL] Re: [PATCH 1/2] x86/Kconfig: Allow > CONFIG_X86_MPPARSE disable for OF platforms > > On 5/24/23 09:23, Saurabh Singh Sengar wrote: > >> Could you please rephrase this to be less confusing? > > > > Thanks for your review. Currently, in the absence of ACPI, it is > > impossible to disable X86_MPPARSE. In the case of ACPI being enabled, > > one has the option to either enable or disable X86_MPARSE. My > > intention is to permit X86_MPPARSE=n for OF platforms where ACPI=n. To > > describe the capability of choosing any desired value for MPPARSE, I used > the term 'selectable.' > > Perhaps 'configurable' would be a more appropriate word in this context? > > I can fix this and include it in V2. > > OK, so this particular Hyper-V setup doesn't run normal normal distro > kernels? It requires a very specialized kernel? Or it's just _better_ that the > kernel is configured this way? This is a system where we provide isolation through VTL. More information About VTL is here: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/vsm#virtual-trust-level-vtl In the context of VTL0, the system runs the normal kernel. However, for higher VTLs, we enable the kernel with HYPERV_VTL_MODE. It's important to note that the lower memory of the system is not included in the higher VTLs It runs the normal kernel as part of VTL0 but for higher VTLs we run the kernel with HYPERV_VTL_MODE enable. VTL0 is assigned to lower memory of system, the lower memory not part of higher VTLs. However, MPARSE option disregard this and try to scan VTL0 memory which causes issue. This will enable any system which doesn't want lower memory to be scanned for MPPARSE for whatever reason. > > >> This is also one of those patches where I wonder: Why do _you_ care > >> about this? Are you just trying to be nice? Is this intended as some kind of > cleanup? > > > > It solves an issue for Hyper-V VBS setup, please refer to the 2/2 of > > this patch series. > > Heh, that changelog is even more confusing than _this_ one. It doesn't say > that there's a problem, only that it removes "not required" code. > > I'm still confused by this whole thing. I agree the commit message could be better. And I commented below in that thread to clarify. Hope it clarifies, please let me know if any more information is required: When CONFIG_X86_MPPARSE is enabled, the kernel will scan low memory, looking for MP tables. In Hyper-V VBS setup, lower memory is assigned to VTL0. This lower memory may contain the actual MPPARSE table for VTL0, which can confuse the VTLx kernel and cause issues. (x > 0)
On 5/25/23 00:06, Saurabh Singh Sengar wrote: > When CONFIG_X86_MPPARSE is enabled, the kernel will scan low memory, > looking for MP tables. In Hyper-V VBS setup, lower memory is assigned to VTL0. > This lower memory may contain the actual MPPARSE table for VTL0, > which can confuse the VTLx kernel and cause issues. (x > 0) This still just seems wrong. If an action crashes the kernel because of changes, we don't just compile it out and move on. We add enumeration for the new feature that's causing it and turn off the action at runtime.
> -----Original Message----- > From: Dave Hansen <dave.hansen@intel.com> > Sent: Thursday, May 25, 2023 7:26 PM > To: Saurabh Singh Sengar <ssengar@microsoft.com>; Saurabh Sengar > <ssengar@linux.microsoft.com>; tglx@linutronix.de; mingo@redhat.com; > bp@alien8.de; dave.hansen@linux.intel.com; x86@kernel.org; > hpa@zytor.com; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang > <haiyangz@microsoft.com>; wei.liu@kernel.org; Dexuan Cui > <decui@microsoft.com>; Michael Kelley (LINUX) <mikelley@microsoft.com>; > linux-kernel@vger.kernel.org; linux-hyperv@vger.kernel.org > Subject: Re: [EXTERNAL] Re: [PATCH 1/2] x86/Kconfig: Allow > CONFIG_X86_MPPARSE disable for OF platforms > > On 5/25/23 00:06, Saurabh Singh Sengar wrote: > > When CONFIG_X86_MPPARSE is enabled, the kernel will scan low memory, > > looking for MP tables. In Hyper-V VBS setup, lower memory is assigned to > VTL0. > > This lower memory may contain the actual MPPARSE table for VTL0, which > > can confuse the VTLx kernel and cause issues. (x > 0) > > This still just seems wrong. > > If an action crashes the kernel because of changes, we don't just compile it > out and move on. We add enumeration for the new feature that's causing it > and turn off the action at runtime. > Thanks, I greatly appreciate your suggestion and wanted to let you know that I am actively working on upstreaming the new fix for the VTL driver to bypass the need for the MP table scan. Furthermore, I would like to learn about the rationale behind disallowing the disablement of CONFIG_X86_MPPARSE when MP tables are not in use. Considering that we compile out the features we don't support, wouldn't it be acceptable to allow users to customize their configurations in this manner? Allowing the disablement of CONFIG_X86_MPPARSE would provide greater flexibility and efficiency for those who do not utilize MP tables.
On 6/2/23 05:22, Saurabh Singh Sengar wrote: > Furthermore, I would like to learn about the rationale behind disallowing the > disablement of CONFIG_X86_MPPARSE when MP tables are not in use. Considering > that we compile out the features we don't support, wouldn't it be acceptable to > allow users to customize their configurations in this manner? Allowing the > disablement of CONFIG_X86_MPPARSE would provide greater flexibility and > efficiency for those who do not utilize MP tables. If someone sent a patch, I'd certainly look and figure out what "flexibility" and "efficiency" it would provide. But, honestly, it would just just be noise if it doesn't solve an _actual_ problem. Would anyone care or notice the "flexibility" and "efficiency" it would provide?
> -----Original Message----- > From: Dave Hansen <dave.hansen@intel.com> > Sent: Friday, June 2, 2023 7:54 PM > To: Saurabh Singh Sengar <ssengar@microsoft.com>; Saurabh Sengar > <ssengar@linux.microsoft.com>; tglx@linutronix.de; mingo@redhat.com; > bp@alien8.de; dave.hansen@linux.intel.com; x86@kernel.org; > hpa@zytor.com; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang > <haiyangz@microsoft.com>; wei.liu@kernel.org; Dexuan Cui > <decui@microsoft.com>; Michael Kelley (LINUX) <mikelley@microsoft.com>; > linux-kernel@vger.kernel.org; linux-hyperv@vger.kernel.org > Subject: [EXTERNAL] Re: [PATCH 1/2] x86/Kconfig: Allow > CONFIG_X86_MPPARSE disable for OF platforms > > On 6/2/23 05:22, Saurabh Singh Sengar wrote: > > Furthermore, I would like to learn about the rationale behind > > disallowing the disablement of CONFIG_X86_MPPARSE when MP tables are > > not in use. Considering that we compile out the features we don't > > support, wouldn't it be acceptable to allow users to customize their > > configurations in this manner? Allowing the disablement of > > CONFIG_X86_MPPARSE would provide greater flexibility and efficiency for > those who do not utilize MP tables. > > If someone sent a patch, I'd certainly look and figure out what "flexibility" and > "efficiency" it would provide. But, honestly, it would just just be noise if it > doesn't solve an _actual_ problem. > > Would anyone care or notice the "flexibility" and "efficiency" it would > provide? After the new approach we have opted, I agree it's not blocking us from any functional problem. Although one of the things we are trying to achieve is the minimal kernel where we want to remove all the unnecessary options. Our system is not dependent MPPARSE and we just don't want this code in our minimal kernel, and this config option is preventing us from removing it. Also, in past kernel has provided this flexibility for other options, which made me think it is fine do it for OF as well. https://lkml.indiana.edu/hypermail/linux/kernel/1210.3/01987.html Happy to know your opinion and learn.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 53bab123a8ee..e60315397399 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -469,7 +469,7 @@ config X86_X2APIC If you don't know what to do here, say N. config X86_MPPARSE - bool "Enable MPS table" if ACPI + bool "Enable MPS table" if ACPI || OF default y depends on X86_LOCAL_APIC help