linux-kernel - Re: [External] Re: [PATCH v2] RISC-V: KVM: Delegate kvm unhandled faults to VS mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPYmKFur4asd4bzCBgCwrPpMK9amihWSeK2Vwpk1mGjK_Fy29g@mail.gmail.com>
Date: Fri, 11 Jul 2025 16:57:35 +0800
From: Xu Lu <luxu.kernel@...edance.com>
To: Anup Patel <apatel@...tanamicro.com>
Cc: rkrcmar@...tanamicro.com, cleger@...osinc.com, anup@...infault.org, 
	atish.patra@...ux.dev, paul.walmsley@...ive.com, palmer@...belt.com, 
	aou@...s.berkeley.edu, alex@...ti.fr, kvm@...r.kernel.org, 
	kvm-riscv@...ts.infradead.org, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [PATCH v2] RISC-V: KVM: Delegate kvm unhandled
 faults to VS mode

On Fri, Jul 11, 2025 at 4:28 PM Anup Patel <apatel@...tanamicro.com> wrote:
>
> On Thu, Jul 10, 2025 at 7:00 PM Xu Lu <luxu.kernel@...edance.com> wrote:
> >
> > Delegate faults which are not handled by kvm to VS mode to avoid
> > unnecessary traps to HS mode. These faults include illegal instruction
> > fault, instruction access fault, load access fault and store access
> > fault.
> >
> > The delegation of illegal instruction fault is particularly important
> > to guest applications that use vector instructions frequently. In such
> > cases, an illegal instruction fault will be raised when guest user thread
> > uses vector instruction the first time and then guest kernel will enable
> > user thread to execute following vector instructions.
> >
> > The fw pmu event counters remain undeleted so that guest can still get
> > these events via sbi call. Guest will only see zero count on these
> > events and know 'firmware' has delegated these faults.
>
> Currently, we don't delegate illegal instruction faults and various
> access faults to Guest because we allow Guest to count PMU
> firmware events. Refer, [1] and [2] for past discussions.
>
> [1] http://lists.infradead.org/pipermail/linux-riscv/2024-August/059658.html
> [2] https://lore.kernel.org/all/20241224-kvm_guest_stat-v2-0-08a77ac36b02@rivosinc.com/
>
> I do understand that additional redirection hoop can slow down
> lazy enabling of vector state so drop delegating various access
> faults.

Roger that. I will resend the patch and only delegate illegal insn fault.

>
> Regards,
> Anup
>
> >
> > Signed-off-by: Xu Lu <luxu.kernel@...edance.com>
> > ---
> >  arch/riscv/include/asm/kvm_host.h |  4 ++++
> >  arch/riscv/kvm/vcpu_exit.c        | 18 ------------------
> >  2 files changed, 4 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/kvm_host.h b/arch/riscv/include/asm/kvm_host.h
> > index 85cfebc32e4cf..e04851cf0115c 100644
> > --- a/arch/riscv/include/asm/kvm_host.h
> > +++ b/arch/riscv/include/asm/kvm_host.h
> > @@ -44,7 +44,11 @@
> >  #define KVM_REQ_STEAL_UPDATE           KVM_ARCH_REQ(6)
> >
> >  #define KVM_HEDELEG_DEFAULT            (BIT(EXC_INST_MISALIGNED) | \
> > +                                        BIT(EXC_INST_ACCESS)     | \
> > +                                        BIT(EXC_INST_ILLEGAL)    | \
> >                                          BIT(EXC_BREAKPOINT)      | \
> > +                                        BIT(EXC_LOAD_ACCESS)     | \
> > +                                        BIT(EXC_STORE_ACCESS)    | \
> >                                          BIT(EXC_SYSCALL)         | \
> >                                          BIT(EXC_INST_PAGE_FAULT) | \
> >                                          BIT(EXC_LOAD_PAGE_FAULT) | \
> > diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
> > index 6e0c184127956..6e2302c65e193 100644
> > --- a/arch/riscv/kvm/vcpu_exit.c
> > +++ b/arch/riscv/kvm/vcpu_exit.c
> > @@ -193,11 +193,6 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
> >         ret = -EFAULT;
> >         run->exit_reason = KVM_EXIT_UNKNOWN;
> >         switch (trap->scause) {
> > -       case EXC_INST_ILLEGAL:
> > -               kvm_riscv_vcpu_pmu_incr_fw(vcpu, SBI_PMU_FW_ILLEGAL_INSN);
> > -               vcpu->stat.instr_illegal_exits++;
> > -               ret = vcpu_redirect(vcpu, trap);
> > -               break;
> >         case EXC_LOAD_MISALIGNED:
> >                 kvm_riscv_vcpu_pmu_incr_fw(vcpu, SBI_PMU_FW_MISALIGNED_LOAD);
> >                 vcpu->stat.load_misaligned_exits++;
> > @@ -208,19 +203,6 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
> >                 vcpu->stat.store_misaligned_exits++;
> >                 ret = vcpu_redirect(vcpu, trap);
> >                 break;
> > -       case EXC_LOAD_ACCESS:
> > -               kvm_riscv_vcpu_pmu_incr_fw(vcpu, SBI_PMU_FW_ACCESS_LOAD);
> > -               vcpu->stat.load_access_exits++;
> > -               ret = vcpu_redirect(vcpu, trap);
> > -               break;
> > -       case EXC_STORE_ACCESS:
> > -               kvm_riscv_vcpu_pmu_incr_fw(vcpu, SBI_PMU_FW_ACCESS_STORE);
> > -               vcpu->stat.store_access_exits++;
> > -               ret = vcpu_redirect(vcpu, trap);
> > -               break;
> > -       case EXC_INST_ACCESS:
> > -               ret = vcpu_redirect(vcpu, trap);
> > -               break;
> >         case EXC_VIRTUAL_INST_FAULT:
> >                 if (vcpu->arch.guest_context.hstatus & HSTATUS_SPV)
> >                         ret = kvm_riscv_vcpu_virtual_insn(vcpu, run, trap);
> > --
> > 2.20.1
> >
> >