Re: [PATCH] KVM: arm64: Fix error checking for FFA_VERSION

On Mon, Nov 24, 2025 at 01:22:48PM +0000, Marc Zyngier wrote:

On Mon, 24 Nov 2025 11:49:08 +0000,
Kornel Dulęba [off-list ref] wrote:

quoted

On Sat, Nov 22, 2025 at 12:36 PM Marc Zyngier [off-list ref] wrote:

quoted

On Fri, 14 Nov 2025 11:11:53 +0000,
"=?utf-8?q?Kornel_Dul=C4=99ba?=" [off-list ref] wrote:

quoted

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 due
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 where
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.

I do have EL3 enabled, but the FF-A itself is not implemented.

Without this change kvm initialization fails with the following:

[    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 looked briefly at this today and I think the !FFA path for nested
probably ends up in kvm_smccc_call_handler(), which will get
KVM_SMCCC_FILTER_DENY for the FFA_VERSION call and end up returning
SMCCC_RET_NOT_SUPPORTED as a u64, so 0xffffffffffffffff and effectively
hiding the bug in the proxy code.

So that might explain the different behaviours we're seeing.

On the plus side, the fix should continue to work in that case because
we'll just ignore the upper 32 bits.

Will