Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

[Peter Maydell <peter.maydell@linaro.org>]

On 26 July 2011 15:02, Anthony Liguori <anthony@codemonkey.ws> wrote:
> In my attempt at PCI modelling, I had something like:
>
> struct I440FX
> {
>   Device parent;
>
>   PciDevice slots[32];
> };
>
> Which means that to attach to bus 0, slot 3, fn 0, you do:
>
> i440fx->slots[3] = mydevice

So what I don't really understand about this model is why the PCI
connection is "privileged" in the sense that 'mydevice' is actually
an instance of something you can stick directly into one of the PCIBus
device's slots. I would expect that 'mydevice' would have a bunch of
(effectively) interfaces it exposed, and you'd connect i440fx->slots[3]
to mydevice.pciconnector or something. [Which ought to both let the
PCIBus call functions implemented by the device, and vice versa.]

(What would a model of a two-PCI-slot graphics card look like?)

Maybe it would be better to use some other example. After all, the
cases like PCI are the ones our device model already handles pretty
well, so the interesting cases to look at are where we're not so
good at it. What does the implementation of omap2_gpio look like,
for instance? (it's not qdev at the moment but there's a set of
patches on the list which make it so; the guts of the qdevification
are http://patchwork.ozlabs.org/patch/103905/ .)
 That's a device which exposes:
 * 4,5, or 6 MMIO regions (depending on how many 'modules' the
   particular revision you ask for has)
 * a variably sized array of gpio inputs
 * ditto, gpio outputs
 * for each 'module', three specific named outgoing gpio lines
   "mpu_irq", "dsp_irq" and "wakeup"
 * a number of omap_clk connections, where an omap_clk* represents
   a connection to the OMAP clock tree, and in practice is an
   interface where the omap_gpio can (a) call a function to
   ask "what rate is this clock running at?" and (b) provide
   a gpio line which will be raised when the clock ticks.
   [omap_gpio doesn't actually use its clock connections but
   other omap devices do; they're interesting because we have
   function calls going in both directions over the interface.]

None of these exposed interfaces are particularly obviously
more important than any of the others -- they're just all
things that might need to be wired up.

I'm particularly interested in how much effort is involved
in defining ad-hoc platform-specific interface types like
omap_clk.

-- PMM