[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 1/3] x86/hap: Wait for remote CPUs during TLB flush


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
  • Date: Wed, 8 Apr 2026 16:48:47 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ifIojBZRiaopT06TQJuudILChDEvA/PjmNK3dFnlbfE=; b=DB1TZuegpAYvkQ2tjNuE/rRQiqgmWgw+Juc58VcIb7CpP5uyDNqsZAeYq9PzLN9rbItuRnLdI65wXdxl946OJKNNhkmXEeHUQa/6UKGFBbgNU9zT16ryfPuPS9BVnNms2V8gUfwL5n3MuSpRr/Je9sQot35ha6oKkYr9VCo6ZZPaWpdXklgdHNwciuNaeaEXd3CrhwObhssbtv6uYHsmixjPBglCONPvNjlarUxJjVv3V2J/JBkBOpq0N8D+opHdIq9U4BWdKsdsV/hSqb/jMUkm1wyzVFRTtoniaHbuYnV5OugjRa+NsfHVdrpi0wpkufMU6d5PuQUHJuQG1vaR7A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AXNe0meH2L8M08dQ1SkHDuXWo4ui8yHYbS22SCJtxw8wmEbFl3MRvCIju7cGu9u6cU/i0liudGumLpEnjOR4B5QozrB/VQ/C7ROqERiebLSYY/VDz3ON0IVe48S7lt76PVROnCQ4PR7IppFEmtwge27OMpxuVLJDMKHmAKdeSXWneIypnXsqEXusW5cGKoGejVdU1xwAgLATl9wFvpaDp4fIE+9szFmARxmSbAhu52YI8XV4uqatQVzKA2YdwJRR7iSzbU5iT1i5HgW19IhD3G2m9/L7v7pEbVVdhHZCJS+X8U5KglXYzi0fDgrDLZao9ocN+NgoI3t7px9aEbfoCQ==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 08 Apr 2026 15:49:14 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 4/8/26 4:21 PM, Jan Beulich wrote:
On 01.04.2026 18:35, Ross Lagerwall wrote:
A future change to on_selected_cpus() will change the semantics of the
wait parameter so that it doesn't wait for remote CPUs to "check in" if
wait == 0. Adjust the call here to retain the existing behaviour so it
continues to wait for the remote CPUs to VMExit.

Doesn't this go too far though? IOW wouldn't we better make the "wait"
parameter a tristate then?

From what I can see, the current wait == 0 behaviour only exists as a
limitation of the implementation: The local CPU needs to wait for all
the remote CPUs to have read "func" and "info" before dropping the lock
to avoid a race condition.

With that limitation removed, I don't see a valid reason to maintain
this beahviour as an option, though I could be convinced otherwise.


As to the semantic change, peeking at patch 2 I don't see you discussing
the safety of doing so for the several other callers that also pass 0
right now.


I did audit the other callers (including via smp_call_function() and
on_each_cpu()) and I believe they are all fine as is.
I can update the commit message to say something along these lines.

Ross



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.