Re: [Qemu-devel] qdev for programmers writeup

[Peter Maydell]

On 11 July 2011 13:48, Paolo Bonzini <address@hidden> wrote:
> On 07/11/2011 12:46 PM, Peter Maydell wrote:
>>Paolo wrote:
>>> Together with such
>>> a bus type there should be a single root board-specific device that is
>>> attached to SysBus.  An interrupt controller is usually a good candidate
>>> for this because it takes qemu_irqs from the outside, and can make good
>>> use of the specificities of SysBus.
>>
>> ...and this bit I don't understand. Why is SysBus a bad thing?
>
> 1) because SysBus devices are in general not accessible from the
> command-line or configuration files.
>
> 2) because SysBus hardcodes in the source code some things that ought to be
> device properties, for example the MMIO base address.  The presence of MMIO
> in sysbus_create_simple/sysbus_create_varargs is totally unnecessary IMHO.

MMIO base address shouldn't be a device property anyway -- it is
a property of the machine (board) model, ie "how am I wiring up
these devices?", not a property of the device itself.

>> It generally seems to me to be the right way to represent a bit of
>> hardware which is fundamentally providing a memory mapped interface
>> plus some GPIO lines. If you make your board use sysbus then it's
>> easy to just plug in any existing sysbus device model qemu already
>> has; if every board has its own bus type instead then this reuse
>> just becomes unnecessarily harder, it seems to me.
>
> That's true, but the only way to plug in those device models would be with C
> code.  You cannot just play with -device to reconfigure them.

I think the C source level reuse is more important and more useful
than plugging stuff around with -device, because in practice messing
about with the memory map of an embedded board isn't something people
typically want to do, because the kernel will have more-or-less
hardcoded where the devices are anyhow. (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.) So if
we want to allow runtime configurability of boards like that we need
to do it by providing runtime configurability of sysbus devices.
(which approximately equates to runtime script-driven machine models).

> In fact, perhaps qdev_{connect_gpio_out,get_gpio_in} should never have been
> public.  Imagine we added to qdev GPIO properties and we used them like this
> in gpio_i2c:
>
>    /* gpio_out=N means "connect my 0th output pin to the parent's
>       N-th input pin.  */
>    DEFINE_PROP_GPIO_OUT("gpio_out", 0),
>
>    /* gpio_in=N means "connect my 0th input pin to the parent's
>       N-th output pin.  */
>    DEFINE_PROP_GPIO_IN("gpio_in", 0),
>    DEFINE_PROP_GPIO_IN("gpio_clk", 1)

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, and I think
it is better for the syntax not to mix up ports and properties.

Also, you want to be able to actually name your output pins, so
at a board level you can talk about wiring up sd_controller.wprot,
not sd_controller.gpio[3]... (Yes, this is to some extent "just syntax"
but I really don't want to end up with machine level modelling looking
like:

>    [device "gpio_i2c"]
>        gpio_out = 29
>        gpio_in = 3
>        gpio_clk = 4

...because that's just not really maintainable IMHO.)

>> Also having the interrupt controller be the board specific device
>> which you attach to sysbus seems totally wrong to me. This doesn't
>> match hardware at all -- the interrupt controller deals with
>> interrupt lines and isn't in the path for memory transactions at
>> all.
>
> Well, it is clear that buses should be modelled after the way data flows.
>  But what is data?  If data is "what is being written", buses should be
> modelled after the way memory transactions flow.  If data is "what is being
> made available", buses are modelled more "after the way interrupts flow.
>  GPIO is a strange thing in the middle. :)

Actually I think we should really be modelling buses only where the
hardware actually has a bus, ie a coherent collection of signals
between multiple devices such that you could in theory plug in
different devices in different slots. The memory transaction
related connections are much more buslike than interrupt wiring.

-- PMM