All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philippe.mathieu.daude@gmail.com>
To: Damien Hedde <damien.hedde@greensocs.com>, qemu-devel@nongnu.org
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Bin Meng" <bin.meng@windriver.com>,
	qemu-riscv@nongnu.org,
	"Alistair Francis" <alistair@alistair23.me>,
	mark.burton@greensocs.com,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	qemu-arm@nongnu.org, "Palmer Dabbelt" <palmer@dabbelt.com>,
	"Vijai Kumar K" <vijai@behindbytes.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [RFC PATCH 02/18] hw/cpu/cpus: introduce _cpus_ device
Date: Sat, 16 Apr 2022 19:52:42 +0200	[thread overview]
Message-ID: <2ded9132-c2b5-c428-6554-98c71b50e8bb@gmail.com> (raw)
In-Reply-To: <20220330125639.201937-3-damien.hedde@greensocs.com>

On 30/3/22 14:56, Damien Hedde wrote:
> This object will be a _cpu-cluster_ generalization and
> is meant to allow create cpus of the same type.
> 
> The main goal is that this object, on contrary to _cpu-cluster-_,
> can be used to dynamically create cpus: it does not rely on
> external code to populate the object with cpus.
> 
> Allowing the user to create a cpu cluster and each _cpu_
> separately would be hard because of the following reasons:
> + cpu reset need to be handled
> + instantiation and realize of cpu-cluster and the cpus
>    are interleaved
> + cpu cluster must contains only identical cpus and it seems
>    difficult to check that at runtime.
> Therefore we add a new type solving all this constraints.
> 
> _cpu-cluster_ will be updated to inherit from this class
> in following commits.
> 
> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
> ---
>   include/hw/cpu/cpus.h |  71 +++++++++++++++++++++++
>   hw/cpu/cpus.c         | 127 ++++++++++++++++++++++++++++++++++++++++++
>   hw/cpu/meson.build    |   2 +-
>   3 files changed, 199 insertions(+), 1 deletion(-)
>   create mode 100644 include/hw/cpu/cpus.h
>   create mode 100644 hw/cpu/cpus.c
> 
> diff --git a/include/hw/cpu/cpus.h b/include/hw/cpu/cpus.h
> new file mode 100644
> index 0000000000..c65f568ef8
> --- /dev/null
> +++ b/include/hw/cpu/cpus.h
> @@ -0,0 +1,71 @@
> +/*
> + * QEMU CPUs type
> + *
> + * Copyright (c) 2022 GreenSocs
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef HW_CPU_CPUS_H
> +#define HW_CPU_CPUS_H
> +
> +#include "qemu/typedefs.h"
> +#include "hw/qdev-core.h"
> +#include "qom/object.h"
> +
> +/*
> + * This object represent several CPUs which are all identical.

Typo "represents".

> + *
> + * If CPUs are not identical (for example, Cortex-A53 and Cortex-A57 CPUs in an
> + * Arm big.LITTLE system) they should be in different groups. If the CPUs do
> + * not have the same view of memory (for example the main CPU and a management
> + * controller processor) they should be in different groups.

This description calls for a clearer CpusGroupState name instead
of CpusState (which confuses me with CPUState). Alternatively
CpusArrayState.

> + *
> + * This is an abstract class, subclasses are supposed to be created on
> + * per-architecture basis to handle the specifics of the cpu architecture.
> + * Subclasses are meant to be user-creatable (for cold-plug).
> + */
> +
> +#define TYPE_CPUS "cpus"
> +OBJECT_DECLARE_TYPE(CpusState, CpusClass, CPUS)
> +
> +/**
> + * CpusState:
> + * @cpu_type: The type of cpu.
> + * @topology.cpus: The number of cpus in this group.
> + *      Explicity put this field into a topology structure in
> + *      order to eventually update this smoothly with a full
> + *      CpuTopology structure in the future.
> + * @cpus: Array of pointer to cpu objects.
> + */
> +struct CpusState {
> +    /*< private >*/
> +    DeviceState parent_obj;
> +
> +    /*< public >*/
> +    char *cpu_type;
> +    struct {
> +        uint16_t cpus;
> +    } topology;
> +    CPUState **cpus;
> +};


WARNING: multiple messages have this Message-ID (diff)
From: "Philippe Mathieu-Daudé" <philippe.mathieu.daude@gmail.com>
To: Damien Hedde <damien.hedde@greensocs.com>, qemu-devel@nongnu.org
Cc: mark.burton@greensocs.com, "Alex Bennée" <alex.bennee@linaro.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Bin Meng" <bin.meng@windriver.com>,
	"Vijai Kumar K" <vijai@behindbytes.com>,
	qemu-arm@nongnu.org, qemu-riscv@nongnu.org
Subject: Re: [RFC PATCH 02/18] hw/cpu/cpus: introduce _cpus_ device
Date: Sat, 16 Apr 2022 19:52:42 +0200	[thread overview]
Message-ID: <2ded9132-c2b5-c428-6554-98c71b50e8bb@gmail.com> (raw)
In-Reply-To: <20220330125639.201937-3-damien.hedde@greensocs.com>

On 30/3/22 14:56, Damien Hedde wrote:
> This object will be a _cpu-cluster_ generalization and
> is meant to allow create cpus of the same type.
> 
> The main goal is that this object, on contrary to _cpu-cluster-_,
> can be used to dynamically create cpus: it does not rely on
> external code to populate the object with cpus.
> 
> Allowing the user to create a cpu cluster and each _cpu_
> separately would be hard because of the following reasons:
> + cpu reset need to be handled
> + instantiation and realize of cpu-cluster and the cpus
>    are interleaved
> + cpu cluster must contains only identical cpus and it seems
>    difficult to check that at runtime.
> Therefore we add a new type solving all this constraints.
> 
> _cpu-cluster_ will be updated to inherit from this class
> in following commits.
> 
> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
> ---
>   include/hw/cpu/cpus.h |  71 +++++++++++++++++++++++
>   hw/cpu/cpus.c         | 127 ++++++++++++++++++++++++++++++++++++++++++
>   hw/cpu/meson.build    |   2 +-
>   3 files changed, 199 insertions(+), 1 deletion(-)
>   create mode 100644 include/hw/cpu/cpus.h
>   create mode 100644 hw/cpu/cpus.c
> 
> diff --git a/include/hw/cpu/cpus.h b/include/hw/cpu/cpus.h
> new file mode 100644
> index 0000000000..c65f568ef8
> --- /dev/null
> +++ b/include/hw/cpu/cpus.h
> @@ -0,0 +1,71 @@
> +/*
> + * QEMU CPUs type
> + *
> + * Copyright (c) 2022 GreenSocs
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef HW_CPU_CPUS_H
> +#define HW_CPU_CPUS_H
> +
> +#include "qemu/typedefs.h"
> +#include "hw/qdev-core.h"
> +#include "qom/object.h"
> +
> +/*
> + * This object represent several CPUs which are all identical.

Typo "represents".

> + *
> + * If CPUs are not identical (for example, Cortex-A53 and Cortex-A57 CPUs in an
> + * Arm big.LITTLE system) they should be in different groups. If the CPUs do
> + * not have the same view of memory (for example the main CPU and a management
> + * controller processor) they should be in different groups.

This description calls for a clearer CpusGroupState name instead
of CpusState (which confuses me with CPUState). Alternatively
CpusArrayState.

> + *
> + * This is an abstract class, subclasses are supposed to be created on
> + * per-architecture basis to handle the specifics of the cpu architecture.
> + * Subclasses are meant to be user-creatable (for cold-plug).
> + */
> +
> +#define TYPE_CPUS "cpus"
> +OBJECT_DECLARE_TYPE(CpusState, CpusClass, CPUS)
> +
> +/**
> + * CpusState:
> + * @cpu_type: The type of cpu.
> + * @topology.cpus: The number of cpus in this group.
> + *      Explicity put this field into a topology structure in
> + *      order to eventually update this smoothly with a full
> + *      CpuTopology structure in the future.
> + * @cpus: Array of pointer to cpu objects.
> + */
> +struct CpusState {
> +    /*< private >*/
> +    DeviceState parent_obj;
> +
> +    /*< public >*/
> +    char *cpu_type;
> +    struct {
> +        uint16_t cpus;
> +    } topology;
> +    CPUState **cpus;
> +};


  reply	other threads:[~2022-04-16 17:53 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 12:56 [RFC PATCH 00/18] user-creatable cpu clusters Damien Hedde
2022-03-30 12:56 ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 01/18] define MAX_CLUSTERS in cpu.h instead of cluster.h Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 02/18] hw/cpu/cpus: introduce _cpus_ device Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-04-16 17:52   ` Philippe Mathieu-Daudé [this message]
2022-04-16 17:52     ` Philippe Mathieu-Daudé
2022-04-19  9:11     ` Damien Hedde
2022-04-19  9:11       ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 03/18] hw/cpu/cpus: prepare to handle cpu clusters Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 04/18] hw/cpu/cluster: make _cpu-cluster_ a subclass of _cpus_ Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 05/18] gdbstub: deal with _cpus_ object instead of _cpu-cluster_ Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 06/18] hw/cpu/cluster: remove cluster_id now that gdbstub is updated Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 07/18] hw/cpu/cpus: add a common start-powered-off property Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 08/18] hw/arm/arm_cpus: add arm_cpus device Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-04-16 18:01   ` Philippe Mathieu-Daudé
2022-04-16 18:01     ` Philippe Mathieu-Daudé
2022-03-30 12:56 ` [RFC PATCH 09/18] hw/arm/xlnx-zynqmp: convert cpu clusters to arm_cpus Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-04-16 18:06   ` Philippe Mathieu-Daudé
2022-04-16 18:06     ` Philippe Mathieu-Daudé
2022-03-30 12:56 ` [RFC PATCH 10/18] hw/riscv/riscv_hart: prepare transition to cpus Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 11/18] hw/riscv: prepare riscv_hart " Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 12/18] hw/riscv/virt: " Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 13/18] hw/riscv/spike: " Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 14/18] hw/riscv/riscv_hart: use cpus as base class Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 15/18] hw/riscv/sifive_u&microchip_pfsoc: apply riscv_hart_array update Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 16/18] hw/riscv: update remaining machines due to " Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 17/18] hw/riscv/riscv_hart: remove temporary features Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-03-30 12:56 ` [RFC PATCH 18/18] add myself as reviewer of the newly added _cpus_ Damien Hedde
2022-03-30 12:56   ` Damien Hedde
2022-04-15  7:42 ` [RFC PATCH 00/18] user-creatable cpu clusters Damien Hedde
2022-04-15  7:42   ` Damien Hedde
2022-04-21 15:51 ` Peter Maydell
2022-04-21 15:51   ` Peter Maydell
2022-04-21 18:11   ` Damien Hedde
2022-04-21 18:11     ` Damien Hedde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ded9132-c2b5-c428-6554-98c71b50e8bb@gmail.com \
    --to=philippe.mathieu.daude@gmail.com \
    --cc=alex.bennee@linaro.org \
    --cc=alistair@alistair23.me \
    --cc=bin.meng@windriver.com \
    --cc=damien.hedde@greensocs.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=eduardo@habkost.net \
    --cc=f4bug@amsat.org \
    --cc=mark.burton@greensocs.com \
    --cc=palmer@dabbelt.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=vijai@behindbytes.com \
    --cc=wangyanan55@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.