Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()

[Paolo Bonzini]

Il 13/04/2012 12:43, Peter Maydell ha scritto:
> On 13 April 2012 11:24, Paolo Bonzini <address@hidden> wrote:
>> The PC has a similar model but it is implemented with N+1 devices, one
>> APIC per CPU plus the IO-APIC.
>>
>> For the ARM, it seems cleaner to me to also split it into a per-CPU
>> object (gic_cpu_ops) and a connection object (gic_dist_ops +
>> gic_thiscpu_ops)---even if the per-CPU object are just thin forwarders
>> because the logic is embedded in a single device.
> 
> I'm against this because it's not modelling the hardware. The
> actual silicon is a single block of functionality with a number
> of configurable knobs/pins/memory regions

Well, it's configurable at synthesis time.  You're trying to model
things like VHDL generate statements, which just do not exist in C.
Modeling what you do in VHDL *and* keeping configurability is going to
be hard anyway.

In fact, if you want to model real hardware the real GIC does have a
"backdoor" to the SoC that contains it (the "number of CPUs" constant is
probably set in some VHDL file that is shared by SoC and GIC source code).

> , and I think trying
> to impose a boundary that doesn't exist in reality isn't going
> to work. The only sane forwarding you could do for the gic_cpu_ops
> objects would be to forward the reads and writes entirely untouched.

Yes, that would be it.

For the MPTimer it could also make sense to do things the other way
round: place the timer as a child of the CPU, and add a global device
that just forwards to the current CPU's timers.  You could choose
between consistency and simplicity.

> That's just a silly special case wrapper around a MemoryRegion and
> I don't see that it helps.

It helps because it avoids having N of this, N of that, and N of the
other.  You can just have N CPUBlock objects, each of which has-a CPU,
an interface to the GIC, an interface to the MPTimer, etc.

    /machine            the SoC object
       /cpu[0]          a CPUBlock object
          /cpu          the actual ARMCPU
          /gic_intf     a forwarder to the global GIC object
          /timer        an MPTimerBlock
          /watchdog     an MPTimerBlock
       /cpu[1]          another CPUBlock object
          /cpu
          /gic_intf
          /timer
          /watchdog
       ...
       /gic             the configurable GIC
       /mptimer         a forwarder to the current CPU's timer objects

(The above view is only the children: you would also have a
/machine/cpu[0]/gic link to /machine/gic etc.  However, you wouldn't
need a link from /machine/cpu[0]/timer to /machine/mptimer).

> Also from the point of view of a user of the GIC (ie the SoC
> level containers) you don't want to be messing about instantiating
> lots of different objects and connecting them together. You want
> to configure and instantiate one object, the GIC, and wire it up in
> the obvious way: by mapping the memory regions it exposes at
> the locations you require and by wiring up the irq/gpio lines
> to your own irq/gpio lines.

Yes, all this would be hidden in the init and/or realize functions for
CPUBlock.

Paolo