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 5F1EAEB64DD for ; Thu, 29 Jun 2023 00:32:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEB938D0005; Wed, 28 Jun 2023 20:32:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E746B8D0001; Wed, 28 Jun 2023 20:32:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D15F78D0005; Wed, 28 Jun 2023 20:32:16 -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 BFB8C8D0001 for ; Wed, 28 Jun 2023 20:32:16 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9D07B120356 for ; Thu, 29 Jun 2023 00:32:16 +0000 (UTC) X-FDA: 80953908672.13.2B29611 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf22.hostedemail.com (Postfix) with ESMTP id 70CC6C0012 for ; Thu, 29 Jun 2023 00:32:14 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LRvVsd0R; spf=pass (imf22.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.65 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=1687998734; 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=Fk8LHel2FaQC480M0ZAORNBVqXT2ke43gC5IFGWWjGA=; b=gMxo0qKj30ybVu7EwAoYqmhD5cgtT44I0fMA28pWJANhvvSU3+F17+RCyWUf+vKLoAH0vm dgVWNWuhzpiVxDb4Mds5LdjmmxqHflg2O9JVJJ0YGgKPZcozh+mYTX/WgCq3wSpt/xEIpo CqNc5kVusf8LbueZgyTqV5mrC+L/16s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687998734; a=rsa-sha256; cv=none; b=7pZi4DDabyegzlhS5VUsTwE98WYybgL1AVT4Wk0owx0j9ZG/3b+8qty0a5ufr1CAHRvr7Y EPCywcJoIxFFEUCmUdOgjo+z/PRrBDO9ExDJIQ/IZSZb9KbCR46zoWRfhPiGFvvUnCJ2Vp NOPlAsWyUI3MxYpC7hgDNqJW4ZA9Vds= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LRvVsd0R; spf=pass (imf22.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.65 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=1687998734; x=1719534734; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=sqRArJ9svcYk8Srvkb99FaaP4ltBUPw0xtk0ZlIVfjk=; b=LRvVsd0RdlPk7BXPL9GcUuxJQPSlpOP3fxRrcBF13mFUqCtm3LdVArkS Dhjcj6POL6UcuBgfiC61rArEeZ1yAfl0Ec45MnEgrDM2M70NHYLicdAoW FR11iwozF7CSVfMbcFq3Nb8Afh3AGzUeFU36r28SsTJUTuWfIdubBXBMc gN2ObrwOnLg5gS8MFZJ+keGLh5Z4QWcgEmQL+cbd6kzCSYCOERTWDO5Zd 8s9DoqgmPLwhxIyLjDsvDAl/9wjG7oEMoGF+K4ata7ZO394sg6VAulcHa QyA/a+WpoZOGdFMbYloW2kqbyMtzI7VsYnWn/0fRbZT0azMAuvrZgkQW+ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10755"; a="365455151" X-IronPort-AV: E=Sophos;i="6.01,166,1684825200"; d="scan'208";a="365455151" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2023 17:32:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10755"; a="891226114" X-IronPort-AV: E=Sophos;i="6.01,166,1684825200"; d="scan'208";a="891226114" Received: from adamha2x-mobl.amr.corp.intel.com (HELO [10.209.108.95]) ([10.209.108.95]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2023 17:32:12 -0700 Message-ID: Date: Wed, 28 Jun 2023 17:32:13 -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 v12 19/22] x86/kexec(): Reset TDX private memory on platforms with TDX erratum Content-Language: en-US To: Nikolay Borisov , Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: linux-mm@kvack.org, x86@kernel.org, kirill.shutemov@linux.intel.com, tony.luck@intel.com, peterz@infradead.org, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, david@redhat.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, ashok.raj@intel.com, reinette.chatre@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com References: <28aece770321e307d58df77eddee2d3fa851d15a.1687784645.git.kai.huang@intel.com> <1662a5ef-c333-d6d6-7605-060f4bcca6fd@suse.com> From: Dave Hansen In-Reply-To: <1662a5ef-c333-d6d6-7605-060f4bcca6fd@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: 56gsuo5r17giy59s381yuhuftajf336j X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 70CC6C0012 X-Rspam-User: X-HE-Tag: 1687998734-184505 X-HE-Meta: U2FsdGVkX19g+w9wKY8kcCFqrmmtkqBFZRRRASIC6HDgyhD1ho8Ri7/dktSq8Nj+YEklTXUa8JWuP3sFDCoFYWPXLquE0B7wmp8cRbmZExgTYAAhhUhNpRG1jRDuYapY+PUQhJhXqCymTulKEzarLeIb2Broyg117LH3zZ0Bmg8c1UHMSDxekx11fugqFl2MrAMwJA/JDILlpAbZoQYVsglhXYZEB6Ft6zMVToibnzOWF7olNajZIy79I8VlzSizpckQNtwHgH92fDYtLbXxxyhUY424goTFhuq5ZsoateGougsDc4g8IjNjlLQsY83Djutc+oShsDRybFexswtJz8Hfi3lGAqaMfuKRSAJZi4gzfz7zxS8KmKSUI+nl8qj8OJ7IbFa03QMjhN+zmTq/KUKqlLRPKSb2sk+r2o+cHaASp6otPZnX5Vdd1T9AXk4oPOZJFznahtbCrWimgQhpZadUO1lwjYRmTNt+BrtQwituGTMLXlH2jq7Aiyqvv99VOtcWM0IOH85SDjaC8kxU5RmqCcS4mxMDPL4mXtAoQw6s52yMI0UxzafBfmkuaiX782W+EhGNh9vKLYbTQybGxo4er8JV3ngQ9r8h43JBl14FF8tSIA8GxfvHneMUnUibEQ1I3zV4iIpkzQnwcUussC1VBo82lW/KeAFcyIDZlSHe3Ni+X2VFc0LGz2cqgDGLcg4HVCMD8Z4EMlBFv13mtAK0k/OaNvNmv51rNNxYxKcivEx5KvtFy382wQ2yOfqFWcdr5auUEw1V1zDPSWH6d30G9ogpCIz0Tc80s758eFCWXZWCrTF9q9PdmgsEvmcXXxdQXoZb+Tw8bIF03IWygenHA9i29CLhPEgkhnoAK3sO0MLwgoqoNTtL/JKvtN2ahUV6xwLbg4XdI0N+TBvz9KWh8oV6vF7+r+F/HHiY+WJwI1zwGIbZmA/L+ThCJO7L5Hovprl8CKozJxQ+Y3n y/TKO/qz bri1Ut9iZNHG8eks62wHex+yVfMFwNqlJ9dxkTA+F0dywwKdgLHVH669ZalVVHXxAjW1lVG+rPEr/cEXA1foU+RvI+hwuJLmUPaOMTW0AlrZJ0F9jEjpQnwvk0svUkcJoG4yKVOhBRutJ2XTcekpDX06JWA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000045, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/28/23 02:20, Nikolay Borisov wrote: >> >>   +    /* >> +     * Starting from this point the system may have TDX private >> +     * memory.  Make it globally visible so tdx_reset_memory() only >> +     * reads TDMRs/PAMTs when they are stable. >> +     * >> +     * Note using atomic_inc_return() to provide the explicit memory >> +     * ordering isn't mandatory here as the WBINVD above already >> +     * does that.  Compiler barrier isn't needed here either. >> +     */ > > If it's not needed, then why use it? Simply do atomic_inc() and instead > rephrase the comment to state what are the ordering guarantees and how > they are achieved (i.e by using wbinvd above). Even better, explain why the barrier needs to be there and *IGNORE* the WBVIND. If the WBINVD gets moved -- or if the gods ever bless us with a halfway reasonable way to flush the caches that's not full serializing -- this code is screwed. There is _zero_ reason to try and "optimize" this junk by trying to get rid of a memory barrier at the risk of screwing it over later. I use "optimize" in quotes because that's a highly charitable way of describing this activity.