Re: [PATCH v7 19/23] KVM: s390: arm64: Implement required functions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Stubbed exception injection functions cause infinite trap loops, allowing guest userspace to permanently hang a VCPU.
- [High] Incorrect endianness mapping for 32-bit FPSR/FPCR registers accessed via KVM_GET_ONE_REG / KVM_SET_ONE_REG.
--

commit 93d3dbc5966621adfcec645f4ad14f3ea7a0f69a
Author: Steffen Eiden <seiden@linux.ibm.com>

KVM: s390: arm64: Implement required functions

This commit implements the required arm64 KVM shared functions for s390,
adding necessary headers and basic exception injection stubs. It also
provides a temporary SMC/HVC exit handler.

> diff --git a/arch/s390/include/arm64/kvm_emulate.h b/arch/s390/include/arm64/kvm_emulate.h
> new file mode 100644
> --- /dev/null
> +++ b/arch/s390/include/arm64/kvm_emulate.h

[ ... ]

> +static __always_inline u64 *vcpu_fpsr(struct kvm_vcpu *vcpu)
> +{
> +	return &vcpu->arch.sae_block.fpsr;
> +}

[Severity: High]
Because s390 is big-endian, does returning a u64 pointer here cause data
corruption during KVM_GET_ONE_REG or KVM_SET_ONE_REG calls?

The shared arm64 code treats fp_regs.fpsr as a 32-bit value and casts the
returned pointer to (u32 *). Pointing to a 64-bit value on a big-endian
system means the cast will access the most-significant 32 bits (which are
zero) instead of the lower 32 bits containing the actual register state.

> +
> +static __always_inline u64 *vcpu_fpcr(struct kvm_vcpu *vcpu)
> +{
> +	return &vcpu->arch.sae_block.fpcr;
> +}

[Severity: High]
Does this have the same 32-bit KVM API endianness corruption issue as
vcpu_fpsr() above?

[ ... ]

> diff --git a/arch/s390/kvm/arm64/inject_fault.c b/arch/s390/kvm/arm64/inject_fault.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/s390/kvm/arm64/inject_fault.c

[ ... ]

> +void kvm_inject_undefined(struct kvm_vcpu *vcpu)
> +{
> +	/* Stub until s390 supports arm64 sysregs TODO sysregs*/
> +}

[Severity: High]
Does leaving this stub empty cause an infinite trap loop on the host?

When an unprivileged guest userspace process executes an undefined
instruction, KVM triggers an exception intercept. The KVM handler
kvm_handle_unknown_ec() calls kvm_inject_undefined(), which does nothing
here.

Since kvm_handle_unknown_ec() returns 1 and the stub doesn't advance the
guest PC, KVM will immediately re-enter the guest at the exact same faulting
instruction, permanently hanging the guest VCPU.

> +
> +int kvm_inject_sea(struct kvm_vcpu *vcpu, bool iabt, u64 addr)
> +{
> +	/* Stub until s390 supports arm64 sysregs TODO sysregs*/
> +	return 1;
> +}

[Severity: High]
Does this stub act identically to kvm_inject_undefined() and cause a hang
when a Synchronous External Abort is triggered (for example, via
KVM_SET_VCPU_EVENTS)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831144802.834315-1-seiden@linux.ibm.com?part=19