Received-SPF: pass (google.com: domain of linux-kernel+bounces-130802-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 4 Apr 2024 09:03:49 +0800
From: Chao Gao <chao.gao@intel.com>
To: "Huang, Kai" <kai.huang@intel.com>
CC: "Yamahata, Isaku" <isaku.yamahata@intel.com>, "kvm@vger.kernel.org"
	<kvm@vger.kernel.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "isaku.yamahata@gmail.com"
	<isaku.yamahata@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>, "Aktas,
 Erdem" <erdemaktas@google.com>, Sean Christopherson <seanjc@google.com>,
	"Sagi Shahar" <sagis@google.com>, "Chen, Bo2" <chen.bo@intel.com>, "Yuan,
 Hang" <hang.yuan@intel.com>, "Zhang, Tina" <tina.zhang@intel.com>, "Sean
 Christopherson" <sean.j.christopherson@intel.com>,
	"isaku.yamahata@linux.intel.com" <isaku.yamahata@linux.intel.com>
Subject: Re: [PATCH v19 038/130] KVM: TDX: create/destroy VM structure
Message-ID: <Zg38dcrwMg1a7iJT@chao-email>
References: <cover.1708933498.git.isaku.yamahata@intel.com>
 <7a508f88e8c8b5199da85b7a9959882ddf390796.1708933498.git.isaku.yamahata@intel.com>
 <ZfpwIespKy8qxWWE@chao-email>
 <20240321141709.GK1994522@ls.amr.corp.intel.com>
 <58e0cf59-1397-44a3-a6a0-e26b2e51ba7b@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <58e0cf59-1397-44a3-a6a0-e26b2e51ba7b@intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9XdnOm75BRd4JOphI5Hr2R8kjyRbMU9KWuNhvr3K/LVoRMAcrPNLM26TrGb+?=
 =?us-ascii?Q?FzMNX5l0bRbA+hYR/SkSHjF7JsPNMVuWJsSGSesYI6p6MKMBVf704UDkGG5L?=
 =?us-ascii?Q?UB7iBiu3dkJrzUFMsRargOrWwi2fWqPNy0+S4Sah0BqhVZ7jttQWCGWFRov3?=
 =?us-ascii?Q?Cfvl69EDyVh58p2r2cFcpvhiAmoBXl3LZZHiqJmkHdRSe3dBQE6fG+5+tNnB?=
 =?us-ascii?Q?jLV4E3FdRItZ8GsueAK8dloZiI2vcF0MDRCWrdf1nj2FZWHjiqisflsuEC4G?=
 =?us-ascii?Q?OPB6CBs0ncD9S7hRoxOsDcKN/cWE3kivH+SwLeg8anqt/rkNL97+ObBLg0pF?=
 =?us-ascii?Q?AV/ds6k9FEj0wpTSpk1tQ18zGLMk80+aecH2VjDsFMX3ZCXBj3QXd2QxEJll?=
 =?us-ascii?Q?AGGocFH0wxNW9JQdxR/DBXlbNO9oraTeKk70amOUqpMJI49/Z50kBotx1BNv?=
 =?us-ascii?Q?tYhp5L1BjRBpBzZuCz/jn+x5k31qL0Wm87st2KHINfeLgIkPwim503F0JDHT?=
 =?us-ascii?Q?x98pnHefCSkIq30nLWJNsRKSQEDbBPBLMkF1n6ibNSpptu+PAh09WDWHiPIe?=
 =?us-ascii?Q?XqQBKo5zhLFw099yBfVCAGpxn9R29RvcqVeWzJAAEyp01ByzqTq5NLN6PAEU?=
 =?us-ascii?Q?Pg9ef6xlOiFAB3gPb0aoWkfAN0u0kazCigz4BeJWVLdw4CBHh3ffQIDJLbaD?=
 =?us-ascii?Q?b59EA/Zw8t1j6vzumDF9QMgRxrYslK3oS/oaFXm/uMtP+8ZNnYlzwtZDpIYm?=
 =?us-ascii?Q?aVnHqfo2Nwyyz67Hkqgp9yv2g6w3uOIlXtCKk3WozMIO9lClN6Y5PbIWmlfe?=
 =?us-ascii?Q?ohy9fIBSZp2fu9om6k/e2IRO3z2Xe9fyf3/XXu3YW9Z1i9CD9uj6NAt79zpv?=
 =?us-ascii?Q?6DzV9yALWpE7aB6FXJNx7or1RUnrK2JZdbpv78QC+BXH5CNFFcPiakQ7zBQ+?=
 =?us-ascii?Q?B7Lfvp5VYsEVmKhWk5AoLtNxslYVIyVeIyLpoBfe1AJghhOtoA0OuQqvqefx?=
 =?us-ascii?Q?Si4Vo1VKD6muio8J7AWya3u/tOdgoEa4ud4gdcJH3G1l+Fae/zPEfVxKvf2F?=
 =?us-ascii?Q?qwflvEnjXMzIejxhsBOpxvFKwf4iWLAMaTkouwsFYhlsT8YF3rcxKdFY3Hu9?=
 =?us-ascii?Q?4HQvYs/sCeWhOo7PZJb62qOHxPOOHyZcG7ZbZKBaR6aI6y13YqUryFsnRQcP?=
 =?us-ascii?Q?C+PxRzctJPSNhkX4qs3NXOXu8AXfzKFkvQrDkjFRbOfAdsXeirXd7vvruJ8L?=
 =?us-ascii?Q?aQ7Jy7yI4CEie+03yKbJyuYfxVtynh+BR13xfXbDNuYwgS9J+JzBxK1WLmCz?=
 =?us-ascii?Q?gjAUsrTcAcy3hM5DNrEFzS3CpwrSz8jMjDHsMjpE/4OMI8B4C+a0aj+1F45n?=
 =?us-ascii?Q?p/Gahs9iBQdLj66d+ShoHCGkmTKPSOIbnmczAki/FO5dlHgSHvJbUyO62SRJ?=
 =?us-ascii?Q?y2wAtYBN1ZgVZpixprRgQBhAkj8OS7bXGPKvziRLs0OmwMrhsp8xftR8pm8l?=
 =?us-ascii?Q?gbLff8C/gV5iiGm3TcTO1gfpmIUFONlvIFTgcjaox0SWsiO6taL/a7MXjxE9?=
 =?us-ascii?Q?40X+IvLD2Go8YOC1A0BH/eIhSlhRWMqMXNfvoL92?=
X-MS-Exchange-CrossTenant-Network-Message-Id: cf717634-b701-47c6-d42f-08dc54431cb5
X-MS-Exchange-CrossTenant-AuthSource: CH3PR11MB8660.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2024 01:04:00.4740
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Bizc3hhPRKIhLpuvj3DVFwUXHNhBbXfA6j6otdO2q9rPHnGAfNwZLa6TSDaYvuw0sUIHycTBWGmRz1M+ZaOW2A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR11MB6532
X-OriginatorOrg: intel.com

On Thu, Apr 04, 2024 at 11:13:49AM +1300, Huang, Kai wrote:
>
>
>On 22/03/2024 3:17 am, Yamahata, Isaku wrote:
>> > > +
>> > > +	for_each_online_cpu(i) {
>> > > +		int pkg = topology_physical_package_id(i);
>> > > +
>> > > +		if (cpumask_test_and_set_cpu(pkg, packages))
>> > > +			continue;
>> > > +
>> > > +		/*
>> > > +		 * Program the memory controller in the package with an
>> > > +		 * encryption key associated to a TDX private host key id
>> > > +		 * assigned to this TDR.  Concurrent operations on same memory
>> > > +		 * controller results in TDX_OPERAND_BUSY.  Avoid this race by
>> > > +		 * mutex.
>> > > +		 */
>> > > +		mutex_lock(&tdx_mng_key_config_lock[pkg]);
>> > the lock is superfluous to me. with cpu lock held, even if multiple CPUs try to
>> > create TDs, the same set of CPUs (the first online CPU of each package) will be
>> > selected to configure the key because of the cpumask_test_and_set_cpu() above.
>> > it means, we never have two CPUs in the same socket trying to program the key,
>> > i.e., no concurrent calls.
>> Makes sense. Will drop the lock.
>
>Hmm.. Skipping in cpumask_test_and_set_cpu() would result in the second
>TDH.MNG.KEY.CONFIG not being done for the second VM.  No?

No. Because @packages isn't shared between VMs.