* [PATCH 0/2] ppc64: do not use MachineClass::max_cpus to limit CPUs @ 2021-04-08 20:40 Daniel Henrique Barboza 2021-04-08 20:40 ` [PATCH 1/2] spapr.c: " Daniel Henrique Barboza 2021-04-08 20:40 ` [PATCH 2/2] spapr.h: increase FDT_MAX_SIZE Daniel Henrique Barboza 0 siblings, 2 replies; 6+ messages in thread From: Daniel Henrique Barboza @ 2021-04-08 20:40 UTC (permalink / raw) To: qemu-devel; +Cc: Daniel Henrique Barboza, qemu-ppc, groug, david Hello, After having to change hardcoded values to launch a 2048 KVM pSeries guests I decided to post these upstream because, at least for me, the current max_cpus usage is lackluster for pSeries. More info in patch 01. Patch 02 is a trivial follow-up to increase the FDT size. Daniel Henrique Barboza (2): spapr.c: do not use MachineClass::max_cpus to limit CPUs spapr.h: increase FDT_MAX_SIZE hw/ppc/spapr.c | 11 ++++++++++- include/hw/ppc/spapr.h | 2 +- 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.30.2 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/2] spapr.c: do not use MachineClass::max_cpus to limit CPUs 2021-04-08 20:40 [PATCH 0/2] ppc64: do not use MachineClass::max_cpus to limit CPUs Daniel Henrique Barboza @ 2021-04-08 20:40 ` Daniel Henrique Barboza 2021-04-19 5:40 ` David Gibson 2021-04-08 20:40 ` [PATCH 2/2] spapr.h: increase FDT_MAX_SIZE Daniel Henrique Barboza 1 sibling, 1 reply; 6+ messages in thread From: Daniel Henrique Barboza @ 2021-04-08 20:40 UTC (permalink / raw) To: qemu-devel; +Cc: Daniel Henrique Barboza, qemu-ppc, groug, david Up to this patch, 'max_cpus' value is hardcoded to 1024 (commit 6244bb7e5811). In theory this patch would simply bump it to 2048, since it's the default NR_CPUS kernel setting for ppc64 servers nowadays, but the whole mechanic of MachineClass:max_cpus is flawed for the pSeries machine. The two supported accelerators, KVM and TCG, can live without it. TCG guests don't have a theoretical limit. The user must be free to emulate as many CPUs as the hardware is capable of. And even if there were a limit, max_cpus is not the proper way to report it since it's a common value checked by SMP code in machine_smp_parse() for KVM as well. For KVM guests, the proper way to limit KVM CPUs is by host configuration via NR_CPUS, not a QEMU hardcoded value. There is no technical reason for a pSeries QEMU guest to forcefully stay below NR_CPUS. This hardcoded value also disregard hosts that might have a lower NR_CPUS limit, say 512. In this case, machine.c:machine_smp_parse() will allow a 1024 value to pass, but then kvm_init() will complain about it because it will exceed NR_CPUS: Number of SMP cpus requested (1024) exceeds the maximum cpus supported by KVM (512) A better 'max_cpus' value would consider host settings, but MachineClass::max_cpus is defined well before machine_init() and kvm_init(). We can't check for KVM limits because it's too soon, so we end up making a guess. This patch makes MachineClass:max_cpus settings innocuous by setting it to INT32_MAX. machine.c:machine_smp_parse() will not fail the verification based on max_cpus, letting kvm_init() do the checking with actual host settings. And TCG guests get to do whatever the hardware is capable of emulating. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- hw/ppc/spapr.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 73a06df3b1..d6a67da21f 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -4482,7 +4482,16 @@ static void spapr_machine_class_init(ObjectClass *oc, void *data) mc->init = spapr_machine_init; mc->reset = spapr_machine_reset; mc->block_default_type = IF_SCSI; - mc->max_cpus = 1024; + + /* + * Setting max_cpus to INT32_MAX. Both KVM and TCG max_cpus values + * should be limited by the host capability instead of hardcoded. + * max_cpus for KVM guests will be checked in kvm_init(), and TCG + * guests are welcome to have as many CPUs as the host are capable + * of emulate. + */ + mc->max_cpus = INT32_MAX; + mc->no_parallel = 1; mc->default_boot_order = ""; mc->default_ram_size = 512 * MiB; -- 2.30.2 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] spapr.c: do not use MachineClass::max_cpus to limit CPUs 2021-04-08 20:40 ` [PATCH 1/2] spapr.c: " Daniel Henrique Barboza @ 2021-04-19 5:40 ` David Gibson 0 siblings, 0 replies; 6+ messages in thread From: David Gibson @ 2021-04-19 5:40 UTC (permalink / raw) To: Daniel Henrique Barboza; +Cc: qemu-ppc, qemu-devel, groug [-- Attachment #1: Type: text/plain, Size: 3406 bytes --] On Thu, Apr 08, 2021 at 05:40:48PM -0300, Daniel Henrique Barboza wrote: > Up to this patch, 'max_cpus' value is hardcoded to 1024 (commit > 6244bb7e5811). In theory this patch would simply bump it to 2048, since > it's the default NR_CPUS kernel setting for ppc64 servers nowadays, but > the whole mechanic of MachineClass:max_cpus is flawed for the pSeries > machine. The two supported accelerators, KVM and TCG, can live without > it. > > TCG guests don't have a theoretical limit. The user must be free to > emulate as many CPUs as the hardware is capable of. And even if there > were a limit, max_cpus is not the proper way to report it since it's a > common value checked by SMP code in machine_smp_parse() for KVM as well. > > For KVM guests, the proper way to limit KVM CPUs is by host > configuration via NR_CPUS, not a QEMU hardcoded value. There is no > technical reason for a pSeries QEMU guest to forcefully stay below > NR_CPUS. > > This hardcoded value also disregard hosts that might have a lower > NR_CPUS limit, say 512. In this case, machine.c:machine_smp_parse() will > allow a 1024 value to pass, but then kvm_init() will complain about it > because it will exceed NR_CPUS: > > Number of SMP cpus requested (1024) exceeds the maximum cpus supported > by KVM (512) > > A better 'max_cpus' value would consider host settings, but > MachineClass::max_cpus is defined well before machine_init() and > kvm_init(). We can't check for KVM limits because it's too soon, so we > end up making a guess. Well.. it's not so much that we're guessing KVM limits. I think max_cpus in the generic code is more about hard CPU limits which are part of the machine architecture itself. You're right that that doesn't really make sense for the paravirtual PAPR machine though. > This patch makes MachineClass:max_cpus settings innocuous by setting it > to INT32_MAX. machine.c:machine_smp_parse() will not fail the > verification based on max_cpus, letting kvm_init() do the checking with > actual host settings. And TCG guests get to do whatever the hardware is > capable of emulating. > > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Applied to ppc-for-6.1. > --- > hw/ppc/spapr.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index 73a06df3b1..d6a67da21f 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -4482,7 +4482,16 @@ static void spapr_machine_class_init(ObjectClass *oc, void *data) > mc->init = spapr_machine_init; > mc->reset = spapr_machine_reset; > mc->block_default_type = IF_SCSI; > - mc->max_cpus = 1024; > + > + /* > + * Setting max_cpus to INT32_MAX. Both KVM and TCG max_cpus values > + * should be limited by the host capability instead of hardcoded. > + * max_cpus for KVM guests will be checked in kvm_init(), and TCG > + * guests are welcome to have as many CPUs as the host are capable > + * of emulate. > + */ > + mc->max_cpus = INT32_MAX; > + > mc->no_parallel = 1; > mc->default_boot_order = ""; > mc->default_ram_size = 512 * MiB; -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 2/2] spapr.h: increase FDT_MAX_SIZE 2021-04-08 20:40 [PATCH 0/2] ppc64: do not use MachineClass::max_cpus to limit CPUs Daniel Henrique Barboza 2021-04-08 20:40 ` [PATCH 1/2] spapr.c: " Daniel Henrique Barboza @ 2021-04-08 20:40 ` Daniel Henrique Barboza 2021-04-19 5:41 ` David Gibson 2021-04-29 14:03 ` Cédric Le Goater 1 sibling, 2 replies; 6+ messages in thread From: Daniel Henrique Barboza @ 2021-04-08 20:40 UTC (permalink / raw) To: qemu-devel; +Cc: Daniel Henrique Barboza, qemu-ppc, groug, david Certain SMP topologies stress, e.g. 1 thread/core, 2048 cores and 1 socket, stress the current maximum size of the pSeries FDT: Calling ibm,client-architecture-support...qemu-system-ppc64: error creating device tree: (fdt_setprop(fdt, offset, "ibm,processor-segment-sizes", segs, sizeof(segs))): FDT_ERR_NOSPACE 2048 is the default NR_CPUS value for the pSeries kernel. It's expected that users will want QEMU to be able to handle this kind of configuration. Bumping FDT_MAX_SIZE to 2MB is enough for these setups to be created. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- include/hw/ppc/spapr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h index bf7cab7a2c..3deb382678 100644 --- a/include/hw/ppc/spapr.h +++ b/include/hw/ppc/spapr.h @@ -95,7 +95,7 @@ typedef enum { #define SPAPR_CAP_FIXED_CCD 0x03 #define SPAPR_CAP_FIXED_NA 0x10 /* Lets leave a bit of a gap... */ -#define FDT_MAX_SIZE 0x100000 +#define FDT_MAX_SIZE 0x200000 /* * NUMA related macros. MAX_DISTANCE_REF_POINTS was taken -- 2.30.2 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] spapr.h: increase FDT_MAX_SIZE 2021-04-08 20:40 ` [PATCH 2/2] spapr.h: increase FDT_MAX_SIZE Daniel Henrique Barboza @ 2021-04-19 5:41 ` David Gibson 2021-04-29 14:03 ` Cédric Le Goater 1 sibling, 0 replies; 6+ messages in thread From: David Gibson @ 2021-04-19 5:41 UTC (permalink / raw) To: Daniel Henrique Barboza; +Cc: qemu-ppc, qemu-devel, groug [-- Attachment #1: Type: text/plain, Size: 1561 bytes --] On Thu, Apr 08, 2021 at 05:40:49PM -0300, Daniel Henrique Barboza wrote: > Certain SMP topologies stress, e.g. 1 thread/core, 2048 cores and > 1 socket, stress the current maximum size of the pSeries FDT: > > Calling ibm,client-architecture-support...qemu-system-ppc64: error > creating device tree: (fdt_setprop(fdt, offset, > "ibm,processor-segment-sizes", segs, sizeof(segs))): FDT_ERR_NOSPACE > > 2048 is the default NR_CPUS value for the pSeries kernel. It's expected > that users will want QEMU to be able to handle this kind of > configuration. > > Bumping FDT_MAX_SIZE to 2MB is enough for these setups to be created. > > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Applied to ppc-for-6.1, thanks. > --- > include/hw/ppc/spapr.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h > index bf7cab7a2c..3deb382678 100644 > --- a/include/hw/ppc/spapr.h > +++ b/include/hw/ppc/spapr.h > @@ -95,7 +95,7 @@ typedef enum { > #define SPAPR_CAP_FIXED_CCD 0x03 > #define SPAPR_CAP_FIXED_NA 0x10 /* Lets leave a bit of a gap... */ > > -#define FDT_MAX_SIZE 0x100000 > +#define FDT_MAX_SIZE 0x200000 > > /* > * NUMA related macros. MAX_DISTANCE_REF_POINTS was taken -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] spapr.h: increase FDT_MAX_SIZE 2021-04-08 20:40 ` [PATCH 2/2] spapr.h: increase FDT_MAX_SIZE Daniel Henrique Barboza 2021-04-19 5:41 ` David Gibson @ 2021-04-29 14:03 ` Cédric Le Goater 1 sibling, 0 replies; 6+ messages in thread From: Cédric Le Goater @ 2021-04-29 14:03 UTC (permalink / raw) To: Daniel Henrique Barboza, qemu-devel; +Cc: qemu-ppc, groug, david On 4/8/21 10:40 PM, Daniel Henrique Barboza wrote: > Certain SMP topologies stress, e.g. 1 thread/core, 2048 cores and > 1 socket, stress the current maximum size of the pSeries FDT: > > Calling ibm,client-architecture-support...qemu-system-ppc64: error > creating device tree: (fdt_setprop(fdt, offset, > "ibm,processor-segment-sizes", segs, sizeof(segs))): FDT_ERR_NOSPACE > > 2048 is the default NR_CPUS value for the pSeries kernel. It's expected > that users will want QEMU to be able to handle this kind of > configuration. > > Bumping FDT_MAX_SIZE to 2MB is enough for these setups to be created. > > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> > --- > include/hw/ppc/spapr.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h > index bf7cab7a2c..3deb382678 100644 > --- a/include/hw/ppc/spapr.h > +++ b/include/hw/ppc/spapr.h > @@ -95,7 +95,7 @@ typedef enum { > #define SPAPR_CAP_FIXED_CCD 0x03 > #define SPAPR_CAP_FIXED_NA 0x10 /* Lets leave a bit of a gap... */ > > -#define FDT_MAX_SIZE 0x100000 > +#define FDT_MAX_SIZE 0x200000 > > /* > * NUMA related macros. MAX_DISTANCE_REF_POINTS was taken > FYI, On a very large system, I also had to bump the FDT_MAX_SIZE value in softmmu/device-tree.c because QEMU is parsing the host DT. Thanks, C. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-29 14:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-08 20:40 [PATCH 0/2] ppc64: do not use MachineClass::max_cpus to limit CPUs Daniel Henrique Barboza 2021-04-08 20:40 ` [PATCH 1/2] spapr.c: " Daniel Henrique Barboza 2021-04-19 5:40 ` David Gibson 2021-04-08 20:40 ` [PATCH 2/2] spapr.h: increase FDT_MAX_SIZE Daniel Henrique Barboza 2021-04-19 5:41 ` David Gibson 2021-04-29 14:03 ` Cédric Le Goater
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).