[PATCH 1/2] KVM: x86: ioapic: Set remote_irr only after successful delivery

[PATCH 1/2] KVM: x86: ioapic: Set remote_irr only after successful delivery

[Hao Zhang]

From: Hao Zhang <zhanghao1@kylinos.cn>

The I/O APIC sets remote_irr for level-triggered interrupts to track that
the interrupt has been accepted by a local APIC and that the I/O APIC must
wait for the corresponding EOI before delivering the interrupt again.

But ioapic_service() currently sets remote_irr for any non-zero return
from kvm_irq_delivery_to_apic(). The delivery helper can return -1 when
no destination is found. Treating -1 as success causes KVM to set
remote_irr even though no interrupt was delivered and no EOI will ever
be generated, leaving the pin blocked.

Set remote_irr only when the delivery result is positive, i.e. when at
least one local APIC accepted the interrupt.

Fixes: 4925663a079c ("KVM: Report IRQ injection status to userspace.")
Signed-off-by: Hao Zhang <zhanghao1@kylinos.cn>
---
 arch/x86/kvm/ioapic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 757667fb2bfa..24a7cc3b8b7e 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -491,7 +491,7 @@ static int ioapic_service(struct kvm_ioapic *ioapic, int irq, bool line_status)
 	} else
 		ret = kvm_irq_delivery_to_apic(ioapic->kvm, NULL, &irqe);
 
-	if (ret && irqe.trig_mode == IOAPIC_LEVEL_TRIG)
+	if (ret > 0 && irqe.trig_mode == IOAPIC_LEVEL_TRIG)
 		entry->fields.remote_irr = 1;
 
 	return ret;

base-commit: c21bb4193868a8de71fc4693fa741e195fdf5d86
-- 
2.15.0

[PATCH 2/2] KVM: selftests: Verify IOAPIC doesn't set remote_irr on failed delivery

[Hao Zhang]

From: Hao Zhang <zhanghao1@kylinos.cn>

Add a regression test for level-triggered I/O APIC interrupt delivery
when no local APIC can accept the interrupt.

remote_irr tracks that a level-triggered interrupt has been accepted by a
local APIC and that the I/O APIC must wait for the corresponding EOI before
delivering the interrupt again.  If no local APIC accepts the interrupt,
remote_irr must remain clear, as no EOI will ever be generated.

Configure an I/O APIC redirection entry and inject an I/O APIC-only GSI
before creating any vCPUs.  Verify that KVM_IRQ_LINE_STATUS reports failed
delivery and that KVM_GET_IRQCHIP reports remote_irr clear.

This covers the case where failed delivery returns a negative value and
must not be treated as a successful delivery for remote_irr tracking.

Signed-off-by: Hao Zhang <zhanghao1@kylinos.cn>
---
 tools/testing/selftests/kvm/Makefile.kvm           |  1 +
 .../testing/selftests/kvm/x86/ioapic_state_test.c  | 70 ++++++++++++++++++++++
 2 files changed, 71 insertions(+)
 create mode 100644 tools/testing/selftests/kvm/x86/ioapic_state_test.c

diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 6fc34e9bf8e1..89e3f82e75b0 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -86,6 +86,7 @@ TEST_GEN_PROGS_x86 += x86/hyperv_features
 TEST_GEN_PROGS_x86 += x86/hyperv_ipi
 TEST_GEN_PROGS_x86 += x86/hyperv_svm_test
 TEST_GEN_PROGS_x86 += x86/hyperv_tlb_flush
+TEST_GEN_PROGS_x86 += x86/ioapic_state_test
 TEST_GEN_PROGS_x86 += x86/kvm_clock_test
 TEST_GEN_PROGS_x86 += x86/kvm_pv_test
 TEST_GEN_PROGS_x86 += x86/kvm_buslock_test
diff --git a/tools/testing/selftests/kvm/x86/ioapic_state_test.c b/tools/testing/selftests/kvm/x86/ioapic_state_test.c
new file mode 100644
index 000000000000..3e1badcc391c
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/ioapic_state_test.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Regression tests for in-kernel I/O APIC state.
+ */
+
+#include "kvm_util.h"
+#include "test_util.h"
+
+#define TEST_IOAPIC_PIN		16
+#define TEST_VECTOR		0x50
+#define NO_SUCH_APIC_ID		0xfe
+
+static void get_ioapic(struct kvm_vm *vm, struct kvm_irqchip *irqchip)
+{
+	int r;
+
+	irqchip->chip_id = KVM_IRQCHIP_IOAPIC;
+	r = __vm_ioctl(vm, KVM_GET_IRQCHIP, irqchip);
+	if (r && errno == ENXIO)
+		__TEST_REQUIRE(0, "In-kernel I/O APIC not available");
+
+	TEST_ASSERT(!r, KVM_IOCTL_ERROR(KVM_GET_IRQCHIP, r));
+}
+
+static void set_ioapic(struct kvm_vm *vm, struct kvm_irqchip *irqchip)
+{
+	irqchip->chip_id = KVM_IRQCHIP_IOAPIC;
+	vm_ioctl(vm, KVM_SET_IRQCHIP, irqchip);
+}
+
+static void test_no_remote_irr_for_undelivered_interrupt(void)
+{
+	struct kvm_irq_level irq = {
+		.irq = TEST_IOAPIC_PIN,
+		.level = 1,
+	};
+	struct kvm_irqchip irqchip;
+	struct kvm_vm *vm;
+
+	vm = vm_create_barebones();
+	vm_create_irqchip(vm);
+
+	get_ioapic(vm, &irqchip);
+
+	irqchip.chip.ioapic.redirtbl[TEST_IOAPIC_PIN].fields.vector = TEST_VECTOR;
+	irqchip.chip.ioapic.redirtbl[TEST_IOAPIC_PIN].fields.dest_id = NO_SUCH_APIC_ID;
+	irqchip.chip.ioapic.redirtbl[TEST_IOAPIC_PIN].fields.dest_mode = 0;
+	irqchip.chip.ioapic.redirtbl[TEST_IOAPIC_PIN].fields.trig_mode = 1;
+	irqchip.chip.ioapic.redirtbl[TEST_IOAPIC_PIN].fields.mask = 0;
+	irqchip.chip.ioapic.redirtbl[TEST_IOAPIC_PIN].fields.remote_irr = 0;
+
+	set_ioapic(vm, &irqchip);
+
+	vm_ioctl(vm, KVM_IRQ_LINE_STATUS, &irq);
+	TEST_ASSERT(irq.status == -1,
+		    "Expected failed interrupt delivery, got %d", irq.status);
+
+	get_ioapic(vm, &irqchip);
+	TEST_ASSERT(!irqchip.chip.ioapic.redirtbl[TEST_IOAPIC_PIN].fields.remote_irr,
+		    "KVM set remote_irr for a level-triggered interrupt that wasn't delivered");
+
+	kvm_vm_free(vm);
+}
+
+int main(void)
+{
+	test_no_remote_irr_for_undelivered_interrupt();
+
+	return 0;
+}
-- 
2.15.0

Re: [PATCH 1/2] KVM: x86: ioapic: Set remote_irr only after successful delivery

[Huang, Kai]

On Thu, 2026-08-06 at 21:39 +0800, Hao Zhang wrote:
> From: Hao Zhang <zhanghao1@kylinos.cn>
> 
> The I/O APIC sets remote_irr for level-triggered interrupts to track that
> the interrupt has been accepted by a local APIC and that the I/O APIC must
> wait for the corresponding EOI before delivering the interrupt again.
> 
> But ioapic_service() currently sets remote_irr for any non-zero return
> from kvm_irq_delivery_to_apic(). The delivery helper can return -1 when
> no destination is found. Treating -1 as success causes KVM to set
> remote_irr even though no interrupt was delivered and no EOI will ever
> be generated, leaving the pin blocked.
> 
> Set remote_irr only when the delivery result is positive, i.e. when at
> least one local APIC accepted the interrupt.
> 
> Fixes: 4925663a079c ("KVM: Report IRQ injection status to userspace.")
> Signed-off-by: Hao Zhang <zhanghao1@kylinos.cn>
> ---
>  arch/x86/kvm/ioapic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
> index 757667fb2bfa..24a7cc3b8b7e 100644
> --- a/arch/x86/kvm/ioapic.c
> +++ b/arch/x86/kvm/ioapic.c
> @@ -491,7 +491,7 @@ static int ioapic_service(struct kvm_ioapic *ioapic, int irq, bool line_status)
>  	} else
>  		ret = kvm_irq_delivery_to_apic(ioapic->kvm, NULL, &irqe);
>  
> -	if (ret && irqe.trig_mode == IOAPIC_LEVEL_TRIG)
> +	if (ret > 0 && irqe.trig_mode == IOAPIC_LEVEL_TRIG)
>  		entry->fields.remote_irr = 1;
>  
>  	return ret;
> 
> base-commit: c21bb4193868a8de71fc4693fa741e195fdf5d86

This seems reasonable to me.  Just wondering did you meet any real bug?

Btw, currently the IRQ is set to irr_delivered for level-triggered IRQ
regardless of the return value of kvm_irq_delivery_to_apic():

        if (irqe.trig_mode == IOAPIC_EDGE_TRIG)                                
                ioapic->irr_delivered |= 1 << irq;           

        if (irq == RTC_GSI && line_status) {                                   
		...                                                                          
        } else                                                                 
                ret = kvm_irq_delivery_to_apic(ioapic->kvm, NULL, &irqe);

	...

Similarly, should this only be done when kvm_irq_delivery_to_apic() returns
positive?

E.g., kvm_get_ioapic() clears the bits in irr_delivered, so if one IRQ is set in
it but actually not accepted by LAPIC then kvm_get_ioapic() will not return such
IRQ in irr, therefore it can potentially be lost?