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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()
Date: Fri, 13 Apr 2012 10:09:10 +0100

On 13 April 2012 09:33, Paolo Bonzini <address@hidden> wrote:
> Il 13/04/2012 10:12, Peter Maydell ha scritto:
>> Half a dozen from random grep:
>> "xilinx,timer" -- memory region size depends on a property
>> "lan9118" -- which MemoryRegionOps we use for the region depends
>>   on the "mode_16bit" property.
>
> You can set these at realize time, before the memory region itself is
> realized (realization uses pre-order for this reason).
>
>> "SUNW,tcx" -- number of memory regions depend on depth property
>
> The regions can still exist in the device, whether they're mapped
> depends on the depth property.

This is like saying that you should still have 512 IRQ lines on
every IRQ array, or that omap should have 6 GPIO modules even
on variants with only 4, and so on. Devices shouldn't expose
connections that don't actually exist for the config you've
picked, otherwise we can't report attempts to wire up nonexistent
connections as errors. We have this ability for qdev/sysbus
currently, we shouldn't drop it in the move to QOM.

>> "a9mpcore_priv" (and its equivalents for a15, 11mpcore, etc)
>> "arm_mptimer" -- number of regions and irqs depends on 'num-cpu' prop
>
> Why wouldn't you model this as a parent SoC object with either:
>
> - 1 GIC child, N CPU children, N MPTimer children, and N GICInterface
> children (with links to the GIC);
>
> - or 1 GIC + N CPU children, each of the latter having 1 MPTimer child
> and 1 GICInterface child (with links to the GIC);

You're right in general that we should be modelling these as
container objects (I posted a series the other week that starts
to move in that direction by dropping the weird subclassing of
the GIC.) But the overall container object for a cortex-a9 will
still be an object whose number of exposed IRQ lines depends on
a device parameter, and the GIC device must still have a number
of exposed memory regions/input lines/output lines that depends
on the number of CPUs, which is going to be a device parameter.

I'm not sure what your GICInterface children are?

-- PMM



reply via email to

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