On 07/11/2011 06:47 PM, Peter Maydell wrote:
On 11 July 2011 16:29, Paolo Bonzini<pbonz...@redhat.com> 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