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 74FA4C88CB4 for ; Mon, 12 Jun 2023 13:47:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C61A86B0072; Mon, 12 Jun 2023 09:47:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C119D6B0074; Mon, 12 Jun 2023 09:47:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB3046B0075; Mon, 12 Jun 2023 09:47:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9776B6B0072 for ; Mon, 12 Jun 2023 09:47:15 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 667C08020D for ; Mon, 12 Jun 2023 13:47:15 +0000 (UTC) X-FDA: 80894222430.26.8317618 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf20.hostedemail.com (Postfix) with ESMTP id 681171C000E for ; Mon, 12 Jun 2023 13:47:11 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=X0w3UgYe; spf=pass (imf20.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686577633; 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=IgMyd5+6M9vF8aXgLk1uxdBl7HmJg3EvZq/DLebXEbQ=; b=IxMBOkm+VthZR1BISM5KoF6cy0otZoxWNdSY+JIUXWAD1dih3nnRSo/PI7e3mSYKwISyYm E1PuLkGsQ5lc3iwULt+vI9QIqV2qdCmndGLmc+hNbswlLm/lMX0tzFgsomzlZhNVexaVuM GofEt8h+r+++poYNpADqxeWe2LnJQys= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686577633; a=rsa-sha256; cv=none; b=N+S8fLV/BbFpHJQoCvvONOwpab6KG8Xk4fOI0M65dxOpm4rrUYvxaUEKWVyndO7DcfIH0b zb+oPRjbAdYKbK5PVTmGY+t96lrQw49EY9ut6Hp3IUlS6RDVPGe5kCm46HnW8l84gHM4DX IIVGX01ooXodx3tvKRFDzqMXqMEcVlM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=X0w3UgYe; spf=pass (imf20.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686577632; x=1718113632; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=tEEMAOv5y1FNh96KVITEe1drEbJjSixD47uAg1phk68=; b=X0w3UgYenf0/1NnHG/dt1BECONOEFZFbrfg2YLEgcr5h8T34We7JVsJN 1J86GIgriErgDNMOacFkONj2quP1o33lujoYC9gNsXb6/r9iN5lvHiPlp oPwPrmU/U16zlK1Hpb4GC23phCqtQAEHmU2LUyYfIUmy2aVARLwA+KJhD Z8Y94P82XFhQ4FgtrP09ebENls7cf2LGy91CbG8XZ1I6fhlQFTImOzK3n EqKuF8QXurOupIonl4bRW3Qu3llBV6bDVzG3NC67rzRSqtwZT9tIWau7q VaV4FbeHnpG67xojeDDIj+e4gFzBav1i2o7xNxeewMTyNRWGvwUXiu+A+ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="358035647" X-IronPort-AV: E=Sophos;i="6.00,236,1681196400"; d="scan'208";a="358035647" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2023 06:47:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="705388478" X-IronPort-AV: E=Sophos;i="6.00,236,1681196400"; d="scan'208";a="705388478" Received: from spmantha-mobl1.amr.corp.intel.com (HELO [10.209.43.2]) ([10.209.43.2]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2023 06:47:08 -0700 Message-ID: <48d5a29a-878c-665d-6ac2-6f0563bf6f3c@intel.com> Date: Mon, 12 Jun 2023 06:47:08 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v11 18/20] x86: Handle TDX erratum to reset TDX private memory during kexec() and reboot Content-Language: en-US To: "Huang, Kai" , "kirill.shutemov@linux.intel.com" Cc: "kvm@vger.kernel.org" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "Luck, Tony" , "Chatre, Reinette" , "Christopherson,, Sean" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "Yamahata, Isaku" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "Shahar, Sagi" , "peterz@infradead.org" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <5aa7506d4fedbf625e3fe8ceeb88af3be1ce97ea.1685887183.git.kai.huang@intel.com> <20230609132301.uvvp27yr5kpenl6f@box.shutemov.name> <58f34b4b81b6d6b37d3386dec0f073e6eb7a97ff.camel@intel.com> <20230612075830.jbrdd6ysz4qq7wdf@box.shutemov.name> <4c7effc3abe71aa1cbee41f3bd46b97aed40be26.camel@intel.com> From: Dave Hansen In-Reply-To: <4c7effc3abe71aa1cbee41f3bd46b97aed40be26.camel@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 681171C000E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: mpoic5iryggztceh5xinydagwxana5z6 X-HE-Tag: 1686577631-864957 X-HE-Meta: U2FsdGVkX19s3QbAFK0/6DjupYobMZmz+Jh+QG8QVCCnq3SgkZMFRoEo98V6GNM/xD8dCvD2+cYLjqK7YlqLmyFHhYGrzMyroaOI16wp0nPBoGeRh/U76753c/zVcFY+z8zTXJYnE8G2EBarwQL0bHTFn6ou70a57/101Y3DuwIWPT4M6SHj4xkAUEXFdse2MHq2vVJhL8mPmDbe55vm7aFzMsNrRsHg1OfceOOClxSHh9iyqRpKKYhVu1UQDj97dLRf7zda/eMLNMO647PzR2XiKfmOpDiD39y2uvs25ZBwUUgS5VrNZrrHVTU0VvbgQyg2m1hEcSYpSueWa083BDbxNEgIIeNm/Xw6V3T8Kkuy/+CYi9FahqaXgZsxhgMFSiVJrKLIBpeoOUgd+mcrdNDNo87SUSIYbfqcBXXl5ycubnxwPKDAt+It5v0OHKH8exuOZ0domKSWEF0eToaEiJo8idveVqEMUVQc+PDCPs+jR1OPNzUY+dG1gHv/3+DlfEzaXn3n5PnraZXxqpeBRPpku7byZ742UJXnbB7Ov0q3f4dtqvmr7lo9pvzXckJfG8VkZ4WJTjlzxcztq0KMrzsvJi0UX8BYN/rrsQsRpxuXbxWLCC306+dzrrmexSfDGbsUNiSyUpV67SL5LRHO0MzabvcrMGOW3fNwnTCIuOPLEyh3DAwFCpmbcsoW0jdJRbXe2Li5jYi38l1gqnOpqAeov4ldWEAm2UznoxF8pmB2XvczD7JTcAB6qRY9Z+7URrLIHUh69hPvSY89apwKbr5m6fZbf5nSua3PAxp0IF8JNvmIbnXxcoAgo15RYoW22Zf9T7BMeBpn28+zrPD1sUOzSA92aroDrWtJESjfFwA6aPPwI1VkK9TfjAq8yrVBF8SWAe6WXyClDzVMr+zAkiNm4opOFCxUik+sry7HLkERSHtYZbSie+U7DtoFEO6ryBfGZLFMqd3QlAcOJBX VQvI8cTj w9nyisYF/10VLRoHZ4sKdsdprjVHSCZQcMZbPXx8S3VKET2D7BVWaJ5qt2OdgzZEKjW1rL3/VIdBmJaoBVhXinO3J2HkhyRI+9WZ8Rn05O48naRuNWXYB6fmEZ73GObV5pzt5gXmJ1LLhpTOcGKQ0fz76Gw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/12/23 03:27, Huang, Kai wrote: > So I think a __mb() after setting tdmr->pamt_4k_base should be good enough, as > it guarantees when setting to any pamt_*_size happens, the valid pamt_4k_base > will be seen by other cpus. > > Does it make sense? Just use a normal old atomic_t or set_bit()/test_bit(). They have built-in memory barriers are are less likely to get botched.