Re: [RFC 5/7] system: add qemu_irq_new / qemu_irq_new_child / qemu_irq_new_array

[Mark Cave-Ayland <mark.caveayland@nutanix.com>]

On 16/06/2026 17:22, Peter Maydell wrote:

> On Tue, 16 Jun 2026 at 16:57, Daniel P. Berrangé <berrange@redhat.com> 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é <berrange@redhat.com>
>> ---
>>   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.