Re: [PATCH] RISC-V: KVM: Fix spurious -EEXIST and clean up gstage fault path types

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch fails to resolve the 34-bit GPA truncation on RV32 because the address calculation `(trap->htval << 2)` is still evaluated using 32-bit arithmetic before assignment.
--

--- Patch [1]: [PATCH] RISC-V: KVM: Fix spurious -EEXIST and clean up gstage fault path types ---
commit 9da8ae12634bbc92cd912d48c6458250997cb454
Author: Bingyu.Xian <shanbeeyoo@gmail.com>

RISC-V: KVM: Fix spurious -EEXIST and clean up gstage fault path types

This commit updates the G-stage page fault path to treat -EEXIST from
kvm_riscv_gstage_map_page() as a success, aligning RISC-V with other
architectures. It also updates the type of vma_pageshift to unsigned int
and fault_addr to gpa_t, intending to prevent 34-bit guest physical address
truncation on RV32.

[ ... ]

> diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
> index 6c8530b9f29ed..76cceecee5aba 100644
> --- a/arch/riscv/kvm/vcpu_exit.c
> +++ b/arch/riscv/kvm/vcpu_exit.c
> @@ -17,7 +17,8 @@ static int gstage_page_fault(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  {
>  	struct kvm_gstage_mapping host_map;
>  	struct kvm_memory_slot *memslot;
> -	unsigned long hva, fault_addr;
> +	unsigned long hva;
> +	gpa_t fault_addr;

[Severity: High]
This is a pre-existing issue, but does the calculation for fault_addr still
truncate the address on RV32 before this assignment?

The commit message notes this type change is meant to prevent 34-bit guest
physical addresses from being truncated. However, looking further down in
gstage_page_fault(), the actual calculation is:

    fault_addr = (trap->htval << 2) | (trap->stval & 0x3);

Because trap->htval is an unsigned long, the shift (trap->htval << 2) is
evaluated as a 32-bit operation on RV32. This discards the upper bits of
the 34-bit guest physical address before the final result is widened and
stored in the new 64-bit gpa_t variable.

Should trap->htval be explicitly cast to gpa_t or u64 before the shift
operation to ensure the higher bits are preserved?

>  	bool writable;
>  	gfn_t gfn;
>  	int ret;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729070749.730218-1-shanbeeyoo@gmail.com?part=1