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 BA3B8EB64D9 for ; Mon, 19 Jun 2023 14:47:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 06E7A8D0002; Mon, 19 Jun 2023 10:47:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3A018D0001; Mon, 19 Jun 2023 10:47:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDA8E8D0002; Mon, 19 Jun 2023 10:47:04 -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 CB4248D0001 for ; Mon, 19 Jun 2023 10:47:04 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 61CAD806D6 for ; Mon, 19 Jun 2023 14:47:04 +0000 (UTC) X-FDA: 80919774768.10.9AE37B7 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf13.hostedemail.com (Postfix) with ESMTP id B07BC2000A for ; Mon, 19 Jun 2023 14:47:01 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dSEty4mV; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf13.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687186022; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4HbDDf6TPQQQAR2+0OOBRpURVfLkYfBnxg6v9jaK87g=; b=BWy5LUIw7SE1699iqrNd+bOBWmD305uaMwM+/OeLngRJcnf+MFgUin9vetv51SStOAFYl7 XvOYVfchUqo/I0RJxz5NU3Lvl0nUAbNdzROCm34HIXJyC8MQw+HyfWrk2QwzNumF32Xfkx FlXpbXY3tW+vVKHuvuSu/s0n6DI83Tk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dSEty4mV; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf13.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687186022; a=rsa-sha256; cv=none; b=gnUCiMRoGR1PkuhAq3PllDTbFX7noSl2TTzqprIitrphKCLoxwoX0dOWbVyKss0h22ANpb tPMqmXTIJ8os49Q2Urc2jKhGSBMoTg1LRhfltRN1A3IyaTlQtd0Z2Z9NTzZesUMdmyp70M QOtErgwSMYCBrEL8bFr3kAIKJ94fY2U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687186021; x=1718722021; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=vSIDsXoHgFk3LG2nLDWLfukEJ6ybqcavLSChFuxh5cU=; b=dSEty4mVo1fiWQwulZv33iwMH5gEXhOTo6MM38qZVd7dICoFOI2CxbnI PHR7MtCH565Ek8qyM9gf61I2BeRGE9oCz6JE4DmhtlhbgjyWWOyD//x2t hS6V/TLADnNWR10Q48iglPbh/h+vjTvZLkXztg9p1HyxpLw396p3v7xVq bGlVY7VL/Muw5VADOkDOKThCekM4eKtfJlJ3o6LG3wPdUjtvKKC7bD9yU dOlyBlV2EEMlkw++ly7ErlNcViCxrc0Z9Bufb7rKIYrWYidoI/ugdkhMT /+Vh7PrVDHqBaWITom3dP52utclkUNsiipXqtJb6Ev7I5DEaqAwNo1k94 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10746"; a="362185570" X-IronPort-AV: E=Sophos;i="6.00,254,1681196400"; d="scan'208";a="362185570" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2023 07:46:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10746"; a="779065687" X-IronPort-AV: E=Sophos;i="6.00,254,1681196400"; d="scan'208";a="779065687" Received: from leitchrx-mobl1.ger.corp.intel.com (HELO box.shutemov.name) ([10.249.45.32]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2023 07:46:54 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 905A810DD6D; Mon, 19 Jun 2023 17:46:51 +0300 (+03) Date: Mon, 19 Jun 2023 17:46:51 +0300 From: "kirill.shutemov@linux.intel.com" To: Dave Hansen Cc: "Huang, Kai" , "kvm@vger.kernel.org" , "Luck, Tony" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "linux-kernel@vger.kernel.org" , "Chatre, Reinette" , "Christopherson,, Sean" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" Subject: Re: [PATCH v11 18/20] x86: Handle TDX erratum to reset TDX private memory during kexec() and reboot Message-ID: <20230619144651.kvmscndienyfr3my@box.shutemov.name> 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> <48d5a29a-878c-665d-6ac2-6f0563bf6f3c@intel.com> <5782c8c2bb3e76a802e4a81c553a21edbaee7c47.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B07BC2000A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: i39ucp3g6w5atopwjguem8176kwonu1z X-HE-Tag: 1687186021-840295 X-HE-Meta: U2FsdGVkX19uSURkGDVBB7QxBoA/EQZcPlelAOolFcvUvqrvpfoEYJKm0/0zkb5r4bkWKeURE6XluJw8LxR0QtkvLDaKRRgEphg8z/IXTk3H90uURqRSwYDbeHFI1JY7J0bSAA5n67Wf7WN1DrtwshRJcoGfSUBoUN+bOlOpgA/kRsgLFUeHe0Mdp1MSuICrxbYRP26lbZ1AD93gR2G+DYn0ymEuL4bA4Ne/3g8LW8J3Vmj1jb5z6lGQi/efjDPzjNHifI49EAr1Cs+Pn4rKwtFYmmEDB9isACxRtg8ztBfONdYSnzNBbtiX1JxUgBS+ZC1Hf/S2Vc+wjIrFPmO7zFCfJqXtMlSCwT7/YS9Kcpv2y6c9Z4QnkGXnF4pGSwAcgf4cTyCpAM2PgNToqWG7HlLW+UxVRGhyioosvLR4WtAQVWGmvlPkuIu5tI07TWFRWQ3+qW+kZdrGhu2Vl67OqDbCXAgFuj8XTOyTI7mZhgwuPxSUvvgoEVmmv2lCQHSwbgbjHIYLyHWTtsxx/4i6D175SchY9BhUAWVvvDc37cLWRLfIZVqzYvn34yZX6X3cUqo+QrclqJoV9p1R7FFOIqhlahDs5KRmTcD8H10lQWs5df4+CH1LDc1WYH6TcLt8gquSz8dMof+1UYYPKBRhfscyjhZPLlPf/YlGPlbfYDuvsTTfeNJV3PcPIR1GbZSOCjiJc28tGkYe6dC/92OUwbJt/QUUS/fJ2Xt8bixcV4LaMaUmmueHVc/55tGFVNuoQsxI5xA8bA3BLkLjIW4peKl2AnV/UzFexXzFbCW1vkFlB3PV4Ng0VMSmoN7xSX12iF1Vbrn/tm8mJJf6GW9TPcKb+tJExQSMKbBeL1du2+iW5YdTELSx5VlEhT+rCN1qnekxpjBXO0bOoJPpg00coI4eLutg0GrDEAHcmYrT5J1V/F93f9rCxDm6VpvgcV/bnpUc+Jqv87Z/e1XwOLR jAwSVOwl 86DvpPdys/izD2c7Mod/8SzSFiRaSh4bFeH5/xF5vHzxUsptc2K4AL73itPvopDK8NzbK1vDnptIfI1XAXU4eESOGyaqPyzExutM9mvEBVVYAA2a586ZD/0aEGL/e/DSa0pX3MUBuvSxA167a0sDiiDmQbZYr/8RzaQos 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 Mon, Jun 19, 2023 at 07:31:21AM -0700, Dave Hansen wrote: > On 6/19/23 04:43, Huang, Kai wrote: > > On Mon, 2023-06-12 at 06:47 -0700, Dave Hansen wrote: > >> 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. > > Hi Dave, > > > > Using atomic_set() requires changing tdmr->pamt_4k_base to atomic_t, which is a > > little bit silly or overkill IMHO. Looking at the code, it seems > > arch_atomic_set() simply uses __WRITE_ONCE(): > > How about _adding_ a variable that protects tdmr->pamt_4k_base? > Wouldn't that be more straightforward than mucking around with existing > types? What's wrong with simple global spinlock that protects all tdmr->pamt_*? It is much easier to follow than a custom serialization scheme. -- Kiryl Shutsemau / Kirill A. Shutemov