Re: [Qemu-devel] qdev for programmers writeup

[Paolo Bonzini]

On 07/11/2011 06:47 PM, Peter Maydell wrote:
> On 11 July 2011 16:29, Paolo Bonzini<address@hidden>  wrote:
> > On 07/11/2011 04:44 PM, Peter Maydell wrote:
> > > (Also if you have one bus type
> > > per board then you're still very limited in what you can do with -device
> > > because you can't plug in some random other sysbus device anyway.)
> >
> > I'm not talking about one bus type per board!  I'm talking about as few as
> > possible board-specific root devices, and sharing buses between boards as
> > much as possible.
>
> Er, doesn't that just get you sysbus again?

It does get you a bus that can be reused by devices.  It doesn't get you 
a bus that is a pot-pourri of features, some of which are not even 
meaningful in the context of all boards (e.g. PIO), and some of which 
override the run-time reconfigurability mechanisms that qdev has built-in.

By the way, while it's true that run-time reconfigurability does not buy 
you much in terms of adding devices---at least without a device tree in 
the guest---it can help in terms of removing devices for debugging.

If a device only needs MMIO and no GPIO/IRQ pins, it probably can stay 
under SysBus.  However, I don't believe the magic MMIO functionality of 
SysBus is useful, and I do think it should be replaced by properties.

> Also if you have a root device
> and it's not the CPU then something's a bit odd. (The CPU lives above
> the interrupt controller in the interrupt tree if you want to look at it
> like that.)

If you consider the CPU to be hidden beyond sysbus, then yes, you do 
have CPU->SysBus->PIC.  It is interesting that in the PC the devices 
below SysBus are indeed mostly managing interrupts:

    CPU->SysBus->LAPIC(s)
                 IOAPIC
                 HPET
                 i440FX-pcihost
                 fw_cfg

I think the PC's fw_cfg device should move below the ISA bridge; and the 
HPET is there only because there is no single device for the northbridge 
chip.  It should perhaps be more like

    CPU->SysBus->LAPIC(s)
                 i440FX-nb->i440FX-pcihost
                            IOAPIC
                            HPET
                            i8259

> I think the real reason so many devices use sysbus is that it is basically
> "I'm a device and I support some gpio signals and some memory mappings",
> which is just a very natural way to model a lot of things.

I agree that sysbus is convenient sugar right now, and we need that 
sugar to be available at all levels (not just sysbus), but you don't 
need sysbus to express that.

There is actually one thing that I'd save in sysbus, and that is IRQs. 
That is because GPIO pins provided by qdev work in one direction only. 
If you want to have interrupt/GPIO sources both towards the children and 
towards the parent, it doesn't work well.  This is a nice niche that 
sysbus IRQs fit in; a GPIO chip can use gpio_in/gpio_out towards the 
children, and sysbus IRQs towards the parent, giving nice separation.

> And even if things tend to be tree-like, you still need to support
> arbitrary inter-wiring for the corner cases (like "this MMC controller's
> 'card present' wire needs to connect to the board-register model's input").
> You can model trees with arbitrary interconnections, but not vice-versa.

Yes, any slot/socket mechanism for run-time reconfigurability of GPIO or 
IRQ connections needs to take into account the possibility of connecting 
siblings (or even completely disconnected devices).  Right now that is 
limited to C code.  But since a GPIO/IRQ is simply a pointer, adding 
such a mechanism would be be just syntax to name the devices' GPIO/IRQ 
slots.

But in any case you will need a preferred topology defined somewhere, 
because code needs more than a bunch of qemu_irqs.  Since they know that 
the model is a tree, qdevified devices can exploit their parent-child 
relationship and you can use that to tie the parent and child in more 
specific ways with virtual functions.  It's quite fundamental.  This can 
stay even if you turn the preferred topology into a DAG, or into the 
superposition of many trees.

> (This view of the world, which I accept is not really qdev's, says that
> a bus is really just a conveniently named and manipulable bundle of
> connections.)

I see qbuses as a conveniently named and pluggable set of callbacks 
(including qemu_irq callbacks whenever that's convenient). 
Alternatively, it's the point where the children's sockets are joined to 
the children's slots we're forced by qdev to make all sockets meet their 
slots in the same place---i.e. on the same qbus).

Paolo