[agicy]

Summary

Unhandled SMC function IDs now return ARM_SMCCC_NOT_SUPPORTED instead of 0,
and the remaining literal !0 returns use the same constant.

hunk	behaviour
handle_smc fallback	0 -> NOT_SUPPORTED (changes)
handle_psci_smc fallback	0 -> NOT_SUPPORTED (changes)
psci_emulate_features_info fallback	!0 -> constant (same value)
SMCCC_ARCH_FEATURES arm	!0 -> constant (same value)
handle_arch_smc fallback	!0 -> constant (same value); error! -> warn! with the code

Motivation

0 is SMCCC SUCCESS. Returning it for a function hvisor does not implement
tells the guest the call worked, so optional firmware features probe as present.

Reproduced on aarch64/qemu-gicv3 with Linux 7.2.8:

[    0.000000] RME: Using RSI version 1.0
[WARN] unsupported smc standard service 0xc4000190     <- RSI_ABI_VERSION
[WARN] unsupported smc standard service 0xc4000196
[WARN] unsupported smc standard service 0xc4000197
[    0.000000] Kernel panic - not syncing:
               Failed to set memory range to protected: 0x80000000-0xc0000000

hvisor answered 0, so the guest concluded it was running in a CCA realm and
proceeded to RSI_SET_MEMORY_PROTECTED, which cannot work here. With
NOT_SUPPORTED the probes answer honestly, RME is not enabled, and the board
boots. This is reachable on any platform whose firmware advertises RME,
including real hardware with TF-A.

The other hunks do not change behaviour; they exist so the file spells the
return value one way.

Verification

Environment: aarch64/qemu-gicv3, QEMU 11.1.1, guest Linux 7.2.8, U-Boot/TF-A
boot flow (-bios u-boot-atf.bin + flash.img).

make BID=aarch64/qemu-gicv3 all
qemu-system-aarch64 -machine virt,secure=on,gic-version=3,virtualization=on,iommu=smmuv3 \
  ... -bios platform/aarch64/qemu-gicv3/image/bootloader/u-boot-atf.bin \
  -drive if=pflash,format=raw,index=1,file=flash.img ...

	before	after
RME: Using RSI version 1.0	yes	no
kernel panic (Failed to set memory range to protected)	yes	no
boot	-	Mounted root (2.55s), shell
CPU features: detected:	Spectre-v2/v3a/v4/BHB	unchanged

Not run: real hardware, riscv64/loongarch64/x86_64 (the change is confined to
src/arch/aarch64/trap.rs).

Risks and Limitations

• Two hunks change guest-visible behaviour. NOT_SUPPORTED is the value the
  SMCCC specification requires for an unimplemented function, and guests treat
  it as "feature absent", which is what was previously being misreported as
  "feature present". No caller is known to depend on the old 0.
• The handle_arch_smc fallback now logs at warn instead of error. Error
  level implied a defect where the call simply is not implemented.
• Not changed: ARCH_SC calls are still answered locally rather than
  forwarded to EL3. Forwarding is arguably more correct (the guest is asking
  the firmware whether it implements a workaround), but it is a wider behaviour
  change with no observable difference on this setup, because QEMU's TF-A does
  not implement ARCH_WORKAROUND_1. Better raised separately.
• Only the aarch64 path is touched.

[li041]

LGTM! Thanks for your contribution.