qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 00/15] Refactor PC machine to take advantage of QO


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC 00/15] Refactor PC machine to take advantage of QOM
Date: Thu, 26 Jan 2012 14:00:04 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

On 01/26/2012 01:57 PM, Markus Armbruster wrote:
Peter Maydell<address@hidden>  writes:

On 26 January 2012 19:00, Anthony Liguori<address@hidden>  wrote:
We need to modeled MemoryRegions and qemu_irq in QOM too.

+1 : this ought to let us get rid of SysBus...

  MemoryRegions
shouldn't be that difficult.  Our habit of passing qemu_irq's as arrays without
an explicit size will probably require some refactoring but in principle,
supporting irqs should be easy too.

I think that there are probably a lot of cases where we're using an array
of qemu_irqs now but should be using separately named signals of some sort
instead (particularly where we're using them for things which aren't actually
IRQs...)

Apropos array of qemu_irq: we're leaking them in several places.
qemu_allocate_irqs() returns a pointer to an array of qemu_irq whose
elements to point into an array of *qemu_irq.  Both arrays are malloced.

Many callers ask for just one IRQ like this:

     *qemu_allocate_irqs(..., 1)

This leaks the array of qemu_irq.

There are other, less obvious leaks of the returned array.

We leak lots of stuff...

One nice thing in QOM is that we can create child devices that use the parent device's resources and tie the life cycles together.

So whereas we were leaking all sorts of MemoryRegions and qdev devices before, with this series, we do it a whole lot less.

Same principle will apply to IRQs.

Regards,

Anthony Liguori






reply via email to

[Prev in Thread] Current Thread [Next in Thread]