|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC 00/15] Refactor PC machine to take advantage of QOM |
Date: | Thu, 26 Jan 2012 13:36:18 -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:12 PM, Peter Maydell wrote:
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...)
I started hacking up a Pin object that used a Notifier. It's pretty easy to plumb that to an existing qemu_irq so I think that's the way to go.
That way we could incrementally remove qemu_irq usage.I started with this path but the pc initialization was so fubar that I ran into too many problems. Now I think I can go back and do it again and it will be more reasonable given this refactoring.
At a high level, a Pin object looks and feels like a qemu_irq. There's a pin_raise, pin_set_level, etc. But there is also a pin_get_level() (it's stateful) and there's a pin_add_level_change_notifier() which allows you to register.
Pins are objects so they can be added to the composition tree which means they can be addressed. If you have a truly unidirectional path, then you can just use a child and link and connect them that way.
For a bidirectional path (where software controls the direction at run time), you can have an intermediate Wire object which consists of two Pin links.
Regards, Anthony Liguori
-- PMM
[Prev in Thread] | Current Thread | [Next in Thread] |