Re: [Qemu-devel] qdev for programmers writeup

[Peter Maydell]

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? 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.)

>> So if
>> we want to allow runtime configurability of boards like that we need
>> to do it by providing runtime configurability of sysbus devices.
>
> But we already have properties as a runtime configurability mechanism, and
> the additional functionality provided by SysBus is exactly to bypass it.  In
> that sense SysBus is bad (if used widely as it is now).
>
> It is also bad because SysBus takes device metainformation (number of IRQ
> lines, size of MMIO and PIO areas) and puts it into per-device structure.

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. It's also an
easy to use API for machine models to instantiate and wire up both IRQs
and memory mappings. If we want less use of sysbus then we need to have
the basic qdev device model have much better support for doing this.

>> I think it would be better to think of GPIO as a special (simple)
>> case of a generic desire to plug devices into each other (this is what
>> SystemC calls a "port": basically an interface (API) defined so that
>> two things can make calls to arbitrary callback functions on the other
>> end of a connection). How ports are wired up is a property of the
>> machine model, not a property of the device at either end
>
> But in practice you tend to have tree-like relationships.  Even if it is
> just a two-level tree with a GPIO chip or interrupt controller at one end,
> and everything else at the other.

Yes, but the tree-like relation of the memory transaction bus/interconnect
isn't necessarily the same as the tree-like relation of the interrupt
controllers; and the tree-like relation of the clocks might be different
again. 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.
Insisting that interrupts are always a tree also rules out ever having
qemu support multiple distinct CPUs where some interrupt sources end up
going to more than one CPU; I'd rather we didn't bake that kind of
assumption into the core device model if possible.

(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.)

-- PMM