From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 493A1C43334 for ; Fri, 24 Jun 2022 11:23:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96A278E0212; Fri, 24 Jun 2022 07:23:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FC6F8E020E; Fri, 24 Jun 2022 07:23:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 792E28E0212; Fri, 24 Jun 2022 07:23:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 674D08E020E for ; Fri, 24 Jun 2022 07:23:31 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 3674080685 for ; Fri, 24 Jun 2022 11:23:31 +0000 (UTC) X-FDA: 79612893822.31.E6236E2 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf22.hostedemail.com (Postfix) with ESMTP id 398AEC0007 for ; Fri, 24 Jun 2022 11:23:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656069810; x=1687605810; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=xgjsDnXlP1t2rfiijqMLMBJUg2+1poD5XRUpahbyPQg=; b=cujlbKO975237eI3UyGeHjJsSKfKa/GetUvhZyGy3J181jTQASMJcwVO I/SIzrppaCe31eMzLlDKcbafGB5mYoFylhtKRTdzcBteirATxuXBuIchv 1eiUM6kN6ICuEN38eCt3ovfg9oGihlcXIixpJc/ltOl4LEwWPZBSufjcj bzR0nOqsbKVLVy1mokIpfYoigpoSDRAJq1eCqqdq2/7a5Z7uh5coh+EV5 a4jujntw2wFREp/i8Rt4RdFHLeqpk4LGr4Sx+pcrxZn+9mOxrVApPKfoS SBnMNgNus8/nFDr8MYWP8PNifXw3Xm+NMJNYzv8LvH0XnpLnc5BclN+lz w==; X-IronPort-AV: E=McAfee;i="6400,9594,10387"; a="306447032" X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="306447032" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2022 04:23:18 -0700 X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="915645909" Received: from jvrobert-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.212.99.67]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2022 04:23:15 -0700 Message-ID: <97945fb19901f6ec11c72b015f55f6bb42cbc7c1.camel@intel.com> Subject: Re: [PATCH v5 05/22] x86/virt/tdx: Prevent hot-add driver managed memory From: Kai Huang To: Chao Gao Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, seanjc@google.com, pbonzini@redhat.com, dave.hansen@intel.com, len.brown@intel.com, tony.luck@intel.com, rafael.j.wysocki@intel.com, reinette.chatre@intel.com, dan.j.williams@intel.com, peterz@infradead.org, ak@linux.intel.com, kirill.shutemov@linux.intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, isaku.yamahata@intel.com, akpm@linux-foundation.org Date: Fri, 24 Jun 2022 23:23:13 +1200 In-Reply-To: <20220624021200.GB15566@gao-cwp> References: <173e1f9b2348f29e5f7d939855b8dd98625bcb35.1655894131.git.kai.huang@intel.com> <20220624021200.GB15566@gao-cwp> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.2 (3.44.2-1.fc36) MIME-Version: 1.0 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656069810; a=rsa-sha256; cv=none; b=wqIe7pxE3RdyiH9/9noRsRTMk3L3hw6pYdr+gD6IpCozS1HdvJs2t6EAMk4aayofNfOFZC YoLQnoOwQBouG4X9wDdQlZTDswUmAy/9Y5dxvmYMoZjhZvFI4dmGMaJTPcSKKAI3bTKcEk 3gTLYjxlASMTYs4Vfo5X1llB/d7Vc1o= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cujlbKO9; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of kai.huang@intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kai.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656069810; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LRpwuBNZIIGQ3mW9b7ZiJcvyU5iccsQNL+ADaLEZ2yQ=; b=6DLD4dj2NI3IdJkQ3SlymSwAV6erzE+mWdrshGmBx+gjkwjruLbkioL18oQn71of2vYhY8 UAY/bxGlzFQq+VKYS1wt53DjwFRHMlOyD5jwy6bs7IkAhifVfLHhUipa3PNhuw5xUFToAX LRMr8mmo7C0cSc2O092j9GTljvvTpTE= X-Stat-Signature: eu4jesj9zw4cw76xtm1su9gj6t8uedx7 X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 398AEC0007 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cujlbKO9; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of kai.huang@intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kai.huang@intel.com X-HE-Tag: 1656069809-667238 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 2022-06-24 at 10:12 +0800, Chao Gao wrote: > On Wed, Jun 22, 2022 at 11:16:19PM +1200, Kai Huang wrote: > > @@ -55,6 +55,7 @@ > > #include > > #include > > #include > > +#include > >=20 > > #include "mm_internal.h" > >=20 > > @@ -972,6 +973,26 @@ int arch_add_memory(int nid, u64 start, u64 size, > > return add_pages(nid, start_pfn, nr_pages, params); > > } > >=20 > > +int arch_memory_add_precheck(int nid, u64 start, u64 size, mhp_t mhp_f= lags) > > +{ > > + if (!platform_tdx_enabled()) > > + return 0; >=20 > add a new cc attribute (if existing ones don't fit) for TDX host platform= and > check the attribute here. So that the code here can be reused by other cc > platforms if they have the same requirement. Please see my explanation in the commit message: The __weak arch-specific hook is used instead of a new CC_ATTR similar to disable software CPU hotplug. It is because some driver managed memory resources may actually be TDX-capable (such as legacy PMEM, which is underneath indeed RAM), and the arch-specific hook can be further enhanced to allow those when needed. --=20 Thanks, -Kai