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: <D7X576NHG512.2HBBO3JLIA1JH@ventanamicro.com>
Date: Thu, 20 Feb 2025 09:50:06 +0100
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "xiangwencheng" <xiangwencheng@...xincomputing.com>, "Andrew Jones"
 <ajones@...tanamicro.com>
Cc: <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

2025-02-20T16:17:33+08:00, xiangwencheng <xiangwencheng@...xincomputing.com>:
>> From: "Andrew Jones"<ajones@...tanamicro.com>
>> On Thu, Feb 20, 2025 at 03:12:58PM +0800, xiangwencheng wrote:
>> > 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.

(Configure your mail client, so it doesn't add a newline between each
 quoted line when replying.)

>> > So I still think is not necessary to call another kvm_vcpu_kick after writing to
>> > VS_FILE.

So the kick wasn't there to mask some other bug, thanks.

>> 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.

The wakeup is asynchronous, and this would practically never avoid the
host interrupt, but we'd do extra pointless work...
I think it's much better just with the write.  (The wakeup would again
make KVM look like it has a bug elsewhere.)