Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp4219484iog; Tue, 28 Jun 2022 11:24:06 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tWTJVpZvzGVL13rZvbOSi/36vN9QcuyPX9rq1FHQoGTvW8yZ004h6SewMcqodDnKAeNZXg X-Received: by 2002:a17:906:8301:b0:6e4:896d:59b1 with SMTP id j1-20020a170906830100b006e4896d59b1mr19221744ejx.396.1656440646776; Tue, 28 Jun 2022 11:24:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656440646; cv=none; d=google.com; s=arc-20160816; b=Ie6/oGVK6PhnsxLRHt+gthktfqwK6khkp2w/uUKFQyCWHz967QsLTjVEkrSsZjdm5+ fT0c9XzA9tHEBfCV2u8bcf0ya60lTajHs8EyJAkYCjZ5yZJ3BiJVjPJMjPCKE8GUYf4i ah5E+EJA2yxdM4mEfF8ERyG2K7kuIngmlOqxeWQjUKkWqH64CT1s6skLZ+qdqkv/VoDS ieks1mujvK9E9wIIwqeeXToDdcMM/x54yK17TghMf+6llZ7ORyTZmHfBRNyciRq8XB75 RQFWBNcQBPu59r/pIA2OiVlwZxKYphYJJk3ZK27+cJ5rW7OKsIKmr8wRKwP0aGSVVxmo CW4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=d/K3uK9czM2AfMF4jLStX27UoeGzElv+mW5P0Wyew2s=; b=gSLBxTMUS71Wm1hI9P63t87+Fk1vrtAss/TXFKHp3mWXqNt2SfujoZEVnUq+XNDo1O L6uNhOept3Mf7rE6IsMwoM/COo3th3I5M4FAZehMAbnBkgyCobnaQCeutqdqMXqoAKtu DBsFDK5L+jWZZFR/PnymRRldx7NXuqw4zsCwVXMK/2FoZE070N0CppYcFowBFJO9Qwpx BVsJuQyQZIOTv1gL5rlzM7ibNUPqELtYzNtfFznj2y772AKXJRQPY5PI4TX1vANX9w13 5pZLYl7RPtiu7IliJHO0G932zq42gi0Rv8ruh057S3CUWqFD7VNHItn+kelbdGFzI85T 3Beg== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sc9-20020a1709078a0900b006ff6c9f7081si17079519ejc.738.2022.06.28.11.23.41; Tue, 28 Jun 2022 11:24:06 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232985AbiF1Rze (ORCPT + 99 others); Tue, 28 Jun 2022 13:55:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232724AbiF1Rz3 (ORCPT ); Tue, 28 Jun 2022 13:55:29 -0400 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36E0EF0D; Tue, 28 Jun 2022 10:55:23 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id o19so16974547ybg.2; Tue, 28 Jun 2022 10:55:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d/K3uK9czM2AfMF4jLStX27UoeGzElv+mW5P0Wyew2s=; b=a6tmfx4RS91KbPPsEKSq9MW0EWhbaKIe3ABVmuLVOHMnw5Jd0uRfUzWpDX+Tc+RCvO mM/eniQBPGeoN7O5CkYMVxmpL3UCCSCjRWaE+aGC6I47spqtERjX5rLypUbXg1QU2NDz LcOkbYt8Q3cB9jd1JiBjCs5NEiBD5dHIuNsP6iSqxT8s653qO5/CReB9nRgMIzSCbtRx u6ty1V8R/lNApWK6rvqSKlezmPoByzVu3T1KnAC9awUVtErD/Sss7fd+mj/j7ZD+e6eK Qlm59GwN6W1NM1NuaQUH/4Kh68zWK7NRfn9GN4GQIjDnvc2NcitanpUNRLeyo+bz3D/F DJAw== X-Gm-Message-State: AJIora/NJ7UhrPgB9sB1FlLEbDIX6mfKhrkClu2JH8Kqvec1MJXeM+pe ZE44rpwPb7Xn+ue6VDevLakve6ZoIT2/ZfWjoYQW8EU3 X-Received: by 2002:a25:ae26:0:b0:66d:1fdc:263c with SMTP id a38-20020a25ae26000000b0066d1fdc263cmr6540314ybj.137.1656438922500; Tue, 28 Jun 2022 10:55:22 -0700 (PDT) MIME-Version: 1.0 References: <87dc19c47bad73509359c8e1e3a81d51d1681e4c.1655894131.git.kai.huang@intel.com> <198860d65d277dbd30552526a707576db4281b29.camel@intel.com> In-Reply-To: <198860d65d277dbd30552526a707576db4281b29.camel@intel.com> From: "Rafael J. Wysocki" Date: Tue, 28 Jun 2022 19:55:11 +0200 Message-ID: Subject: Re: [PATCH v5 03/22] cc_platform: Add new attribute to prevent ACPI memory hotplug To: Kai Huang Cc: "Rafael J. Wysocki" , Linux Kernel Mailing List , kvm-devel , ACPI Devel Maling List , Sean Christopherson , Paolo Bonzini , Dave Hansen , Len Brown , Tony Luck , Rafael Wysocki , Reinette Chatre , Dan Williams , Peter Zijlstra , Andi Kleen , "Kirill A. Shutemov" , Kuppuswamy Sathyanarayanan , isaku.yamahata@intel.com, Tom Lendacky Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 23, 2022 at 2:09 AM Kai Huang wrote: > > On Wed, 2022-06-22 at 13:45 +0200, Rafael J. Wysocki wrote: > > On Wed, Jun 22, 2022 at 1:16 PM Kai Huang wrote: > > > > > > Platforms with confidential computing technology may not support ACPI > > > memory hotplug when such technology is enabled by the BIOS. Examples > > > include Intel platforms which support Intel Trust Domain Extensions > > > (TDX). > > > > > > If the kernel ever receives ACPI memory hotplug event, it is likely a > > > BIOS bug. For ACPI memory hot-add, the kernel should speak out this is > > > a BIOS bug and reject the new memory. For hot-removal, for simplicity > > > just assume the kernel cannot continue to work normally, and just BUG(). > > > > > > Add a new attribute CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED to indicate the > > > platform doesn't support ACPI memory hotplug, so that kernel can handle > > > ACPI memory hotplug events for such platform. > > > > > > In acpi_memory_device_{add|remove}(), add early check against this > > > attribute and handle accordingly if it is set. > > > > > > Signed-off-by: Kai Huang > > > --- > > > drivers/acpi/acpi_memhotplug.c | 23 +++++++++++++++++++++++ > > > include/linux/cc_platform.h | 10 ++++++++++ > > > 2 files changed, 33 insertions(+) > > > > > > diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c > > > index 24f662d8bd39..94d6354ea453 100644 > > > --- a/drivers/acpi/acpi_memhotplug.c > > > +++ b/drivers/acpi/acpi_memhotplug.c > > > @@ -15,6 +15,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "internal.h" > > > > > > @@ -291,6 +292,17 @@ static int acpi_memory_device_add(struct acpi_device *device, > > > if (!device) > > > return -EINVAL; > > > > > > + /* > > > + * If the confidential computing platform doesn't support ACPI > > > + * memory hotplug, the BIOS should never deliver such event to > > > + * the kernel. Report ACPI CPU hot-add as a BIOS bug and ignore > > > + * the memory device. > > > + */ > > > + if (cc_platform_has(CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED)) { > > > > Same comment as for the acpi_processor driver: this will affect the > > initialization too and it would be cleaner to reset the > > .hotplug.enabled flag of the scan handler. > > > > > > Hi Rafael, > > Thanks for review. The same to the ACPI CPU hotplug handling, this is illegal > also during kernel boot. What do you mean? Is it not correct to enumerate any memory device through ACPI at all? > If we just want to disable, then perhaps something like below? > > --- a/drivers/acpi/acpi_memhotplug.c > +++ b/drivers/acpi/acpi_memhotplug.c > @@ -366,6 +366,9 @@ static bool __initdata acpi_no_memhotplug; > > void __init acpi_memory_hotplug_init(void) > { > + if (cc_platform_has(CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED)) > + acpi_no_memhotplug = true; > + This looks fine to me if the above is the case, but you need to modify the changelog to match. > if (acpi_no_memhotplug) { > memory_device_handler.attach = NULL; > acpi_scan_add_handler(&memory_device_handler); > > > --