qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Salil Mehta via <qemu-devel@nongnu.org>
To: Gavin Shan <gshan@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>
Cc: "maz@kernel.org" <maz@kernel.org>,
	"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
	"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
	"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
	"imammedo@redhat.com" <imammedo@redhat.com>,
	"andrew.jones@linux.dev" <andrew.jones@linux.dev>,
	"david@redhat.com" <david@redhat.com>,
	"philmd@linaro.org" <philmd@linaro.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"borntraeger@linux.ibm.com" <borntraeger@linux.ibm.com>,
	 "alex.bennee@linaro.org" <alex.bennee@linaro.org>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"darren@os.amperecomputing.com" <darren@os.amperecomputing.com>,
	"ilkka@os.amperecomputing.com" <ilkka@os.amperecomputing.com>,
	"vishnu@os.amperecomputing.com" <vishnu@os.amperecomputing.com>,
	"karl.heubaum@oracle.com" <karl.heubaum@oracle.com>,
	"miguel.luis@oracle.com" <miguel.luis@oracle.com>,
	 "salil.mehta@opnsrc.net" <salil.mehta@opnsrc.net>,
	zhukeqian <zhukeqian1@huawei.com>,
	"wangxiongfeng (C)" <wangxiongfeng2@huawei.com>,
	"wangyanan (Y)" <wangyanan55@huawei.com>,
	"jiakernel2@gmail.com" <jiakernel2@gmail.com>,
	"maobibo@loongson.cn" <maobibo@loongson.cn>,
	"lixianglai@loongson.cn" <lixianglai@loongson.cn>
Subject: RE: [PATCH RFC V2 02/37] cpus-common: Add common CPU utility for possible vCPUs
Date: Mon, 2 Oct 2023 10:21:57 +0000	[thread overview]
Message-ID: <b002d32909f64a048371ff501bcedfc3@huawei.com> (raw)
In-Reply-To: <44e4f955-ab51-92ca-8d65-e3a38d8d6657@redhat.com>

Hi Gavin,

> From: Gavin Shan <gshan@redhat.com>
> Sent: Wednesday, September 27, 2023 4:54 AM
> To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org; qemu-
> arm@nongnu.org
> Cc: maz@kernel.org; jean-philippe@linaro.org; Jonathan Cameron
> <jonathan.cameron@huawei.com>; lpieralisi@kernel.org;
> peter.maydell@linaro.org; richard.henderson@linaro.org;
> imammedo@redhat.com; andrew.jones@linux.dev; david@redhat.com;
> philmd@linaro.org; eric.auger@redhat.com; will@kernel.org; ardb@kernel.org;
> oliver.upton@linux.dev; pbonzini@redhat.com; mst@redhat.com;
> rafael@kernel.org; borntraeger@linux.ibm.com; alex.bennee@linaro.org;
> linux@armlinux.org.uk; darren@os.amperecomputing.com;
> ilkka@os.amperecomputing.com; vishnu@os.amperecomputing.com;
> karl.heubaum@oracle.com; miguel.luis@oracle.com; salil.mehta@opnsrc.net;
> zhukeqian <zhukeqian1@huawei.com>; wangxiongfeng (C)
> <wangxiongfeng2@huawei.com>; wangyanan (Y) <wangyanan55@huawei.com>;
> jiakernel2@gmail.com; maobibo@loongson.cn; lixianglai@loongson.cn
> Subject: Re: [PATCH RFC V2 02/37] cpus-common: Add common CPU utility for
> possible vCPUs
> 
> Hi Salil,
> 
> On 9/26/23 20:04, Salil Mehta wrote:
> > Adds various utility functions which might be required to fetch or check
> the
> > state of the possible vCPUs. This also introduces concept of *disabled*
> vCPUs,
> > which are part of the *possible* vCPUs but are not part of the *present*
> vCPU.
> > This state shall be used during machine init time to check the presence
> of
> > vcpus.
>    ^^^^^
> 
>    vCPUs


Yes. Thanks.


> > Co-developed-by: Salil Mehta <salil.mehta@huawei.com>
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > Co-developed-by: Keqian Zhu <zhukeqian1@huawei.com>
> > Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > ---
> >   cpus-common.c         | 31 +++++++++++++++++++++++++
> >   include/hw/core/cpu.h | 53 +++++++++++++++++++++++++++++++++++++++++++
> >   2 files changed, 84 insertions(+)
> >
> > diff --git a/cpus-common.c b/cpus-common.c
> > index 45c745ecf6..24c04199a1 100644
> > --- a/cpus-common.c
> > +++ b/cpus-common.c
> > @@ -24,6 +24,7 @@
> >   #include "sysemu/cpus.h"
> >   #include "qemu/lockable.h"
> >   #include "trace/trace-root.h"
> > +#include "hw/boards.h"
> >
> >   QemuMutex qemu_cpu_list_lock;
> >   static QemuCond exclusive_cond;
> > @@ -107,6 +108,36 @@ void cpu_list_remove(CPUState *cpu)
> >       cpu_list_generation_id++;
> >   }
> >
> > +CPUState *qemu_get_possible_cpu(int index)
> > +{
> > +    MachineState *ms = MACHINE(qdev_get_machine());
> > +    const CPUArchIdList *possible_cpus = ms->possible_cpus;
> > +
> > +    assert((index >= 0) && (index < possible_cpus->len));
> > +
> > +    return CPU(possible_cpus->cpus[index].cpu);
> > +}
> > +
> > +bool qemu_present_cpu(CPUState *cpu)
> > +{
> > +    return cpu;
> > +}
> > +
> > +bool qemu_enabled_cpu(CPUState *cpu)
> > +{
> > +    return cpu && !cpu->disabled;
> > +}
> > +
> 
> I do think it's a good idea to have wrappers to check for CPU's states since
> these CPU states play important role in this series to support vCPU hotplug.
> However, it would be nice to move them around into header file (include/hw/boards.h)
> because all the checks are originated from ms->possible_cpus->cpus[]. It sounds
> functions to a machine (board) instead of global scope. Besides, it would be
> nice to have same input (index) for all functions. How about something like
> below in include/hw/boards.h?

These are operations related to CPUState and hence cpus-common.c seem to be
more appropriate to me. You can see similar functions like qemu_get_cpu()
already exists in the same file.

Yes, some operation do make use of the possible list which is maintained at
board level but eventually what we are returning is the CPUState. 

I am open to move some of above to board level not all like present,
enabled checks should exist in this file only. I would prefer to keep
all of them in this file.


> 
> static inline  bool machine_has_possible_cpu(int index)
> {
>      MachineState *ms = MACHINE(qdev_get_machine());
> 
>      if (!ms || !ms->possible_cpus || index < 0 || index >= ms-
> >possible_cus->len) {
>          return false;
>      }
> 
>      return true;
> }
> 
> static inline bool machine_has_present_cpu(int index)
> {
>      MachineState *ms = MACHINE(qdev_get_machine());
> 
>      if (!machine_is_possible_cpu(index) ||
>          !ms->possible_cpus->cpus[index].cpu) {
>          return false;
>      }
> 
>      return true;
> }
> 
> static inline bool machine_has_enabled_cpu(int index)
> {
>      MachineState *ms = MACHINE(qdev_get_machine());
>      CPUState *cs;
> 
>      if (!machine_is_present_cpu(index)) {
>          return false;
>      }
> 
>      cs = CPU(ms->possible_cpus->cpus[index].cpu);
>      return !cs->disabled
> }
> 
> > +uint64_t qemu_get_cpu_archid(int cpu_index)
> > +{
> > +    MachineState *ms = MACHINE(qdev_get_machine());
> > +    const CPUArchIdList *possible_cpus = ms->possible_cpus;
> > +
> > +    assert((cpu_index >= 0) && (cpu_index < possible_cpus->len));
> > +
> > +    return possible_cpus->cpus[cpu_index].arch_id;
> > +}
> > +
> 
> I think it's unnecessary to keep it since it's called for once by
> hw/arm/virt-acpi-build.c::build_madt. The architectural ID can be
> directly fetched from possible_cpus->cpus[i].arch_id. It's fine
> to drop this function and fold the logic to the following patch.

It is a very useful accessor API. I can see this code is being
replicated everywhere which also means many time its related
variables are repeatedly defined. 

Maybe this is being used once now. But this can be used across
architectures later.

> 
> [PATCH RFC V2 21/37] hw/arm: MADT Tbl change to size the guest with
> possible vCPUs
> 
> 
> >   CPUState *qemu_get_cpu(int index)
> >   {
> >       CPUState *cpu;
> > diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
> > index fdcbe87352..e5af79950c 100644
> > --- a/include/hw/core/cpu.h
> > +++ b/include/hw/core/cpu.h
> > @@ -413,6 +413,17 @@ struct CPUState {
> >       SavedIOTLB saved_iotlb;
> >   #endif
> >
> > +    /*
> > +     * Some architectures do not allow *presence* of vCPUs to be changed
> > +     * after guest has booted using information specified by VMM/firmware
> > +     * via ACPI MADT at the boot time. Thus to enable vCPU hotplug on these
> > +     * architectures possible vCPU can have CPUState object in 'disabled'
> > +     * state or can also not have CPUState object at all. This is possible
> > +     * when vCPU Hotplug is supported and vCPUs are 'yet-to-be-plugged' in
> > +     * the QOM or have been hot-unplugged.
> > +     * By default every CPUState is enabled as of now across all archs.
> > +     */
> > +    bool disabled;
> >       /* TODO Move common fields from CPUArchState here. */
> >       int cpu_index;
> >       int cluster_index;
> 
> I guess the comments can be simplified a bit. How about something like
> below?
>      /*
>       * In order to support vCPU hotplug on architectures like aarch64,
>       * the vCPU states fall into possible, present or enabled. This field
>       * is added to distinguish present and enabled vCPUs. By default, all
>       * vCPUs are present and enabled.
>       */

I can definitely try to simplify it but above is not properly conveying the
reason why we require the disabled state.


> 
> > @@ -770,6 +781,48 @@ static inline bool cpu_in_exclusive_context(const
> CPUState *cpu)
> >    */
> >   CPUState *qemu_get_cpu(int index);
> >
> > +/**
> > + * qemu_get_possible_cpu:
> > + * @index: The CPUState@cpu_index value of the CPU to obtain.
> > + *         Input index MUST be in range [0, Max Possible CPUs)
> > + *
> > + * If CPUState object exists,then it gets a CPU matching
> > + * @index in the possible CPU array.
> > + *
> > + * Returns: The possible CPU or %NULL if CPU does not exist.
> > + */
> > +CPUState *qemu_get_possible_cpu(int index);
> > +
> > +/**
> > + * qemu_present_cpu:
> > + * @cpu: The vCPU to check
> > + *
> > + * Checks if the vCPU is amongst the present possible vcpus.
> > + *
> > + * Returns: True if it is present possible vCPU else false
> > + */
> > +bool qemu_present_cpu(CPUState *cpu);
> > +
> > +/**
> > + * qemu_enabled_cpu:
> > + * @cpu: The vCPU to check
> > + *
> > + * Checks if the vCPU is enabled.
> > + *
> > + * Returns: True if it is 'enabled' else false
> > + */
> > +bool qemu_enabled_cpu(CPUState *cpu);
> > +
> > +/**
> > + * qemu_get_cpu_archid:
> > + * @cpu_index: possible vCPU for which arch-id needs to be retreived
> > + *
> > + * Fetches the vCPU arch-id from the present possible vCPUs.
> > + *
> > + * Returns: arch-id of the possible vCPU
> > + */
> > +uint64_t qemu_get_cpu_archid(int cpu_index);
> > +





WARNING: multiple messages have this Message-ID (diff)
From: Salil Mehta <salil.mehta@huawei.com>
To: Gavin Shan <gshan@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>
Cc: "maz@kernel.org" <maz@kernel.org>,
	"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
	"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
	"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
	"imammedo@redhat.com" <imammedo@redhat.com>,
	"andrew.jones@linux.dev" <andrew.jones@linux.dev>,
	"david@redhat.com" <david@redhat.com>,
	"philmd@linaro.org" <philmd@linaro.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"borntraeger@linux.ibm.com" <borntraeger@linux.ibm.com>,
	 "alex.bennee@linaro.org" <alex.bennee@linaro.org>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"darren@os.amperecomputing.com" <darren@os.amperecomputing.com>,
	"ilkka@os.amperecomputing.com" <ilkka@os.amperecomputing.com>,
	"vishnu@os.amperecomputing.com" <vishnu@os.amperecomputing.com>,
	"karl.heubaum@oracle.com" <karl.heubaum@oracle.com>,
	"miguel.luis@oracle.com" <miguel.luis@oracle.com>,
	 "salil.mehta@opnsrc.net" <salil.mehta@opnsrc.net>,
	zhukeqian <zhukeqian1@huawei.com>,
	"wangxiongfeng (C)" <wangxiongfeng2@huawei.com>,
	"wangyanan (Y)" <wangyanan55@huawei.com>,
	"jiakernel2@gmail.com" <jiakernel2@gmail.com>,
	"maobibo@loongson.cn" <maobibo@loongson.cn>,
	"lixianglai@loongson.cn" <lixianglai@loongson.cn>
Subject: RE: [PATCH RFC V2 02/37] cpus-common: Add common CPU utility for possible vCPUs
Date: Mon, 2 Oct 2023 10:21:57 +0000	[thread overview]
Message-ID: <b002d32909f64a048371ff501bcedfc3@huawei.com> (raw)
Message-ID: <20231002102157.q8g4k03jetk27K94eIS_EL7q8vswpG9eps90QcG6NPs@z> (raw)
In-Reply-To: <44e4f955-ab51-92ca-8d65-e3a38d8d6657@redhat.com>

Hi Gavin,

> From: Gavin Shan <gshan@redhat.com>
> Sent: Wednesday, September 27, 2023 4:54 AM
> To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org; qemu-
> arm@nongnu.org
> Cc: maz@kernel.org; jean-philippe@linaro.org; Jonathan Cameron
> <jonathan.cameron@huawei.com>; lpieralisi@kernel.org;
> peter.maydell@linaro.org; richard.henderson@linaro.org;
> imammedo@redhat.com; andrew.jones@linux.dev; david@redhat.com;
> philmd@linaro.org; eric.auger@redhat.com; will@kernel.org; ardb@kernel.org;
> oliver.upton@linux.dev; pbonzini@redhat.com; mst@redhat.com;
> rafael@kernel.org; borntraeger@linux.ibm.com; alex.bennee@linaro.org;
> linux@armlinux.org.uk; darren@os.amperecomputing.com;
> ilkka@os.amperecomputing.com; vishnu@os.amperecomputing.com;
> karl.heubaum@oracle.com; miguel.luis@oracle.com; salil.mehta@opnsrc.net;
> zhukeqian <zhukeqian1@huawei.com>; wangxiongfeng (C)
> <wangxiongfeng2@huawei.com>; wangyanan (Y) <wangyanan55@huawei.com>;
> jiakernel2@gmail.com; maobibo@loongson.cn; lixianglai@loongson.cn
> Subject: Re: [PATCH RFC V2 02/37] cpus-common: Add common CPU utility for
> possible vCPUs
> 
> Hi Salil,
> 
> On 9/26/23 20:04, Salil Mehta wrote:
> > Adds various utility functions which might be required to fetch or check
> the
> > state of the possible vCPUs. This also introduces concept of *disabled*
> vCPUs,
> > which are part of the *possible* vCPUs but are not part of the *present*
> vCPU.
> > This state shall be used during machine init time to check the presence
> of
> > vcpus.
>    ^^^^^
> 
>    vCPUs


Yes. Thanks.


> > Co-developed-by: Salil Mehta <salil.mehta@huawei.com>
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > Co-developed-by: Keqian Zhu <zhukeqian1@huawei.com>
> > Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > ---
> >   cpus-common.c         | 31 +++++++++++++++++++++++++
> >   include/hw/core/cpu.h | 53 +++++++++++++++++++++++++++++++++++++++++++
> >   2 files changed, 84 insertions(+)
> >
> > diff --git a/cpus-common.c b/cpus-common.c
> > index 45c745ecf6..24c04199a1 100644
> > --- a/cpus-common.c
> > +++ b/cpus-common.c
> > @@ -24,6 +24,7 @@
> >   #include "sysemu/cpus.h"
> >   #include "qemu/lockable.h"
> >   #include "trace/trace-root.h"
> > +#include "hw/boards.h"
> >
> >   QemuMutex qemu_cpu_list_lock;
> >   static QemuCond exclusive_cond;
> > @@ -107,6 +108,36 @@ void cpu_list_remove(CPUState *cpu)
> >       cpu_list_generation_id++;
> >   }
> >
> > +CPUState *qemu_get_possible_cpu(int index)
> > +{
> > +    MachineState *ms = MACHINE(qdev_get_machine());
> > +    const CPUArchIdList *possible_cpus = ms->possible_cpus;
> > +
> > +    assert((index >= 0) && (index < possible_cpus->len));
> > +
> > +    return CPU(possible_cpus->cpus[index].cpu);
> > +}
> > +
> > +bool qemu_present_cpu(CPUState *cpu)
> > +{
> > +    return cpu;
> > +}
> > +
> > +bool qemu_enabled_cpu(CPUState *cpu)
> > +{
> > +    return cpu && !cpu->disabled;
> > +}
> > +
> 
> I do think it's a good idea to have wrappers to check for CPU's states since
> these CPU states play important role in this series to support vCPU hotplug.
> However, it would be nice to move them around into header file (include/hw/boards.h)
> because all the checks are originated from ms->possible_cpus->cpus[]. It sounds
> functions to a machine (board) instead of global scope. Besides, it would be
> nice to have same input (index) for all functions. How about something like
> below in include/hw/boards.h?

These are operations related to CPUState and hence cpus-common.c seem to be
more appropriate to me. You can see similar functions like qemu_get_cpu()
already exists in the same file.

Yes, some operation do make use of the possible list which is maintained at
board level but eventually what we are returning is the CPUState. 

I am open to move some of above to board level not all like present,
enabled checks should exist in this file only. I would prefer to keep
all of them in this file.


> 
> static inline  bool machine_has_possible_cpu(int index)
> {
>      MachineState *ms = MACHINE(qdev_get_machine());
> 
>      if (!ms || !ms->possible_cpus || index < 0 || index >= ms-
> >possible_cus->len) {
>          return false;
>      }
> 
>      return true;
> }
> 
> static inline bool machine_has_present_cpu(int index)
> {
>      MachineState *ms = MACHINE(qdev_get_machine());
> 
>      if (!machine_is_possible_cpu(index) ||
>          !ms->possible_cpus->cpus[index].cpu) {
>          return false;
>      }
> 
>      return true;
> }
> 
> static inline bool machine_has_enabled_cpu(int index)
> {
>      MachineState *ms = MACHINE(qdev_get_machine());
>      CPUState *cs;
> 
>      if (!machine_is_present_cpu(index)) {
>          return false;
>      }
> 
>      cs = CPU(ms->possible_cpus->cpus[index].cpu);
>      return !cs->disabled
> }
> 
> > +uint64_t qemu_get_cpu_archid(int cpu_index)
> > +{
> > +    MachineState *ms = MACHINE(qdev_get_machine());
> > +    const CPUArchIdList *possible_cpus = ms->possible_cpus;
> > +
> > +    assert((cpu_index >= 0) && (cpu_index < possible_cpus->len));
> > +
> > +    return possible_cpus->cpus[cpu_index].arch_id;
> > +}
> > +
> 
> I think it's unnecessary to keep it since it's called for once by
> hw/arm/virt-acpi-build.c::build_madt. The architectural ID can be
> directly fetched from possible_cpus->cpus[i].arch_id. It's fine
> to drop this function and fold the logic to the following patch.

It is a very useful accessor API. I can see this code is being
replicated everywhere which also means many time its related
variables are repeatedly defined. 

Maybe this is being used once now. But this can be used across
architectures later.

> 
> [PATCH RFC V2 21/37] hw/arm: MADT Tbl change to size the guest with
> possible vCPUs
> 
> 
> >   CPUState *qemu_get_cpu(int index)
> >   {
> >       CPUState *cpu;
> > diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
> > index fdcbe87352..e5af79950c 100644
> > --- a/include/hw/core/cpu.h
> > +++ b/include/hw/core/cpu.h
> > @@ -413,6 +413,17 @@ struct CPUState {
> >       SavedIOTLB saved_iotlb;
> >   #endif
> >
> > +    /*
> > +     * Some architectures do not allow *presence* of vCPUs to be changed
> > +     * after guest has booted using information specified by VMM/firmware
> > +     * via ACPI MADT at the boot time. Thus to enable vCPU hotplug on these
> > +     * architectures possible vCPU can have CPUState object in 'disabled'
> > +     * state or can also not have CPUState object at all. This is possible
> > +     * when vCPU Hotplug is supported and vCPUs are 'yet-to-be-plugged' in
> > +     * the QOM or have been hot-unplugged.
> > +     * By default every CPUState is enabled as of now across all archs.
> > +     */
> > +    bool disabled;
> >       /* TODO Move common fields from CPUArchState here. */
> >       int cpu_index;
> >       int cluster_index;
> 
> I guess the comments can be simplified a bit. How about something like
> below?
>      /*
>       * In order to support vCPU hotplug on architectures like aarch64,
>       * the vCPU states fall into possible, present or enabled. This field
>       * is added to distinguish present and enabled vCPUs. By default, all
>       * vCPUs are present and enabled.
>       */

I can definitely try to simplify it but above is not properly conveying the
reason why we require the disabled state.


> 
> > @@ -770,6 +781,48 @@ static inline bool cpu_in_exclusive_context(const
> CPUState *cpu)
> >    */
> >   CPUState *qemu_get_cpu(int index);
> >
> > +/**
> > + * qemu_get_possible_cpu:
> > + * @index: The CPUState@cpu_index value of the CPU to obtain.
> > + *         Input index MUST be in range [0, Max Possible CPUs)
> > + *
> > + * If CPUState object exists,then it gets a CPU matching
> > + * @index in the possible CPU array.
> > + *
> > + * Returns: The possible CPU or %NULL if CPU does not exist.
> > + */
> > +CPUState *qemu_get_possible_cpu(int index);
> > +
> > +/**
> > + * qemu_present_cpu:
> > + * @cpu: The vCPU to check
> > + *
> > + * Checks if the vCPU is amongst the present possible vcpus.
> > + *
> > + * Returns: True if it is present possible vCPU else false
> > + */
> > +bool qemu_present_cpu(CPUState *cpu);
> > +
> > +/**
> > + * qemu_enabled_cpu:
> > + * @cpu: The vCPU to check
> > + *
> > + * Checks if the vCPU is enabled.
> > + *
> > + * Returns: True if it is 'enabled' else false
> > + */
> > +bool qemu_enabled_cpu(CPUState *cpu);
> > +
> > +/**
> > + * qemu_get_cpu_archid:
> > + * @cpu_index: possible vCPU for which arch-id needs to be retreived
> > + *
> > + * Fetches the vCPU arch-id from the present possible vCPUs.
> > + *
> > + * Returns: arch-id of the possible vCPU
> > + */
> > +uint64_t qemu_get_cpu_archid(int cpu_index);
> > +





  reply	other threads:[~2023-10-02 10:22 UTC|newest]

Thread overview: 146+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 10:03 [PATCH RFC V2 00/37] Support of Virtual CPU Hotplug for ARMv8 Arch Salil Mehta via
2023-09-26 10:04 ` [PATCH RFC V2 01/37] arm/virt, target/arm: Add new ARMCPU {socket, cluster, core, thread}-id property Salil Mehta via
2023-09-26 23:57   ` [PATCH RFC V2 01/37] arm/virt,target/arm: Add new ARMCPU {socket,cluster,core,thread}-id property Gavin Shan
2023-10-02  9:53     ` Salil Mehta via
2023-10-02  9:53       ` Salil Mehta
2023-10-03  5:05       ` Gavin Shan
2023-09-26 10:04 ` [PATCH RFC V2 02/37] cpus-common: Add common CPU utility for possible vCPUs Salil Mehta via
2023-09-27  3:54   ` Gavin Shan
2023-10-02 10:21     ` Salil Mehta via [this message]
2023-10-02 10:21       ` Salil Mehta
2023-10-03  5:34       ` Gavin Shan
2023-09-26 10:04 ` [PATCH RFC V2 03/37] hw/arm/virt: Move setting of common CPU properties in a function Salil Mehta via
2023-09-27  5:16   ` Gavin Shan
2023-10-02 10:24     ` Salil Mehta via
2023-10-02 10:24       ` Salil Mehta
2023-10-10  6:46   ` Shaoqin Huang
2023-10-10  9:47     ` Salil Mehta via
2023-10-10  9:47       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 04/37] arm/virt, target/arm: Machine init time change common to vCPU {cold|hot}-plug Salil Mehta via
2023-09-27  6:28   ` [PATCH RFC V2 04/37] arm/virt,target/arm: " Gavin Shan
2023-10-02 16:12     ` Salil Mehta via
2023-10-02 16:12       ` Salil Mehta
2024-01-16 15:59       ` Jonathan Cameron via
2023-09-27  6:30   ` Gavin Shan
2023-10-02 10:27     ` Salil Mehta via
2023-10-02 10:27       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 05/37] accel/kvm: Extract common KVM vCPU {creation, parking} code Salil Mehta via
2023-09-27  6:51   ` [PATCH RFC V2 05/37] accel/kvm: Extract common KVM vCPU {creation,parking} code Gavin Shan
2023-10-02 16:20     ` Salil Mehta via
2023-10-02 16:20       ` Salil Mehta
2023-10-03  5:39       ` Gavin Shan
2023-09-26 10:04 ` [PATCH RFC V2 06/37] arm/virt, kvm: Pre-create disabled possible vCPUs @machine init Salil Mehta via
2023-09-27 10:04   ` [PATCH RFC V2 06/37] arm/virt,kvm: " Gavin Shan
2023-10-02 16:39     ` Salil Mehta via
2023-10-02 16:39       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 07/37] arm/virt, gicv3: Changes to pre-size GIC with possible vcpus " Salil Mehta via
2023-09-28  0:14   ` Gavin Shan
2023-10-16 16:15     ` Salil Mehta via
2023-10-16 16:15       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 08/37] arm/virt: Init PMU at host for all possible vcpus Salil Mehta via
2023-09-26 10:04 ` [PATCH RFC V2 09/37] hw/acpi: Move CPU ctrl-dev MMIO region len macro to common header file Salil Mehta via
2023-09-28  0:19   ` Gavin Shan
2023-10-16 16:20     ` Salil Mehta via
2023-10-16 16:20       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 10/37] arm/acpi: Enable ACPI support for vcpu hotplug Salil Mehta via
2023-09-28  0:25   ` Gavin Shan
2023-10-16 21:23     ` Salil Mehta via
2023-10-16 21:23       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 11/37] hw/acpi: Add ACPI CPU hotplug init stub Salil Mehta via
2023-09-28  0:28   ` Gavin Shan
2023-10-16 21:27     ` Salil Mehta via
2023-10-16 21:27       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 12/37] hw/acpi: Use qemu_present_cpu() API in ACPI CPU hotplug init Salil Mehta via
2023-09-28  0:40   ` Gavin Shan
2023-10-16 21:41     ` Salil Mehta via
2023-10-16 21:41       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 13/37] hw/acpi: Init GED framework with cpu hotplug events Salil Mehta via
2023-09-28  0:56   ` Gavin Shan
2023-10-16 21:44     ` Salil Mehta via
2023-10-16 21:44       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 14/37] arm/virt: Add cpu hotplug events to GED during creation Salil Mehta via
2023-09-28  1:03   ` Gavin Shan
2023-10-16 21:46     ` Salil Mehta via
2023-10-16 21:46       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 15/37] arm/virt: Create GED dev before *disabled* CPU Objs are destroyed Salil Mehta via
2023-09-28  1:08   ` Gavin Shan
2023-10-16 21:54     ` Salil Mehta via
2023-10-16 21:54       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 16/37] hw/acpi: Update CPUs AML with cpu-(ctrl)dev change Salil Mehta via
2023-09-28  1:26   ` Gavin Shan
2023-10-16 21:57     ` Salil Mehta via
2023-10-16 21:57       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 17/37] arm/virt/acpi: Build CPUs AML with CPU Hotplug support Salil Mehta via
2023-09-28  1:36   ` Gavin Shan
2023-10-16 22:05     ` Salil Mehta via
2023-10-16 22:05       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 18/37] arm/virt: Make ARM vCPU *present* status ACPI *persistent* Salil Mehta via
2023-09-28 23:18   ` Gavin Shan
2023-10-16 22:33     ` Salil Mehta via
2023-10-16 22:33       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 19/37] hw/acpi: ACPI/AML Changes to reflect the correct _STA.{PRES, ENA} Bits to Guest Salil Mehta via
2023-09-28 23:33   ` [PATCH RFC V2 19/37] hw/acpi: ACPI/AML Changes to reflect the correct _STA.{PRES,ENA} " Gavin Shan
2023-10-16 22:59     ` Salil Mehta via
2023-10-16 22:59       ` Salil Mehta
2024-01-17 21:46   ` [PATCH RFC V2 19/37] hw/acpi: ACPI/AML Changes to reflect the correct _STA.{PRES, ENA} " Jonathan Cameron via
2023-09-26 10:04 ` [PATCH RFC V2 20/37] hw/acpi: Update GED _EVT method AML with cpu scan Salil Mehta via
2023-09-28 23:35   ` Gavin Shan
2023-10-16 23:01     ` Salil Mehta via
2023-10-16 23:01       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 21/37] hw/arm: MADT Tbl change to size the guest with possible vCPUs Salil Mehta via
2023-09-28 23:43   ` Gavin Shan
2023-10-16 23:15     ` Salil Mehta via
2023-10-16 23:15       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 22/37] hw/acpi: Make _MAT method optional Salil Mehta via
2023-09-28 23:50   ` Gavin Shan
2023-10-16 23:17     ` Salil Mehta via
2023-10-16 23:17       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 23/37] arm/virt: Release objects for *disabled* possible vCPUs after init Salil Mehta via
2023-09-28 23:57   ` Gavin Shan
2023-10-16 23:28     ` Salil Mehta via
2023-10-16 23:28       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 24/37] hw/acpi: Update ACPI GED framework to support vCPU Hotplug Salil Mehta via
2023-09-26 11:02   ` Michael S. Tsirkin
2023-09-26 11:37     ` Salil Mehta via
2023-09-26 12:00       ` Michael S. Tsirkin
2023-09-26 12:27         ` Salil Mehta via
2023-09-26 13:02         ` lixianglai
2023-09-26 10:04 ` [PATCH RFC V2 25/37] arm/virt: Add/update basic hot-(un)plug framework Salil Mehta via
2023-09-29  0:20   ` Gavin Shan
2023-10-16 23:40     ` Salil Mehta via
2023-10-16 23:40       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 26/37] arm/virt: Changes to (un)wire GICC<->vCPU IRQs during hot-(un)plug Salil Mehta via
2023-09-26 10:04 ` [PATCH RFC V2 27/37] hw/arm, gicv3: Changes to update GIC with vCPU hot-plug notification Salil Mehta via
2023-09-26 10:04 ` [PATCH RFC V2 28/37] hw/intc/arm-gicv3*: Changes required to (re)init the vCPU register info Salil Mehta via
2023-09-26 10:04 ` [PATCH RFC V2 29/37] arm/virt: Update the guest(via GED) about CPU hot-(un)plug events Salil Mehta via
2023-09-29  0:30   ` Gavin Shan
2023-10-16 23:48     ` Salil Mehta via
2023-10-16 23:48       ` Salil Mehta
2023-09-26 10:04 ` [PATCH RFC V2 30/37] hw/arm: Changes required for reset and to support next boot Salil Mehta via
2023-09-26 10:04 ` [PATCH RFC V2 31/37] physmem, gdbstub: Common helping funcs/changes to *unrealize* vCPU Salil Mehta via
2023-10-03  6:33   ` [PATCH RFC V2 31/37] physmem,gdbstub: " Philippe Mathieu-Daudé
2023-10-03 10:22     ` Salil Mehta via
2023-10-03 10:22       ` Salil Mehta
2023-10-04  9:17       ` Salil Mehta via
2023-10-04  9:17         ` Salil Mehta
2023-09-26 10:36 ` [PATCH RFC V2 32/37] target/arm: Add support of *unrealize* ARMCPU during vCPU Hot-unplug Salil Mehta via
2023-09-26 10:36   ` [PATCH RFC V2 33/37] target/arm/kvm: Write CPU state back to KVM on reset Salil Mehta via
2023-09-26 10:36   ` [PATCH RFC V2 34/37] target/arm/kvm, tcg: Register/Handle SMCCC hypercall exits to VMM/Qemu Salil Mehta via
2023-09-29  4:15     ` [PATCH RFC V2 34/37] target/arm/kvm,tcg: " Gavin Shan
2023-10-17  0:03       ` Salil Mehta via
2023-10-17  0:03         ` Salil Mehta
2023-09-26 10:36   ` [PATCH RFC V2 35/37] hw/arm: Support hotplug capability check using _OSC method Salil Mehta via
2023-09-29  4:23     ` Gavin Shan
2023-10-17  0:13       ` Salil Mehta via
2023-10-17  0:13         ` Salil Mehta
2023-09-26 10:36   ` [PATCH RFC V2 36/37] tcg/mttcg: enable threads to unregister in tcg_ctxs[] Salil Mehta via
2023-09-26 10:36   ` [PATCH RFC V2 37/37] hw/arm/virt: Expose cold-booted CPUs as MADT GICC Enabled Salil Mehta via
2023-10-11 10:23 ` [PATCH RFC V2 00/37] Support of Virtual CPU Hotplug for ARMv8 Arch Vishnu Pajjuri
2023-10-11 10:32   ` Salil Mehta via
2023-10-11 10:32     ` Salil Mehta
2023-10-11 11:08     ` Vishnu Pajjuri
2023-10-11 20:15       ` Salil Mehta
2023-10-12 17:02 ` Miguel Luis
2023-10-12 17:54   ` Salil Mehta via
2023-10-12 17:54     ` Salil Mehta
2023-10-13 10:43     ` Miguel Luis

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=b002d32909f64a048371ff501bcedfc3@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=alex.bennee@linaro.org \
    --cc=andrew.jones@linux.dev \
    --cc=ardb@kernel.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=darren@os.amperecomputing.com \
    --cc=david@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=gshan@redhat.com \
    --cc=ilkka@os.amperecomputing.com \
    --cc=imammedo@redhat.com \
    --cc=jean-philippe@linaro.org \
    --cc=jiakernel2@gmail.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=karl.heubaum@oracle.com \
    --cc=linux@armlinux.org.uk \
    --cc=lixianglai@loongson.cn \
    --cc=lpieralisi@kernel.org \
    --cc=maobibo@loongson.cn \
    --cc=maz@kernel.org \
    --cc=miguel.luis@oracle.com \
    --cc=mst@redhat.com \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=rafael@kernel.org \
    --cc=richard.henderson@linaro.org \
    --cc=salil.mehta@huawei.com \
    --cc=salil.mehta@opnsrc.net \
    --cc=vishnu@os.amperecomputing.com \
    --cc=wangxiongfeng2@huawei.com \
    --cc=wangyanan55@huawei.com \
    --cc=will@kernel.org \
    --cc=zhukeqian1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).