linux-kernel - Re: [PATCH] riscv: KVM: Remove unnecessary vcpu kick

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250220-f9c4c4b3792a66999ea5b385@orel>
Date: Thu, 20 Feb 2025 09:01:28 +0100
From: Andrew Jones <ajones@...tanamicro.com>
To: xiangwencheng <xiangwencheng@...xincomputing.com>
Cc: Radim Krčmář <rkrcmar@...tanamicro.com>, 
	anup@...infault.org, kvm-riscv@...ts.infradead.org, kvm@...r.kernel.org, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, atishp@...shpatra.org, 
	paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu, 
	linux-riscv <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH] riscv: KVM: Remove unnecessary vcpu kick

On Thu, Feb 20, 2025 at 03:12:58PM +0800, xiangwencheng wrote:
...
> As "KVM:  WFI wake-up using IMSIC VS-files" that described in [1], writing to 
> VS-FILE will wake up vCPU.
> 
> KVM has also handled the situation of WFI. Here is the WFI emulation process:
> kvm_riscv_vcpu_exit 
>     -> kvm_riscv_vcpu_virtual_insn 
>          -> system_opcode_insn 
>               -> wfi_insn 
>                  -> kvm_riscv_vcpu_wfi
>                      -> kvm_vcpu_halt
>                          -> kvm_vcpu_block
>                              -> kvm_arch_vcpu_blocking
>                                    -> kvm_riscv_aia_wakeon_hgei
>                                          -> csr_set(CSR_HGEIE, BIT(hgei));
>                              -> set_current_state(TASK_INTERRUPTIBLE);
>                              -> schedule
> 
> In kvm_arch_vcpu_blocking it will enable guest external interrupt, which
> means wirting to VS_FILE will cause an interrupt. And the interrupt handler
> hgei_interrupt which is setted in aia_hgei_init will finally call kvm_vcpu_kick
> to wake up vCPU.
> 
> So I still think is not necessary to call another kvm_vcpu_kick after writing to
> VS_FILE.
> 
> Waiting for more info. Thanks.
> 
> [1]  https://kvm-forum.qemu.org/2022/AIA_Virtualization_in_KVM_RISCV_final.pdf
>

Right, we don't need anything since hgei_interrupt() kicks for us, but if
we do

@@ -973,8 +973,8 @@ int kvm_riscv_vcpu_aia_imsic_inject(struct kvm_vcpu *vcpu,
        read_lock_irqsave(&imsic->vsfile_lock, flags);

        if (imsic->vsfile_cpu >= 0) {
+               kvm_vcpu_wake_up(vcpu);
                writel(iid, imsic->vsfile_va + IMSIC_MMIO_SETIPNUM_LE);
-               kvm_vcpu_kick(vcpu);
        } else {
                eix = &imsic->swfile->eix[iid / BITS_PER_TYPE(u64)];
                set_bit(iid & (BITS_PER_TYPE(u64) - 1), eix->eip);

then we should be able to avoid taking a host interrupt.

Thanks,
drew