On Tue, Mar 25, 2025, bibo mao wrote: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.
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.
And if the IRQ that triggered VM-Exit is for the host's tick, then it's desirableLoongArch 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.
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
VM-Exit, then manually calling the interrupt handler from KVM will result in everyBy 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.
IRQ effectively happening twice: once on the manual call, and against when KVM
enables IRQs and the "real" IRQ fires.