qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()
Date: Fri, 13 Apr 2012 12:24:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

Il 13/04/2012 12:09, Peter Maydell ha scritto:
>> The GIC can have a (strongly-typed) backlink to the SoC, and can call
>> object_property_get on it.
> 
> The trouble with this is that the GIC is embedded into about
> half a dozen different parent devices, all of which obviously
> have different types.

They can have a common superclass.  But you _can_ also make it a
property; right now there is no way to guess how comfortable that will
be, but we *should* make it comfortable.

It can be done by using three-stage initialization, either in the few
objects that need it or in DeviceState.

>>>>> I'm not sure what your GICInterface children are?
>>>>
>>>> Those would model the GIC<->CPU interface memory regions.
>>>
>>> MemoryRegions model memory regions :-) I'm not sure what
>>> more there is to do there.
>>
>> MemoryRegion + how to create them + ops != MemoryRegion. :)
> 
> Er, the ops are part of the core GIC -- what we're modelling
> here is a memory-mapped set of registers which provide a
> window (interface) onto the device. That's exactly what
> exposing a MemoryRegion is. (I'd like to have better support
> for exposing "named" MemoryRegions, in the same way that
> a Pin to me is support for "named" irq/gpio lines, but I don't
> think that's what you're getting at.)

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.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]