qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 2/6] a9mpcore: localised temporary init-only


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v1 2/6] a9mpcore: localised temporary init-only variables
Date: Tue, 19 Feb 2013 12:52:27 +0000

On 19 February 2013 12:43, Peter Crosthwaite
<address@hidden> wrote:
> On Tue, Feb 19, 2013 at 7:56 PM, Andreas Färber <address@hidden> wrote:
>> The main point of concern being QMP. QOM realize has the purpose of
>> decoupling device creation from device modification and emulation start.
>> Thus devices may not be created in initfn-turning-into-realize
>> functions. Otherwise they wouldn't be visible for inspection and for
>> setting properties.
>
> This is an annoying limitation, as containter devices should be able
> to create a variable number of children depending on their property
> values.

IIRC we decided that the answer to this is that you create the
children in the "property value has been set" hook...

>> When creating a device, the device itself has no knowledge of on whose
>> memory it is being created. Might be via -device, via board config file
>> or via QMP/libvirt. Thus the instantiating code needs to know how much
>> memory to allocate since instance_init may not fail, only realize.
>
> Hang on though, this is not about creating a device inline in the
> parents struct, this is about maintaining pointers to a new device.

I strongly dislike the inline-struct approach because it makes
public internal-device-state (ie the struct fields) which were
previously in QDEV entirely private. I don't want to go backwards
here so we need a solution which doesn't just move all these
structs into public header files.

>> * PMM had requested a "cortex" sub-object for grouping the CPU cores and
>> any ARM (Ltd./Holdings plc) stuff; I left them in the main SoC object
>> though, not sure if that causes lifetime issues in theory.
>
> I dont agree. Grouping IPs by vendor is a little artificial. There is
> no architectural reason why PL330, PL35x should go in a special
> container

I didn't mean "all ARM IP in a container"!  I meant that we should
have a "cortex-a9 with all the CPUs and the private peripherals
and the GIC" container, corresponding exactly to the way that in
hardware this all comes as a complete composed lump. At the moment
in QEMU we model the private peripherals in a container but the
CPU cores themselves are instantiated separately by the board
and wired up. That's pointless duplication.

-- PMM



reply via email to

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