qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <eduardo@habkost.net>
Subject: [RFC PATCH] hw/timer/hpet: fix IRQ routing in legacy support mode
Date: Wed, 30 Aug 2023 21:20:21 +0100	[thread overview]
Message-ID: <6c1f2ced5b329a86a5c6846fb8530f2f1a845a44.camel@infradead.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2970 bytes --]

From: David Woodhouse <dwmw@amazon.co.uk>

The interrupt from timer 0 in legacy mode is supposed to go to IRQ 0 on
the i8259 and IRQ 2 on the I/O APIC. The generic x86 GSI handling can't
cope with IRQ numbers differing between the two chips (despite it also
being the case for PCI INTx routing), so add a special case for the HPET.

IRQ 2 isn't valid on the i8259; it's the cascade IRQ and would be
interpreted as spurious interrupt on the secondary PIC. So we can fix
up all attempts to deliver IRQ2, to actually deliver to IRQ0 on the PIC.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
It ain't ever so pretty, but it's prettier than the INTx routing hack
that I just documented and at least this one doesn't rely on guest
behaviour.

Do we have tests for HPET interrupt delivery that can be extended to
cover this?


 hw/i386/x86.c   | 19 +++++++++++++++----
 hw/timer/hpet.c |  5 ++++-
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index a88a126123..0d2c74f2d9 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -602,13 +602,24 @@ DeviceState *cpu_get_current_apic(void)
 void gsi_handler(void *opaque, int n, int level)
 {
     GSIState *s = opaque;
-
+    int i8259_pin = n;
     trace_x86_gsi_interrupt(n, level);
     switch (n) {
-    case 0 ... ISA_NUM_IRQS - 1:
-        if (s->i8259_irq[n]) {
+    case 2:
+        /*
+         * Special case for HPET legacy mode, which is defined as routing HPET
+         * timer 0 to IRQ2 of the I/O APIC and IRQ0 of the i8259 PIC. Since
+         * IRQ2 on the i8259 is the cascade, it isn't otherwise valid so we
+         * handle it via this special case.
+         */
+        i8259_pin = 0;
+        /* fall through */
+    case 0:
+    case 1:
+    case 3 ... ISA_NUM_IRQS - 1:
+        if (s->i8259_irq[i8259_pin]) {
             /* Under KVM, Kernel will forward to both PIC and IOAPIC */
-            qemu_set_irq(s->i8259_irq[n], level);
+            qemu_set_irq(s->i8259_irq[i8259_pin], level);
         }
         /* fall through */
     case ISA_NUM_IRQS ... IOAPIC_NUM_PINS - 1:
diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
index 6998094233..9f740ffdee 100644
--- a/hw/timer/hpet.c
+++ b/hw/timer/hpet.c
@@ -196,8 +196,11 @@ static void update_irq(struct HPETTimer *timer, int set)
         /* if LegacyReplacementRoute bit is set, HPET specification requires
          * timer0 be routed to IRQ0 in NON-APIC or IRQ2 in the I/O APIC,
          * timer1 be routed to IRQ8 in NON-APIC or IRQ8 in the I/O APIC.
+         *
+         * There is a special case in the x86 gsi_handler() which converts
+         * IRQ2 into IRQ0 for the i8259 PIC and makes this work correctly.
          */
-        route = (timer->tn == 0) ? 0 : RTC_ISA_IRQ;
+        route = (timer->tn == 0) ? 2 : RTC_ISA_IRQ;
     } else {
         route = timer_int_route(timer);
     }
-- 
2.34.1



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]

             reply	other threads:[~2023-08-30 20:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30 20:20 David Woodhouse [this message]
2023-10-17 21:24 ` [RFC PATCH] hw/timer/hpet: fix IRQ routing in legacy support mode David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c1f2ced5b329a86a5c6846fb8530f2f1a845a44.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=eduardo@habkost.net \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).