From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa10.hc1455-7.c3s2.iphmx.com (esa10.hc1455-7.c3s2.iphmx.com [139.138.36.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 234DC23A566 for ; Tue, 9 Jun 2026 13:17:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=139.138.36.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781011032; cv=none; b=sA3r2S42PHWrgZqvLcQEZzGNtFXfuXIiqZ+9OfJyZPeRRkxDjR+ry1DJRR4L7rDQhGOavj6iunWp+dg2kNNYDVJmUixLXlrqUzrAbVd9tbB2VzvfZhcL7fcJDsA4Tz+4mZNd80m/LmkapefZQzFTl/2Vl6JURV7CM9EsmQHGENY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781011032; c=relaxed/simple; bh=N/vFtBsEQhmzFRkg7JVXBFy8+0kq7irSjH06B5RYaow=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LaDz0BmwgtoaEqLyRD+SoApmLRo1aeIF8LO/DdGar37ktSKQugM9EHTR2qyxpQGe5Pj2NtSzBVDa1qrh4AJk50aj0WnZUFQteZNqynyiVwHLqVEydMcIji2cGCi9O7czq9DNqvxTC4rlBiV5lxbQGb3KQ+Rw7CMYjbAvRIFG1GA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fujitsu.com; spf=pass smtp.mailfrom=fujitsu.com; dkim=pass (2048-bit key) header.d=fujitsu.com header.i=@fujitsu.com header.b=OvhsnrNx; arc=none smtp.client-ip=139.138.36.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fujitsu.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fujitsu.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fujitsu.com header.i=@fujitsu.com header.b="OvhsnrNx" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fujitsu.com; i=@fujitsu.com; q=dns/txt; s=fj2; t=1781011031; x=1812547031; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=N/vFtBsEQhmzFRkg7JVXBFy8+0kq7irSjH06B5RYaow=; b=OvhsnrNxo8O3m4y8JjxOBeEiK4NhJAvKRQnKEEE+sPLS6MfMNcHEy28I Oj4qHWZAqYWxY8eavL/ZIernvKLTipZr7psCzTtH1KBUaXu6+40g5SdAQ QPbQ2CENtd4Qw+N0XldiZWTUm4EFuCiEcBkpQKXvIyD7mg+19maro4Jte 4ZWL+DrJy1KWy7KO5mxmjsTAcI2Mb8VpAz/vgNB0IyY72ebhm7jp2DSFj 09JVxxIUIJvhQBzfAeAcoFMTknd8fyzThDYoXE8Zrep+RG3vud8CdIwRl Gsq6W7tVJL2xTBWELKsoxrVVjZnO/U0Nx9Gk//48PJ1hEGavand6f2qD+ Q==; X-CSE-ConnectionGUID: xszbGrgtTcmhHDIStsHZQQ== X-CSE-MsgGUID: oGujVtMfSpC9pDek7ymM3g== X-IronPort-AV: E=McAfee;i="6800,10657,11811"; a="229682418" X-IronPort-AV: E=Sophos;i="6.24,196,1774278000"; d="scan'208";a="229682418" Received: from gmgwnl01.global.fujitsu.com (HELO mgmgwnl01.global.fujitsu.com) ([52.143.17.124]) by esa10.hc1455-7.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2026 22:17:03 +0900 Received: from az2nlsmgm1.o.css.fujitsu.com (unknown [10.150.26.203]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mgmgwnl01.global.fujitsu.com (Postfix) with ESMTPS id 12A387A41 for ; Tue, 9 Jun 2026 13:17:03 +0000 (UTC) Received: from az2nlsmom3.fujitsu.com (unknown [10.150.26.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by az2nlsmgm1.o.css.fujitsu.com (Postfix) with ESMTPS id BC4F5C00FEB for ; Tue, 9 Jun 2026 13:17:02 +0000 (UTC) Received: from FCCLS0092175.localdomain (unknown [10.9.34.167]) by az2nlsmom3.fujitsu.com (Postfix) with SMTP id 5E34A101E52F; Tue, 9 Jun 2026 13:16:59 +0000 (UTC) Date: Tue, 9 Jun 2026 22:16:57 +0900 From: Kohei Enju To: Will Deacon Cc: Suzuki K Poulose , Catalin Marinas , Sami Mujawar , Gavin Shan , Steven Price , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new() Message-ID: References: <20260519101217.155740-1-enju.kohei@fujitsu.com> <41ab4dfb-b91c-46df-99a0-de36686c8fea@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On 06/03 12:48, Will Deacon wrote: > On Tue, Jun 02, 2026 at 04:48:43PM +0100, Suzuki K Poulose wrote: > > On 02/06/2026 12:01, Will Deacon wrote: > > > On Tue, May 19, 2026 at 07:12:08PM +0900, Kohei Enju wrote: > > > > With CONFIG_DEBUG_PREEMPT=y, smp_processor_id() becomes an alias of > > > > debug_smp_processor_id(). This debug function complains when certain > > > > conditions that ensure CPU ID stability are not met, specifically when > > > > it's called from a preemptible context. > > > > > > > > In arm_cca_report_new(), which runs in a preemptible context, > > > > smp_processor_id() triggers a splat [0] due to this. > > > > > > > > However, the CPU ID obtained here is used as the target CPU for > > > > smp_call_function_single() to designate a specific CPU for subsequent > > > > operations, not to assert that the current thread will continue to > > > > execute on the same CPU. Therefore, snapshotting the CPU ID itself is > > > > correct, and thus there's no actual harm except for the splat. > > > > > > > > Use raw_smp_processor_id() instead, to directly retrieve the current CPU > > > > ID without the debug checks, avoiding the unnecessary warning message > > > > while preserving the correct functional behavior. > > > > > > That's pretty disgusting imo so I'd like to see some more justification > > > for this approach. > > > > > > > Note that while migrate_disable() would pin the task to the current CPU, > > > > this path should not block CPU hotplug events. Therefore, we snapshot > > > > the current CPU ID and accept that smp_call_function_single() may fail > > > > if the CPU goes offline. > > > > > > Why shouldn't it block CPU hotplug events? What happens if the CPU goes > > > offline and comes back online again during the loop of continue calls? > > > > It need not. It can continue the calls. The RMM keeps track of the internal > > progress in the "REC" object for this "VCPU". Hotplug ON/OFF > > doesn't change the REC object in CCA Guest. So, a REC can come back and > > execute it. But the Linux could fail the operation if the CPU isn't > > available for fetching the report, after we do a RSI_ATTEST_TOKEN_INIT. > > I couldn't really shake that out of the RMM spec tbh: > RSI_ATTESTATION_TOKEN_CONTINUE is allowed to return RSI_ERROR_UNKNOWN > and I couldn't find anything about hotplug. > > But my main point, really, is why are we not using migrate_disable() > here? I can't see the justification. Hi Will, Sorry for the late reply. I agree that using migrate_disable() makes this path simpler and clearer. I've reviewed the discussion where the original commit was introduced: https://lore.kernel.org/linux-arm-kernel/7a83461d-40fd-4e61-8833-5dae2abaf82b@arm.com/ but I couldn't find a strong reason why we shouldn't block CPU hotplug or use migrate_disable(), even though I can see the current design was intentional. So I'm happy to rework the patch to use migrate_disable() and remove the smp_call_function_single() calls if there are no objections. > > Will >