linux-kernel - Re: [RFC V2] LoongArch: KVM: Handle interrupt early before enabling irq

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: <310c31c9-226a-3417-2a76-e7cbc97f169f@loongson.cn>
Date: Thu, 27 Mar 2025 11:16:18 +0800
From: bibo mao <maobibo@...ngson.cn>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Huacai Chen <chenhuacai@...nel.org>,
 Tianrui Zhao <zhaotianrui@...ngson.cn>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [RFC V2] LoongArch: KVM: Handle interrupt early before enabling
 irq


On 2025/3/26 下午11:09, Sean Christopherson wrote:
> On Tue, Mar 25, 2025, bibo mao wrote:
>> Hi Paolo, Sean
>>
>> This idea comes from x86, do you have any guidance or suggestion about it?
>>
>> Also I notice that there is such irq_enable()/irq_disable() pair on x86, I
>> do not know why it is so.
> 
> Because on AMD (SVM), IRQ VM-Exits don't consume the IRQ, i.e. the exit is purely
> a notification.  KVM still needs to enable IRQs to actually handle the pending IRQ.
Good design. Previously only on some realtime HW platforms HW interrupt 
can be configured with high priority event. So with this, IRQ will 
trigger VM-Exits however no IRQ context since it is treated async event.

> And if the IRQ that triggered VM-Exit is for the host's tick, then it's desirable
> to handle the tick IRQ before guest_timing_exit_irqoff() so that the timeslice is
> accounted to the guest, not the host (the tick IRQ arrived while the guest was
> active).
> 
> On Intel (VMX), KVM always runs in a mode where the VM-Exit acknowledge/consumes
> the IRQ, and so KVM _must_ manually call into the appropriate interrupt handler.
> 
>>      local_irq_enable();
>>      ++vcpu->stat.exits;
>>      local_irq_disable();
>>      guest_timing_exit_irqoff();
>>      local_irq_enable();
>>
>> Regards
>> Bibo Mao
>>
>> On 2025/3/11 下午3:47, Bibo Mao wrote:
>>> If interrupt arrive when vCPU is running, vCPU will exit because of
>>> interrupt exception. Currently interrupt exception is handled after
>>> local_irq_enable() is called, and it is handled by host kernel rather
>>> than KVM hypervisor. It will introduce extra another interrupt
>>> exception and then host will handle irq.
>>>
>>> If KVM hypervisor detect that it is interrupt exception, interrupt
>>> can be handle early in KVM hypervisor before local_irq_enable() is
>>> called.
> 
> The correctness of this depends on how LoongArch virtualization processes IRQs.
> If the IRQ is consumed by the VM-Exit, then manually handling the IRQ early is
> both optimal and necessary for correctness.  If the IRQ is NOT consumed by the
LoongArch KVM is similiar with Intel vmx, host intterrupt causes 
VM-Exit, and also there will be extra interrupt exception if 
local_irq_enable() is called in VM-Exit path.


> VM-Exit, then manually calling the interrupt handler from KVM will result in every
> IRQ effectively happening twice: once on the manual call, and against when KVM
By test on LoongArch platform, manual call about IRQ handler at early 
stage will lower interrupt level and ack IRQ. IRQ will not trigger 
again. So I think it is consumed by the VM-Exit.

And thanks for your guidance.

Regards
Bibo Mao
> enables IRQs and the "real" IRQ fires.
>