qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v1 0/8] QOM prop overloading + ARM MPCore CP


From: Alistair Francis
Subject: Re: [Qemu-devel] [RFC PATCH v1 0/8] QOM prop overloading + ARM MPCore CPUs
Date: Fri, 19 Jun 2015 09:21:46 +1000

On Mon, Jun 15, 2015 at 8:36 AM, Peter Crosthwaite
<address@hidden> wrote:
>
> Hi All,
>
> This series introduced support for multi QOM properties with the same
> name and then moves the ARM CPUs to the MPCore container objects (yes!
> they are related!)
>
> The application of the QOM change is container objects passing through
> a single property on multiple same-type children as a single alias. The
> immediate use case, is the ARM MPCore where we want to add N cpus but pass
> through the CPU properties for all of them as an alias on the container
> itself. The container property setter should fan out to all the CPUs in the
> container.
>
> Patches 1-5 implement overloaded properties as part of QOM. QOM
> properties do not allow overloading by default, the creator of the
> property has to switch it on.

Looks pretty good. I'm just wondering what the logic is for making it off
by default. Why not make everything overloadable?

Thanks,

Alistair

>
> Patch 6 switches this feature on for alias properties which handles the
> container use case.
>
> Patch 8 is the feature presentation, pulling the CPUs into the ARM
> MPCore container. This is based on a series of Alistair's to do the same.
> This version does the extra refactoring to handle the case of multiple CPUs
> and the problems created around aliases.
>
> Extra discussion points:
>
> The QOM work will probably conflict with Pavel Fedin' work of arrayified
> properties. So I'll resolve that conflict in a future spin.
>
> Liviu recently brought up a desire for arguments to QOM constructors. P8
> would probably be cleaner if this feature existed, as the number of CPUs
> could be set as a constructor argument. There is no flexibility on when
> this has to be set, it must be done immediately after construction so it
> ideally should be part of construction.
>
> My biggest fear is testing of the changes for the affected boards.
> Peter, do you much coverage of these boards in your regressions? Do you
> have automated tests in a git repo somewhere?
>
> Regards,
> Peter
>
>
>
> Peter Crosthwaite (8):
>   qom: Refactor array property code path
>   qom: Add property overloading
>   qom: Implement overloaded property setters
>   qom: Delete all instances of an overloaded property
>   qom: Disallow getting/resolving an overloaded property
>   qom: Enable overloading of Alias properties
>   arm: realview: Factor out CPU property setters
>   arm: axxmpcore: Add CPUs to MPCore
>
>  hw/arm/exynos4210.c         |  72 +++++++-----------------------
>  hw/arm/highbank.c           |  65 +++++----------------------
>  hw/arm/realview.c           | 100 +++++++++++++++++++++++------------------
>  hw/arm/vexpress.c           |  71 +++++++-----------------------
>  hw/arm/xilinx_zynq.c        |  65 ++++++++++-----------------
>  hw/cpu/a15mpcore.c          |  66 ++++++++++++++++++++++++----
>  hw/cpu/a9mpcore.c           |  97 +++++++++++++++++++++++++++++++++++++---
>  hw/intc/exynos4210_gic.c    | 105 
> --------------------------------------------
>  include/hw/arm/exynos4210.h |   2 -
>  include/hw/cpu/a15mpcore.h  |   2 +
>  include/hw/cpu/a9mpcore.h   |   6 +++
>  include/qom/object.h        |   2 +
>  qom/object.c                |  96 ++++++++++++++++++++++++----------------
>  13 files changed, 341 insertions(+), 408 deletions(-)
>
> --
> 2.4.3.3.g905f831
>
>



reply via email to

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