From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 D749435F612 for ; Tue, 9 Jun 2026 18:20:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781029222; cv=none; b=fHQHpq9Cyo7PLpsNNaixAFkir6ZAMS52BwROSEv74Dbj0ZG364DzvahBpVcZVdZWGstpQsLXjE2MKX+tVauA3vgLiG6RgBhrbqtayK2K0LE4i3bmzQjpk9DQq1uOaDKElXuQmdhvqKXQ4LTAeh8ztsry7QeWFuAJXagrCqwgsZc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781029222; c=relaxed/simple; bh=iQOVA/XJ80BxRy+lkmoMm1g4YcsdXHXufoCDdnfJomw=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=Mzn6ZH0PFL3ddJ8CVZ/EAhKcPO1BqiHEZFmF4PWnVDJ7Yfv7JvM1jUA7Nj158gZnwEsKLTHYoc7ifAsBDuthnqPV3xexJ4uNH7yQU21P/tx/Z3A7sYNWygpxYGaGflnKFEj2qGXMJ3she62pe7z9EDhXK8MX/dm8ZESS9tSGLEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nOwcS0NO; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nOwcS0NO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6AF961F00893; Tue, 9 Jun 2026 18:20:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781029221; bh=iovQDQJTejzASxJKYxLgbOTPFdKvlfF5FjEGL3qLAA0=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=nOwcS0NOytZrca234kuniYDrE+ipOwFN0ZB7I4Zp0y/ulnpTX+Qt8mdl00r83zjTa Vx6xIVSSBzNbBfrJRdgU2s3k1eIiODRkkR3jdZ7+4KH++7S538r8Pj/A6VgsEQZYdN 4ODqlemMOtJLesn5OzueBs3cu5yIzRml5OQFpii16e+9AmVGioKvWKF1vqtfmB8KQD 6cN5YCd/bLr/1rzoHZd8c3wQJ7g/OOPvknXx3s2aNT8IG3E/pwY7KKn/JZmM05A58O d1fcX5ayV+EZcwWflbdvLzNe7WGEmikLbGzlhozw5jqOzETzvygWxahI/0qJ/1cl2Q hGpooWOCzJIRQ== From: sashiko-bot@kernel.org Subject: Re: [RFC PATCH 1/6] arm64: rsi: Add RSI host call structure and helper function Reply-To: sashiko-reviews@lists.linux.dev To: "Kameron Carr" Cc: linux-hyperv@vger.kernel.org In-Reply-To: <20260609181030.2378391-2-kameroncarr@linux.microsoft.com> References: <20260609181030.2378391-2-kameroncarr@linux.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 09 Jun 2026 18:20:20 +0000 Message-Id: <20260609182021.6AF961F00893@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Low] The `struct rsi_host_call` ABI definition relies on implicit compil= er padding, failing to explicitly represent the RES0 field required by the = CCA RMM specification. -- commit 8a89052b48f09110c7f3fe9050a30fbf2d54c237 Author: Kameron Carr arm64: rsi: Add RSI host call structure and helper function This commit introduces the rsi_host_call structure and a helper function to facilitate hypercall routing through the RSI interface for Hyper-V guests in an Arm CCA Realm. > diff --git a/arch/arm64/include/asm/rsi_smc.h b/arch/arm64/include/asm/rs= i_smc.h > index e19253f96c940..ffea93340ed7f 100644 > --- a/arch/arm64/include/asm/rsi_smc.h > +++ b/arch/arm64/include/asm/rsi_smc.h [ ... ] > @@ -142,6 +142,12 @@ struct realm_config { > */ > } __aligned(0x1000); > =20 > +struct rsi_host_call { > + u16 immediate; > + u64 gprs[31]; > +} __aligned(256); [Severity: Low] This isn't a bug, but does this structure definition leave a 6-byte implicit padding hole between immediate and gprs? The Arm CCA RMM specification requires this 48-bit region to be reserved and zeroed. While current allocations might safely zero this memory, could a future stack allocation of this structure leave the padding bytes uninitialized? Would it be safer to add an explicit padding field to enforce the correct layout and prevent potential leaks of uninitialized Realm memory to the untrusted Host? > +static_assert(sizeof(struct rsi_host_call) =3D=3D 256); > + > #endif /* __ASSEMBLER__ */ --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260609181030.2378= 391-1-kameroncarr@linux.microsoft.com?part=3D1