On Wed, Oct 06, 2021 at 06:22:08PM +0800, Gavin Shan wrote:
> The following option is used to specify the distance map. It's
> possible the option isn't provided by user. In this case, the
> distance map isn't populated and exposed to platform. On the
> other hand, the empty NUMA node, where no
On Mon, Sep 27, 2021 at 03:17:31PM +0200, Eric Auger wrote:
> ARM SBBR specification mandates DBG2 table (Debug Port Table 2)
> since v1.0 (ARM DEN0044F 8.3.1.7 DBG2).
>
> The DBG2 table allows to describe one or more debug ports.
>
> Generate an DBG2 table featuring a single debug port, the
On Sun, Oct 03, 2021 at 05:46:04PM +0100, Marc Zyngier wrote:
> The highmem attribute is nothing but another way to express the
> PA range of a VM. To support HW that has a smaller PA range then
> what QEMU assumes, pass this PA range to the virt_set_memmap()
> function, allowing it to correctly
On Sun, Oct 03, 2021 at 05:46:04PM +0100, Marc Zyngier wrote:
...
> @@ -1662,9 +1665,17 @@ static void virt_set_memmap(VirtMachineState *vms)
> vms->memmap[i].size = size;
> base += size;
> }
> -vms->highest_gpa = (vms->highmem ?
> -base :
> -
On Mon, Oct 04, 2021 at 11:44:08AM +0200, Andrew Jones wrote:
> On Sun, Oct 03, 2021 at 05:46:02PM +0100, Marc Zyngier wrote:
...
> >
> > -return MACHINE(vms)->smp.cpus > redist0_capacity ? 2 : 1;
> > +return (MACHINE(vms)->smp.cpus > redist0
vms->memmap[VIRT_MEM].base + ms->maxram_size) - 1;
> if (device_memory_size > 0) {
> ms->device_memory = g_malloc0(sizeof(*ms->device_memory));
> ms->device_memory->base = device_memory_base;
> --
> 2.30.2
>
Reviewed-by: Andrew Jones
vms->highest_gpa = base -1;
> } else {
> +/* Advertise that we have disabled the highmem devices */
> +vms->highmem_ecam = false;
> +vms->highmem_redists = false;
> vms->highest_gpa = memtop - 1;
> }
>
> --
> 2.30.2
>
Reviewed-by: Andrew Jones
On Sun, Oct 03, 2021 at 05:46:02PM +0100, Marc Zyngier wrote:
> Just like we can control the enablement of the highmem PCIe region
> using highmem_ecam, let's add a control for the highmem GICv3
> redistributor region.
>
> Similarily to highmem_ecam, these redistributors are disabled when
>
op_sized_cells(ms->fdt, nodename, "reg",
> 2, base_ecam, 2, size_ecam);
>
> -if (vms->highmem) {
> +if (vms->highmem_ecam) {
> qemu_fdt_setprop_sized_cells(ms->fdt, nodename, "ranges",
> 1, FDT_PCI_RANGE_IOPORT, 2, 0,
> 2, base_pio, 2, size_pio,
> --
> 2.30.2
>
Reviewed-by: Andrew Jones
Thanks,
drew
On Wed, Sep 29, 2021 at 09:09:59AM -0600, Simon Glass wrote:
> Hi Peter,
>
> On Wed, 29 Sept 2021 at 03:10, Peter Maydell wrote:
> >
> > On Wed, 29 Sept 2021 at 04:01, Simon Glass wrote:
> > > On Tue, 28 Sept 2021 at 03:21, Peter Maydell
> > > wrote:
> > > > So what *is* this patch doing? The
0 \
> -numa node,nodeid=1,memdev=m1,initiator=0 \
> -numa cpu,node-id=0,socket-id=0 \
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
ts=sockets][,dies=dies][,cores=cores][,threads=threads]\n"
> "set the number of CPUs to 'n' [default=1]\n"
> "maxcpus= maximum number of total CPUs, including\n"
> "offline CPUs for hotplug, etc\n"
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
node");
> +cli = make_cli(data, "-machine smp.cpus=8,smp.sockets=8 "
> + "-numa node,memdev=ram -numa node");
> qts = qtest_init(cli);
>
> s = qtest_hmp(qts, "info numa");
> --
> 2.23.0
>
Reviewed-by: Andrew Jones
= NULL;
>
> -cli = make_cli(data, "-nodefaults --preconfig -machine smp.cpus=2");
> +cli = make_cli(data, "-nodefaults --preconfig "
> + "-machine smp.cpus=2,smp.sockets=2");
> qs = qtest_init(cli);
>
> /* create 2 numa nodes */
> --
> 2.23.0
>
Reviewed-by: Andrew Jones
On Fri, Sep 10, 2021 at 10:40:30AM +0800, Jingyi Wang wrote:
> Hi all,
> On ARM hardware, as qemu docs describes, "Named CPU models generally
> do not work with KVM." May I ask what is the main obstacle to setting a
> guest CPU model on later host hardware?
Currently KVM does not give the
On Mon, Sep 06, 2021 at 02:31:36PM +0200, Eric Auger wrote:
> This series generates the ACPI DBG2 table along with machvirt.
> It applies on top of Igor's
> [PATCH v2 00/35] acpi: refactor error prone build_header() and
> packed structures usage in ACPI tables
>
> The DBG2 specification can be
On Fri, Sep 03, 2021 at 03:38:13PM +0800, wangyanan (Y) wrote:
>
> On 2021/9/3 15:25, Peter Maydell wrote:
> > On Fri, 3 Sept 2021 at 08:05, wangyanan (Y) wrote:
> > >
> > > On 2021/9/2 23:56, Peter Maydell wrote:
> > > > On Tue, 24 Aug 2021 at 13:20, Yanan Wang wrote:
> > > > > This new
+
> 1 file changed, 48 insertions(+)
>
I already gave my r-b on the last posting, but here it is again
Reviewed-by: Andrew Jones
,
> ARM_CPU_TYPE_NAME("cortex-a72"),
> +ARM_CPU_TYPE_NAME("a64fx"),
> ARM_CPU_TYPE_NAME("host"),
> ARM_CPU_TYPE_NAME("max"),
> };
> --
> 2.27.0
>
Reviewed-by: Andrew Jones
e_enabled(qts, "a64fx", "sve");
> +assert_sve_vls(qts, "a64fx", 0xb, NULL);
> +assert_error(qts, "a64fx", "cannot enable sve384",
> + "{ 'sve384': true }");
> +assert_error(qts, "a64fx", "cannot enable sve640",
> + "{ 'sve640': true }");
> +
> sve_tests_default(qts, "max");
> pauth_tests_default(qts, "max");
>
> --
> 2.27.0
>
Reviewed-by: Andrew Jones
; +
> +/* TODO: Add A64FX specific HPC extension registers */
> +}
> +
> static const ARMCPUInfo aarch64_cpus[] = {
> { .name = "cortex-a57", .initfn = aarch64_a57_initfn },
> { .name = "cortex-a53", .initfn = aarch64_a53_initfn },
says to enable all vector lengths smaller and including sve-max-vq and to
disable all the rest, but if the CPU doesn't support non-power-of-2 vector
lengths, then sve-max-vq will not work for anything other than max-vq=1
and max-vq=2. For this reason, I didn't even bring this property over to
the '
secure_gpio;
> +/* Machines < 6.2 have no support for describing cpu topology to guest */
> +bool no_cpu_topology;
> };
>
> struct VirtMachineState {
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
On Tue, Aug 24, 2021 at 08:28:55AM +0200, Andrew Jones wrote:
> On Mon, Aug 23, 2021 at 10:53:48AM -0700, Richard Henderson wrote:
> > On 8/23/21 9:06 AM, Andrew Jones wrote:
> > > Now that we have an ARMCPU member sve_vq_supported we no longer
> > > need the local kvm
On Mon, Aug 23, 2021 at 10:53:48AM -0700, Richard Henderson wrote:
> On 8/23/21 9:06 AM, Andrew Jones wrote:
> > Now that we have an ARMCPU member sve_vq_supported we no longer
> > need the local kvm_supported bitmap for KVM's supported vector
> > lengths.
> >
>
On Mon, Aug 23, 2021 at 11:04:49AM -0700, Richard Henderson wrote:
> On 8/23/21 9:06 AM, Andrew Jones wrote:
> > Future CPU types may specify which vector lengths are supported.
> > We can apply nearly the same logic to validate those lengths
> > as we do for KVM's support
-of-two or not, smaller than
the maximum enabled length to also be enabled. The architecture
only requires all the power-of-two lengths, though, so TCG will
only enforce that.
Signed-off-by: Andrew Jones
---
target/arm/cpu64.c | 101 -
1 file changed, 45
bitmap_clear() only clears the given range. While the given
range should be sufficient in this case we might as well be
100% sure all bits are zeroed by using bitmap_zero().
Signed-off-by: Andrew Jones
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/kvm64.c | 2 +-
1 file changed, 1
Now that we have an ARMCPU member sve_vq_supported we no longer
need the local kvm_supported bitmap for KVM's supported vector
lengths.
Signed-off-by: Andrew Jones
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/cpu64.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions
with something
that could be shared with TCG.
Thanks,
drew
Andrew Jones (4):
target/arm/cpu: Introduce sve_vq_supported bitmap
target/arm/kvm64: Ensure sve vls map is completely clear
target/arm/cpu64: Replace kvm_supported with sve_vq_supported
target/arm/cpu64: Validate sve vector
' with TCG. And, since 'max' should support all SVE
vector lengths we simply fill the bitmap. Future CPU types may have
less trivial maps though.
Signed-off-by: Andrew Jones
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/cpu.h | 4
target/arm/cpu64.c | 2 ++
2 files changed, 6 insertions
On Thu, Aug 19, 2021 at 09:37:54PM +0200, Andrew Jones wrote:
> While reviewing the new A64FX CPU type it became clear that CPU
> types should be able to specify which SVE vector lengths are
> supported. This series adds a new bitmap member to ARMCPU and
> modifies arm_cpu_
On Thu, Aug 19, 2021 at 09:37:58PM +0200, Andrew Jones wrote:
> Future CPU types may specify which vector lengths are supported.
> We can apply nearly the same logic to validate those lengths
> as we do for KVM's supported vector lengths. We merge the code
> where we can, but unfortu
> On systems that are severely IPA challenged (such as the Apple M1),
> this results in a failure as KVM cannot use the default 40bit that
> '0' represents.
>
> Instead, probe for the extension and use the reported IPA limit
> if available.
>
> Cc: Andrew Jones
> Cc: Eric Auger
>
t;
> The "tls-creds" option should be used instead to point to a "tls-creds-x509"
> object created using "-object".
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
subject format in removed-features.rst to "removed in X.Y".
>
> Signed-off-by: Yanan Wang
> Reviewed-by: Cornelia Huck
> ---
> docs/about/deprecated.rst | 56 -
> docs/about/removed-features.rst | 28 ++++-----
> 2 files changed, 42 insertions(+), 42 deletions(-)
>
Reviewed-by: Andrew Jones
ets* * *cores* * *threads* = *maxcpus*.
> -
> ``-machine enforce-config-section=on|off`` (removed 5.2)
>
>
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
Now that we have an ARMCPU member sve_vq_supported we no longer
need the local kvm_supported bitmap for KVM's supported vector
lengths.
Signed-off-by: Andrew Jones
---
target/arm/cpu64.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/target/arm/cpu64.c
-of-two or not, smaller than
the maximum enabled length to also be enabled. The architecture
only requires all the power-of-two lengths, though, so TCG will
only enforce that.
Signed-off-by: Andrew Jones
---
target/arm/cpu64.c | 101 -
1 file changed, 45
' with TCG. And, since 'max' should support all SVE
vector lengths we simply fill the bitmap. Future CPU types may have
less trivial maps though.
Signed-off-by: Andrew Jones
---
target/arm/cpu.h | 4
target/arm/cpu64.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/target/arm/cpu.h b
bitmap_clear() only clears the given range. While the given
range should be sufficient in this case we might as well be
100% sure all bits are zeroed by using bitmap_zero().
Signed-off-by: Andrew Jones
---
target/arm/kvm64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
more testing and
report back later. I'd also be happy to get test results from
others.
Thanks,
drew
Andrew Jones (4):
target/arm/cpu: Introduce sve_vq_supported bitmap
target/arm/kvm64: Ensure sve vls map is completely clear
target/arm/cpu64: Replace kvm_supported with sve_vq_supported
e 'max' cpu type will have the trivial all-set
supported bitmap, but the a64fx will have a specific one. I plan to
do this "supported" bitmap generalization and apply it to the TCG
max cpu type. You'll need to rebase this series on those patches and
provide the a64fx supported bitmap.
I th
On Tue, Aug 17, 2021 at 05:53:34AM -1000, Richard Henderson wrote:
> On 8/17/21 5:36 AM, Andrew Jones wrote:
> > On Tue, Aug 17, 2021 at 05:23:17AM -1000, Richard Henderson wrote:
> > > On 8/17/21 1:56 AM, Andrew Jones wrote:
> > > > I guess it's fine.
On Tue, Aug 17, 2021 at 05:23:17AM -1000, Richard Henderson wrote:
> On 8/17/21 1:56 AM, Andrew Jones wrote:
> > I guess it's fine. You could easily create a new cpu_arm_set_sve_vq()
> > which would forbid changing the properties if you wanted to, but then
> > we need to an
On Tue, Aug 17, 2021 at 01:37:15PM +0100, Peter Maydell wrote:
> On Tue, 17 Aug 2021 at 13:22, Andrew Jones wrote:
> >
> > On Tue, Aug 17, 2021 at 01:06:19PM +0100, Peter Maydell wrote:
> > > On Tue, 17 Aug 2021 at 13:02, Andrew Jones wrote:
> > > >
> &
d documenting behaviors we want to leave undefined for the time
being, giving us freedom to change it later.
Fixes: 1e63fe685804 ("machine: pass QAPI struct to mc->smp_parse")
Signed-off-by: Andrew Jones
---
qapi/machine.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
On Tue, Aug 17, 2021 at 01:06:19PM +0100, Peter Maydell wrote:
> On Tue, 17 Aug 2021 at 13:02, Andrew Jones wrote:
> >
> > On Mon, Aug 16, 2021 at 11:37:21PM +0200, Paolo Bonzini wrote:
> > > How do we know that no one has ever used such configuration? The
> >
meaningless configurations possibly introduced by users
> > in the future and consequently a necessary deprecation process,
> > fix the doc and also add the corresponding sanity check.
> >
> > Fixes: 1e63fe68580 (machine: pass QAPI struct to mc->smp_parse)
> > Suggeste
On Tue, Aug 17, 2021 at 06:43:58AM +, ishii.shuuic...@fujitsu.com wrote:
>
> > On Thu, 12 Aug 2021 at 10:25, Andrew Jones wrote:
> > > On second thought, do we want the QMP CPU model expansion query to
> > > show that this CPU type has sve,sve128,sve256,sve512? If
On Tue, Aug 17, 2021 at 10:10:44AM +0800, wangyanan (Y) wrote:
> Hi,
> On 2021/8/5 20:39, Yanan Wang wrote:
> > From: Andrew Jones
> >
> > Support device tree CPU topology descriptions.
> >
> > In accordance with the Devicetree Specification, the Linux Doc
&g
On Thu, Aug 12, 2021 at 11:16:50AM +0200, Andrew Jones wrote:
> On Thu, Aug 12, 2021 at 03:04:38PM +0900, Shuuichirou Ishii wrote:
> > Add a definition for the Fujitsu A64FX processor.
> >
> > The A64FX processor does not implement the AArch32 Execution state,
> >
= 6; /* 256 bytes */
> +cpu->gic_num_lrs = 4;
> +cpu->gic_vpribits = 5;
> +cpu->gic_vprebits = 5;
> +
> +/* TODO: Add A64FX specific HPC extension registers */
> +}
> +
> static const ARMCPUInfo aarch64_cpus[] = {
> { .name = "cortex-a57", .initfn = aarch64_a57_initfn },
> { .name = "cortex-a53", .initfn = aarch64_a53_initfn },
> { .name = "cortex-a72", .initfn = aarch64_a72_initfn },
> +{ .name = "a64fx", .initfn = aarch64_a64fx_initfn },
> { .name = "max",.initfn = aarch64_max_initfn },
> };
>
> --
> 2.27.0
>
For the SVE related bits
Reviewed-by: Andrew Jones
On Tue, Aug 10, 2021 at 12:25:07PM +0200, Eric Auger wrote:
> Hello Ard,
> On 8/10/21 11:36 AM, Ard Biesheuvel wrote:
> > On Tue, 10 Aug 2021 at 10:31, Eric Auger wrote:
> >> ARM SBBR specification mandates DBG2 table (Debug Port Table 2).
> >> this latter allows to describe one or more debug
erty_add(obj, "sve-max-vq", "uint32", cpu_max_get_sve_max_vq,
> -cpu_max_set_sve_max_vq, NULL, NULL);
> }
>
> static const ARMCPUInfo aarch64_cpus[] = {
Otherwise looks OK to me.
Thanks,
drew
>
> ---
>
> Best regards.
On Thu, Aug 05, 2021 at 04:30:43PM +0900, Shuuichirou Ishii wrote:
> Add a definition for the Fujitsu A64FX processor.
>
> The A64FX processor does not implement the AArch32 Execution state,
> so there are no associated AArch32 Identification registers.
>
> Signed-off-by: Shuuichirou Ishii
>
s(+)
> create mode 100644 tests/unit/test-smp-parse.c
>
Reviewed-by: Andrew Jones
++
> hw/core/machine.c | 177 -
> hw/core/meson.build | 1 +
> include/hw/boards.h | 1 +
> 5 files changed, 202 insertions(+), 177 deletions(-)
> create mode 100644 hw/core/machine-smp.c
>
Reviewed-by: Andrew Jones
tested only by calling the parser.
>
> Signed-off-by: Yanan Wang
> ---
> hw/core/machine.c | 63 +++
> 1 file changed, 31 insertions(+), 32 deletions(-)
>
Reviewed-by: Andrew Jones
initially like other members, cleanup the
> sanity check for dies.
>
> No functional change intended.
>
> Signed-off-by: Yanan Wang
> ---
> hw/core/machine.c | 19 +++
> hw/i386/pc.c | 23 ++-
> 2 files changed, 25 insertions(
3671a0f8f 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -110,9 +110,11 @@ typedef struct {
>
> /**
> * SMPCompatProps:
> + * @prefer_sockets - whether sockets is preferred over cores in smp parsing
> * @dies_supported - whether dies is supported by the machine
> */
> typedef struct {
> +bool prefer_sockets;
> bool dies_supported;
> } SMPCompatProps;
>
> @@ -250,7 +252,6 @@ struct MachineClass {
> bool nvdimm_supported;
> bool numa_mem_supported;
> bool auto_enable_numa;
> -bool smp_prefer_sockets;
> SMPCompatProps smp_props;
> const char *default_ram_id;
>
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
On Wed, Jul 28, 2021 at 10:38:57PM +0200, Andrew Jones wrote:
> On Wed, Jul 28, 2021 at 11:48:46AM +0800, Yanan Wang wrote:
> > @@ -248,6 +256,7 @@ struct MachineClass {
> > bool numa_mem_supported;
> > bool auto_enable_numa;
> > bool smp_prefer_socke
owed. Return
> @@ -217,7 +213,6 @@ struct MachineClass {
> void (*reset)(MachineState *state);
> void (*wakeup)(MachineState *state);
> int (*kvm_type)(MachineState *machine, const char *arg);
> -void (*smp_parse)(MachineState *ms, SMPConfiguration *config, Error
> **errp);
>
> BlockInterfaceType block_default_type;
> int units_per_default_bus;
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
p_parse generic enough for all arches and the PC specific
> one can be removed.
>
> Making smp_parse() generic enough can reduce code duplication and
> ease the code maintenance, and also allows extending the topology
> with more arch specific members (e.g., clusters) in the fu
"6.1", false);
>
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 463a5514f9..2ae039b74f 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -247,6 +247,7 @@ struct MachineClass {
> bool nvdimm_supported;
> bool numa_mem_supported;
> bool auto_enable_numa;
> +bool smp_prefer_sockets;
> const char *default_ram_id;
>
> HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 0912236b4b..450f511ca7 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -234,7 +234,8 @@ SRST
> Historically preference was given to the coarsest topology parameters
> when computing missing values (ie sockets preferred over cores, which
> were preferred over threads), however, this behaviour is considered
> -liable to change.
> +liable to change. Prior to 6.2 the preference was sockets over cores
> +over threads. Since 6.2 the preference is cores over sockets over
> threads.
> ERST
>
> DEF("numa", HAS_ARG, QEMU_OPTION_numa,
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
eads != maxcpus) {
> -error_setg(errp, "Invalid CPU topology deprecated: "
> +error_setg(errp, "Invalid CPU topology: "
> + "maxcpus must be equal to or greater than smp: "
> "sockets (%u) * dies (%u) * cores (%u) * threads (%u) "
> - "!= maxcpus (%u)",
> - sockets, dies, cores, threads,
> - maxcpus);
> + "== maxcpus (%u) < smp_cpus (%u)",
> + sockets, dies, cores, threads, maxcpus, cpus);
> return;
> }
>
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
ill match the maximum number. When only one of them
> +is given then the omitted one will be set to its counterpart's value.
> +Both parameters may be specified, but the maximum number of CPUs must
> +equal to or greater than the initial CPU count. Both parameters are
be equal to
> +subject to an upper limit that is determined by the specific machine
> +type chosen.
>
> To control reporting of CPU topology information, the number of sockets,
> dies per socket, cores per die, and threads per core can be specified.
> --
> 2.19.1
>
Otherwise
Reviewed-by: Andrew Jones
On Wed, Jul 28, 2021 at 11:48:38AM +0800, Yanan Wang wrote:
> To pave the way for the functional improvement in later patches,
> make some refactor/cleanup for the smp parsers, including using
> local maxcpus instead of ms->smp.max_cpus in the calculation,
> defaulting dies to 0 initially like
On Mon, Jul 26, 2021 at 08:33:52AM -1000, Richard Henderson wrote:
> On 7/26/21 4:59 AM, Andrew Jones wrote:
> > > +SVE User-mode Default Vector Length Property
> > > +
> > > +
> > > +For qemu-aarch64, the cp
On Mon, Jul 26, 2021 at 01:42:45PM +0100, Peter Maydell wrote:
> On Fri, 23 Jul 2021 at 21:34, Richard Henderson
> wrote:
> >
> > This is intended to resolve #482.
> >
> > Changes for v2:
> > * Split out length bounding fix to new patch.
> > * Use byte units for sve-default-vector-length.
> >
On Fri, Jul 23, 2021 at 10:33:44AM -1000, Richard Henderson wrote:
> Mirror the behavour of /proc/sys/abi/sve_default_vector_length
> under the real linux kernel. We have no way of passing along
> a real default across exec like the kernel can, but this is a
> decent way of adjusting the startup
comment for SMPConfiguration. So this patch fixes the doc and
> also adds the corresponding sanity check in the smp parsers.
>
> Suggested-by: Andrew Jones
> Signed-off-by: Yanan Wang
> ---
> hw/core/machine.c | 14 ++
> qapi/machine.json | 6 +++---
> qemu-opt
On Thu, Jul 22, 2021 at 10:59:11PM +0800, wangyanan (Y) wrote:
> Ok. If we remove the rounding, then the calculation code has to be modified
> to be like the following. We have to separately consider the case that cpus
> and maxcpus are both omitted (e.g. -smp sockets=16).
>
> maxcpus = maxcpus >
On Thu, Jul 22, 2021 at 08:02:16AM +0200, Cornelia Huck wrote:
> On Thu, Jul 22 2021, Yanan Wang wrote:
>
> > In the SMP configuration, we should either specify a topology
> > parameter with a reasonable value (equal to or greater than 1)
> > or just leave it omitted and QEMU will calculate its
On Thu, Jul 22, 2021 at 02:15:18PM +0800, wangyanan (Y) wrote:
> On 2021/7/20 2:57, Andrew Jones wrote:
> > On Mon, Jul 19, 2021 at 11:20:43AM +0800, Yanan Wang wrote:
> > > Add a QEMU unit test for the parsing of given SMP configuration.
> > > Since all the parsing l
On Thu, Jul 22, 2021 at 02:24:03PM +0800, wangyanan (Y) wrote:
> On 2021/7/20 1:20, Andrew Jones wrote:
> > On Mon, Jul 19, 2021 at 11:20:42AM +0800, Yanan Wang wrote:
> > > We are going to introduce an unit test for the parser smp_parse()
> > > in hw/core/machine.c
On Thu, Jul 22, 2021 at 04:10:32PM +0800, wangyanan (Y) wrote:
> On 2021/7/20 0:53, Andrew Jones wrote:
> > On Mon, Jul 19, 2021 at 11:20:37AM +0800, Yanan Wang wrote:
> > > We totally have two requirements for a valid SMP configuration:
> > s/totally//
> >
&g
On Thu, Jul 22, 2021 at 12:42:55PM +0800, wangyanan (Y) wrote:
> On 2021/7/20 0:42, Andrew Jones wrote:
> > On Mon, Jul 19, 2021 at 11:20:36AM +0800, Yanan Wang wrote:
> > > Currently we directly calculate the omitted cpus based on the already
> > > provided parameter
On Mon, Jul 19, 2021 at 11:20:43AM +0800, Yanan Wang wrote:
> Add a QEMU unit test for the parsing of given SMP configuration.
> Since all the parsing logic is in generic function smp_parse(),
> this test passes diffenent SMP configurations to the function
> and compare the parsing result with
lt; "
> - "smp_cpus (%u)",
> - sockets, dies_msg, cores, threads, cpus);
> -return;
> -}
> -
> -ms->smp.cpus = cpus;
> -ms->smp.sockets = sockets;
> -ms->smp.dies = dies;
> -ms->smp.cores = cores;
> -ms->smp.threads = threads;
> -ms->smp.max_cpus = maxcpus;
> -}
> -
> static void machine_get_smp(Object *obj, Visitor *v, const char *name,
> void *opaque, Error **errp)
> {
> diff --git a/hw/core/meson.build b/hw/core/meson.build
> index 18f44fb7c2..6d727c7742 100644
> --- a/hw/core/meson.build
> +++ b/hw/core/meson.build
> @@ -14,6 +14,7 @@ hwcore_files = files(
> )
>
> common_ss.add(files('cpu-common.c'))
> +common_ss.add(files('machine-smp.c'))
> common_ss.add(when: 'CONFIG_FITLOADER', if_true: files('loader-fit.c'))
> common_ss.add(when: 'CONFIG_GENERIC_LOADER', if_true:
> files('generic-loader.c'))
> common_ss.add(when: ['CONFIG_GUEST_LOADER', fdt], if_true:
> files('guest-loader.c'))
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 12ab0f5968..071eec1e74 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -34,6 +34,7 @@ HotpluggableCPUList
> *machine_query_hotpluggable_cpus(MachineState *machine);
> void machine_set_cpu_numa_node(MachineState *machine,
> const CpuInstanceProperties *props,
> Error **errp);
> +void smp_parse(MachineState *ms, SMPConfiguration *config, Error **errp);
>
> /**
> * machine_class_allow_dynamic_sysbus_dev: Add type to list of valid devices
> --
> 2.19.1
>
Otherwise
Reviewed-by: Andrew Jones
t;supported by machine '%s' is %d",
> - current_machine->smp.max_cpus,
> + ms->smp.max_cpus,
> mc->name, mc->max_cpus);
> }
>
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
On Mon, Jul 19, 2021 at 11:20:39AM +0800, Yanan Wang wrote:
> In the real SMP hardware topology world, it's much more likely that
> we have high cores-per-socket counts and few sockets totally. While
> the current preference of sockets over cores in smp parsing results
> in a virtual cpu topology
32f0f8aa 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -354,6 +354,9 @@ struct MachineState {
> } \
> type_init(machine_initfn##_register_types)
>
> +extern GlobalProperty hw_compat_6_1[];
> +extern const size_t hw_compat_6_1_len;
> +
> extern GlobalProperty hw_compat_6_0[];
> extern const size_t hw_compat_6_0_len;
>
Arm and general parts look good to me
Reviewed-by: Andrew Jones
On Mon, Jul 19, 2021 at 11:20:37AM +0800, Yanan Wang wrote:
> We totally have two requirements for a valid SMP configuration:
s/totally//
> the sum of "sockets * dies * cores * threads" must represent all
the product
> the possible cpus, i.e., max_cpus, and must include the initial
> present
On Mon, Jul 19, 2021 at 05:36:39PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jul 19, 2021 at 06:28:46PM +0200, Andrew Jones wrote:
> > On Mon, Jul 19, 2021 at 11:20:34AM +0800, Yanan Wang wrote:
> > > Currently the only difference between smp_parse and pc_smp_parse
> > &
On Mon, Jul 19, 2021 at 11:20:36AM +0800, Yanan Wang wrote:
> Currently we directly calculate the omitted cpus based on the already
> provided parameters. This makes some cmdlines like:
> -smp maxcpus=16
> -smp sockets=2,maxcpus=16
> -smp sockets=2,dies=2,maxcpus=16
> -smp
_dies_supported ? " * dies (%u)" : "", dies);
> error_setg(errp, "cpu topology: "
> @@ -795,8 +797,6 @@ static void smp_parse(MachineState *ms, SMPConfiguration
> *config, Error **errp)
> return;
> }
>
> -maxcpus = maxcpus > 0 ? maxcpus : cpus;
> -
> if (maxcpus < cpus) {
> error_setg(errp, "maxcpus must be equal to or greater than smp");
> return;
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
e.
>
> No functional change intended.
>
> Suggested-by: Andrew Jones
> Signed-off-by: Yanan Wang
> ---
> hw/core/machine.c | 28 ++---
> hw/i386/pc.c| 76 +
> include/hw/boards.h | 1 +
> 3 files c
licitly specify the topology parameters
> as zero like "sockets=0" are meaningless, so disallow them.
>
> Suggested-by: Andrew Jones
> Signed-off-by: Yanan Wang
> ---
> hw/core/machine.c | 31 +++
> hw/i386/pc.c | 29 +
On Mon, Jul 19, 2021 at 11:30:41AM +0200, Vitaly Kuznetsov wrote:
> Andrew Jones writes:
>
> > On Fri, Jul 16, 2021 at 02:55:28PM +0200, Vitaly Kuznetsov wrote:
> >> For the beginning, just test 'hv-passthrough' and a couple of custom
> >> Hyper-V enlightenme
On Fri, Jul 16, 2021 at 02:55:28PM +0200, Vitaly Kuznetsov wrote:
> For the beginning, just test 'hv-passthrough' and a couple of custom
> Hyper-V enlightenments configurations through QMP. Later, it would
> be great to complement this by checking CPUID values from within the
> guest.
>
>
> tweak the comment by adding explanation of dies parameter.
>
> Signed-off-by: Yanan Wang
> ---
> hw/core/machine.c | 4 ++--
> include/hw/boards.h | 7 ---
> 2 files changed, 6 insertions(+), 5 deletions(-)
Reviewed-by: Andrew Jones
On Mon, Jul 12, 2021 at 05:05:43PM +0200, Andrew Jones wrote:
> On Mon, Jul 12, 2021 at 05:04:04PM +0200, Andrew Jones wrote:
> > On Fri, Jul 02, 2021 at 06:07:36PM +0800, Yanan Wang wrote:
> > > It's possible that dies parameter is explicitly specified as "dies=0"
&g
On Fri, Jul 02, 2021 at 06:07:37PM +0800, Yanan Wang wrote:
> We are currently using maxcpus to calculate value of sockets but using
> cpus to calculate value of cores/threads. This makes cmdlines like
> "-smp 8,maxcpus=12,cores=4" work while "-smp 8,maxcpus=12,sockets=3"
> break the invalid cpu
On Mon, Jul 12, 2021 at 05:04:04PM +0200, Andrew Jones wrote:
> On Fri, Jul 02, 2021 at 06:07:36PM +0800, Yanan Wang wrote:
> > It's possible that dies parameter is explicitly specified as "dies=0"
> > in the cmdline, if so we will wrongly calculate the oth
t;
> with a zeroed dies value.
>
> So perform zero-check (default the value to 1 if zeroed) for -smp dies
> before using it to calculate other parameters.
OK, dies=0 may make some sense for a user that doesn't want to describe
dies.
Reviewed-by: Andrew Jones
>
> Fixes: 1b4
On Fri, Jul 02, 2021 at 06:07:34PM +0800, Yanan Wang wrote:
> It is currently allowed to explicitly specified the topology parameters
> as 0 in the -smp cmdlines, such as -smp cpus=8,maxcpus=0,sockets=0. And
> for the values of cpus/sockets/cores/threads, we always determine that
> they are
On Fri, Jul 02, 2021 at 06:07:35PM +0800, Yanan Wang wrote:
> We currently perform zero-check (default the value to 1 if zeroed)
> for the computed values of cores/threads, to make sure they are at
> least 1. For consistency, we probably should also default sockets
> to 1 if the computed value is
On Wed, Jun 30, 2021 at 05:37:42PM +0800, wangyanan (Y) wrote:
> On 2021/6/30 16:30, Andrew Jones wrote:
> > On Wed, Jun 30, 2021 at 02:36:31PM +0800, wangyanan (Y) wrote:
> > > Hi Drew, Igor,
> > >
> > > I have a question below, hope for some expla
use the machine compat stuff to switch to it. And also properly
document it with something like "Since 6.2..."
Thanks,
drew
>
> Regards,
> Yanan
> .
>
> On 2021/6/28 16:58, Andrew Jones wrote:
> > On Mon, Jun 28, 2021 at 04:43:05PM +0800, wangyanan (Y) wrote:
>
501 - 600 of 2433 matches
Mail list logo
