On 16/06/2026 17:22, Peter Maydell wrote:
On Tue, 16 Jun 2026 at 16:57, Daniel P. Berrangé <[email protected]> wrote:
Prepare for the move to dynamically allocated IRQ objects by
introducing qemu_irq_new / qemu_irq_new_child / qemu_irq_new_array
functions which call through to object_new instead of object_initialize.
Signed-off-by: Daniel P. Berrangé <[email protected]>
---
hw/core/irq.c | 35 ++++++++++++++++++++
include/hw/core/irq.h | 75 ++++++++++++++++++++++++++++++++++++++++---
2 files changed, 106 insertions(+), 4 deletions(-)
diff --git a/hw/core/irq.c b/hw/core/irq.c
index 106805e241..e943c87b81 100644
--- a/hw/core/irq.c
+++ b/hw/core/irq.c
@@ -49,6 +49,13 @@ void qemu_init_irq(IRQState *irq, qemu_irq_handler handler,
void *opaque,
init_irq_fields(irq, handler, opaque, n);
}
+IRQState *qemu_irq_new(qemu_irq_handler handler, void *opaque, int n)
+{
+ IRQState *irq = IRQ(object_new(TYPE_IRQ));
+ init_irq_fields(irq, handler, opaque, n);
+ return irq;
+}
Isn't this the same as the existing qemu_allocate_irq() ?
(I have over the past few years occasionally been trying to get rid
of existing uses of qemu_allocate_irq() and its cousin
qemu_allocate_irqs(), because they are persistent sources of memory
leaks. The function returns a pointer that the caller has to deal
with and remember to free, whereas using e.g. qdev_init_gpio_*()
makes the new irq objects children of the device they belong to,
so they're automatically freed when the device is destroyed.
qemu_init_irq_child() similarly.)
Indeed, this is another case where we'd want to use
qemu_init_irq_child() since then it automatically gets cleaned up when
the refcount hits zero.
And your point about the similarity of qdev GPIOs is also valid: in
particular with Marc-André's recent work on property arrays, it feels
like we're getting closer to being able to converge everything IRQ and
GPIO-related into a single refcounted implementation.
ATB,
Mark.
