From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 7F2D7192B7D; Mon, 24 Nov 2025 13:22:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763990572; cv=none; b=Nb8K/5mcvmc6cCk1KXlZspRCPwMrDAcosd5NEdNwrmnHEHHYzWGYs2eTx9hGVoaXemAZ0U+ZwVQwFX/Jr0WIev6WX9MkkITDFfxAHUhE369TmRMo4BljTCh7a009WF9iKUPQiZI+AAdgKqdKIeRby3Scqwt6w9/6S82yGSuZVlE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763990572; c=relaxed/simple; bh=OtU6aho4DVI3g6jpWkZccv9Y0k88412t6zYkWXTFktI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=m8aSgP5MXwRCbpDUJA341OVwNfvts4H5os3BEDiQDsAJ2E6OxQClGb/Ubphfs3gLY5oFTMHNBeJEvExJJoEGt6utJ9nERijBnTlxoSoFyO8PIStRZBIBU8sM9C6r+n7l9Fo3HiNBK8chYeC1I78LtQaaygyUqxJrcL7kpJkzrLQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T3n9exZJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T3n9exZJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C351C4CEF1; Mon, 24 Nov 2025 13:22:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763990571; bh=OtU6aho4DVI3g6jpWkZccv9Y0k88412t6zYkWXTFktI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=T3n9exZJ15G0U6tXHmL7uG4lkGcQmMVNTcDKBzI+7ad/ouwSGNA1U16fP4uZdXbVB Fp2Rxkud7FLlQtUWu07idSRMn2LBW3e9bz3OloTV9VNqkX1+smTwz1v1gMRg5mJg8p Vn8gpj5u8bAqvRakwQf/ht8wO1CMkaHKj8EsvhZaCJP6EyVzdbhoE0bT8MXHymP14P 9PONcQWTuP9uvhqJvUAdPYmCuBjQ0ylPGvV+iFwXp7Dm2kSxuMH1F8pGp54J/wUr3G iJCoSFMNYYEXUVm9+010r1JzPKKzoi30xYI5riBFYYmaYxu6Qihon5lc7oHn6iItcs eXD1XbgNzVuQA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vNWWm-00000007rBS-2lh1; Mon, 24 Nov 2025 13:22:48 +0000 Date: Mon, 24 Nov 2025 13:22:48 +0000 Message-ID: <86ms4br2dz.wl-maz@kernel.org> From: Marc Zyngier To: Kornel =?UTF-8?B?RHVsxJliYQ==?= Cc: Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Bartlomiej Grzesik , Tomasz Nowicki , Sebastian Ene , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Fix error checking for FFA_VERSION In-Reply-To: References: <20251114-pkvm_init_noffa-v1-1-87a82e87c345@google.com> <86y0nyqoy9.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: korneld@google.com, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, bgrzesik@google.com, tnowicki@google.com, sebastianene@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 24 Nov 2025 11:49:08 +0000, Kornel Dul=C4=99ba wrote: >=20 > On Sat, Nov 22, 2025 at 12:36=E2=80=AFPM Marc Zyngier wr= ote: > > > > On Fri, 14 Nov 2025 11:11:53 +0000, > > "=3D?utf-8?q?Kornel_Dul=3DC4=3D99ba?=3D" wrote: > > > > > > According to section 13.2 of the DEN0077 FF-A specification, when > > > firmware does not support the requested version, it should reply with > > > FFA_RET_NOT_SUPPORTED(-1). Table 13.6 specifies the type of the error > > > code as int32. > > > Currently, the error checking logic compares the unsigned long return > > > value it got from the SMC layer, against a "-1" literal. This fails d= ue > > > to a type mismatch: the literal is extended to 64 bits, whereas the > > > register contains only 32 bits of ones(0x00000000ffffffff). > > > Consequently, hyp_ffa_init misinterprets the "-1" return value as an > > > invalid FF-A version. This prevents pKVM initialization on devices wh= ere > > > FF-A is not supported in firmware. > > > > Is this statement accurate? I regularly boot KVM in protected mode in > > environments that really cannot be suspected of implementing FF-A > > (there is no EL3 to start with). And yet I don't see any failure of > > the sort. > > > > Please clarify the circumstances this is triggered. >=20 > I do have EL3 enabled, but the FF-A itself is not implemented. >=20 > Without this change kvm initialization fails with the following: >=20 > [ 0.946776][ T1] kvm [1]: nv: 554 coarse grained trap handlers > [ 0.952880][ T1] kvm [1]: nv: 669 fine grained trap handlers > [ 0.958813][ T1] kvm [1]: IPA Size Limit: 44 bits > (...) > [ 1.034089][ T1] kvm [1]: Failed to init hyp memory protection > [ 1.041213][ T1] kvm [1]: error initializing Hyp mode: -95 [ 0.045492] kvm [1]: nv: 568 coarse grained trap handlers [ 0.045860] kvm [1]: nv: 664 fine grained trap handlers [ 0.046194] kvm [1]: IPA Size Limit: 42 bits [ 0.220184] kvm [1]: GICv3: no GICV resource entry [ 0.220525] kvm [1]: disabling GICv2 emulation [ 0.220852] kvm [1]: GIC system register CPU interface enabled [ 0.221264] kvm [1]: vgic interrupt IRQ9 [ 0.221565] kvm [1]: Protected hVHE mode initialized successfully Ergo, it works here without FFA (this is in a nested guest that is not exposed anything but PSCI in the FW emulation). > I managed to narrow this down to the FFA version check by examining > all of the places in kvm initialization logic where -EOPNOTSUPP is > returned. Since printing anything in this part of the code is somewhat > problematic I replaced =E2=80=9Creturn -EOPNOTSUPP=E2=80=9D with =E2=80= =9Creturn res.s0=E2=80=9D to > examine the problematic register value: >=20 > [1.041229][ T1] kvm [1]: error initializing Hyp mode: -1 >=20 > Note that the return code itself is cast to int before being printed. > Then a colleague of mine recommended looking into the arm_ffa driver. > (=E2=80=9Cdrivers/firmware/arm_ffa/driver.c=E2=80=9D) There I found that = in the > ffa_version_check function, the return value from the SMC call is cast > to s32 before being checked for errors. > I did the same in the kvm initialization logic, which is how this > patch was created. Furthermore I also examined the FF-A > specification(DEN0077), where the error code value type is specified > as int32. > With this change applied I can now see that kvm is up and running: >=20 > [ 0.946839][ T1] kvm [1]: nv: 554 coarse grained trap handlers > [ 0.952940][ T1] kvm [1]: nv: 669 fine grained trap handlers > [ 0.958867][ T1] kvm [1]: IPA Size Limit: 44 bits > (...) > [ 1.061717][ T1] kvm [1]: Protected hVHE mode initialized successfu= lly >=20 > The /dev/kvm file is also there. I don't dispute the bug. I dispute the assertion that the absence of FFA triggers it. So either your testing environment influences the behaviour, or you have extra patches that also change the behaviour, or something else. Thanks, M. --=20 Without deviation from the norm, progress is not possible.