[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 21/22] i8259_common.c: remove static irq_count and irq_level variables


  • To: Peter Maydell <peter.maydell@xxxxxxxxxx>
  • From: Mark Cave-Ayland <mark.caveayland@xxxxxxxxxxx>
  • Date: Wed, 14 Oct 2026 12:24:21 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5Y42nFX1SuoOHfoLk9XCJ3MgIlx+bFXAwAy9V4CsUow=; b=qLRB5O2r9K7k/bn/4rk5JUozlVHaBZ7BwY29Nx0Tl8zQqdogjE0mG4kxJ33SS49o6290H9A6ergXv/4WWyBRaDlTE/LuziB+j0e56WYfw4nCUCNf6hWwa0PHIplrFqIGPtVymOh5/qvFguYmGQwaF5Uuqkth6MRGwMwo8XwmoFuX8jULMZIGD6Gdmfdt6lhmcTwD6CYr0f4uydjxfq+ZOueZQHzNi6OSKi1qljBZ7+XObHj1JQcX0u0+AMd/g8uDA1dx3AHvWJbbL5GVTrPmqG4eNTJDq1mmp9ltXe9ScCP8+FwqRya69JFzZSyI7aVCU3p15+gNwNDJXqRiuNRp5Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UCnQJtU4oJx/P6P5towLLsFKmKBSCv0qErSwC+FmP54QmB+m6L37KUJJ1zEwipnRrhDh5epxPPJ1dxQM7bs/Knw5mwJqmPpQjC2xhctd2ZHjqgQrCrCpWezMK/K0mrpAdAzUDbOLIorrrq7Vf/GwfGG2N0zWvRHC91c4auaEHYHaIxzPOSNj11h5yGhG21+hpRnU8ccPulHt4MdCG/ZK/ey6mMs7bx/oINEQBX0gOnkPQgQTuqCtXtAofn5KefG8/CXXusU3XDHicS6qaT6R8wfOMdjGSXhzgYnyVrU+7vuRcOho2/F0YdOjt7WmD85w2P6t0xK/rPO5vz+kVAdCKg==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nutanix.com;
  • Cc: pbonzini@xxxxxxxxxx, richard.henderson@xxxxxxxxxx, mst@xxxxxxxxxx, sstabellini@xxxxxxxxxx, anthony@xxxxxxxxxxxxxx, edgar.iglesias@xxxxxxxxx, qemu-devel@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 14 Oct 2026 11:24:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 13/10/2026 17:29, Peter Maydell wrote:

On Wed, 16 Sept 2026 at 11:50, Mark Cave-Ayland
<mark.caveayland@xxxxxxxxxxx> wrote:

Adjust the parameters to i8259_stat_update_irq() to allow passing in pointers
to the irq_count and irq_level arrays, and then move the arrays into the
corresponding i8259 PIC and KVM PIC devices.

Doing this allows the statistics capture logic in i8259_set_irq() that handles
incoming cascading interrupts to be removed.

Signed-off-by: Mark Cave-Ayland <mark.caveayland@xxxxxxxxxxx>

diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c
index 421c9279cd..ca661afc02 100644
--- a/hw/i386/kvm/i8259.c
+++ b/hw/i386/kvm/i8259.c
@@ -30,6 +30,9 @@ struct KVMI8259PICState {

      ISABus *isabus;
      I8259CommonState i8259[2];
+
+    int irq_level[ISA_NUM_IRQS];
+    uint64_t irq_count[ISA_NUM_IRQS];
  };


diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c
index 3f10777036..ac43995ce4 100644
--- a/hw/intc/i8259.c
+++ b/hw/intc/i8259.c
@@ -49,14 +49,16 @@ struct I8259PICState {
      ISABus *isabus;
      IRQState i8259_primary_out_irq;
      I8259CommonState i8259[2];
+
+    int irq_level[ISA_NUM_IRQS];
+    uint64_t irq_count[ISA_NUM_IRQS];
+#ifdef DEBUG_IRQ_LATENCY
+    int64_t irq_time[ISA_NUM_IRQS];
+#endif
  };

Would it make sense for these two types to have a common base
class (where the stats stuff could then live)? AIUI they're
both intending to provide the same interface ("pair of i8259
devices cascaded together in the way that x86 does it").
I did consider this in development since it would avoid the duplication here (and potentially in both realize() methods), but wasn't sure the extra complexity of the object hierarchy was worth it.

However since you've also raised the idea, I'll have a look at this and add it to v2 if it looks good.


ATB,

Mark.




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.