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

On Wed, Jul 29, 2026 at 12:37 PM Bingyu.Xian <[email protected]> wrote:
>
> Two small fixes to the RISC-V G-stage page fault path, both suggested
> during review of the in-progress KVM Userfault port.
>
> 1. Treat -EEXIST from kvm_riscv_gstage_map_page() as a quiet success.
>
>    When a concurrent vCPU installs the same G-stage mapping while we
>    are waiting for mmu_lock, gstage_map_page() returns -EEXIST.  This
>    is not an error -- the page is correctly mapped and the faulting
>    vCPU can simply retry the guest instruction -- but KVM was treating
>    it as one: printing "Failed to map in G-stage" to dmesg and
>    propagating -EEXIST all the way to userspace.
>
>    Align RISC-V with x86 and arm64, which already swallow -EEXIST in
>    their respective fault handlers.  This also lets
>    kvm_release_faultin_page() drop its "ret && ret != -EEXIST" special
>    case: with ret normalized to 0 the regular release path is correct.
>
> 2. Clean up fault path types.
>
>    - vma_pageshift: short -> unsigned int.  Bit widths and shift counts
>      conventionally use unsigned int in the kernel.
>
>    - fault_addr: unsigned long -> gpa_t.  RV32 with Sv32x4 has 34-bit
>      guest physical addresses that would be truncated when stored in a
>      32-bit unsigned long; gpa_t is u64 on RV32 and holds the full
>      address.  No functional change on RV64.

Don't squash multiple changes into one patch.

Create separate patches with appropriate Fixes tags.

Regards,
Anup

>
>    These type changes are in preparation for sharing a common
>    struct kvm_page_fault across architectures, as requested during
>    review.
>
> No functional change on RV64 beyond silencing the spurious -EEXIST.
>
> These are independent fixes with no dependencies; they can be merged
> on their own.  The KVM_MEM_USERFAULT port that motivated them will be
> sent separately as an RFC once the generic userfault series lands.
>
> Fixes: 9d05c1fee837 ("RISC-V: KVM: Implement stage2 page table programming")
> Assisted-by: YuanSheng: deepseek-v4-pro
> Co-developed-by: Quan Zhou <[email protected]>
> Signed-off-by: Quan Zhou <[email protected]>
> Signed-off-by: Bingyu Xian <[email protected]>
> ---
>  arch/riscv/kvm/mmu.c       | 8 +++++---
>  arch/riscv/kvm/vcpu_exit.c | 3 ++-
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index 8a0aa5e0e216..d2a06a54be17 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
> @@ -541,7 +541,7 @@ int kvm_riscv_mmu_map(struct kvm_vcpu *vcpu, struct kvm_memory_slot *memslot,
>         kvm_pfn_t hfn;
>         bool is_hugetlb;
>         bool writable;
> -       short vma_pageshift;
> +       unsigned int vma_pageshift;
>         gfn_t gfn = gpa >> PAGE_SHIFT;
>         struct vm_area_struct *vma;
>         struct kvm *kvm = vcpu->kvm;
> @@ -652,11 +652,13 @@ int kvm_riscv_mmu_map(struct kvm_vcpu *vcpu, struct kvm_memory_slot *memslot,
>                                                 vma_pagesize, true, true, out_map);
>         }
>
> -       if (ret)
> +       if (ret == -EEXIST)
> +               ret = 0;
> +       else if (ret)
>                 kvm_err("Failed to map in G-stage\n");
>
>  out_unlock:
> -       kvm_release_faultin_page(kvm, page, ret && ret != -EEXIST, writable);
> +       kvm_release_faultin_page(kvm, page, ret, writable);
>         write_unlock(&kvm->mmu_lock);
>         return ret;
>  }
> diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
> index 6c8530b9f29e..76cceecee5ab 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;
>         bool writable;
>         gfn_t gfn;
>         int ret;
> --
> 2.54.0
>

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv