| Message ID | 20240327152229.25847-9-jgross@suse.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | xen/spinlock: make recursive spinlocks a dedicated type | expand |
On 27.03.2024 16:22, Juergen Gross wrote: > With lock handling now allowing up to 16384 cpus (spinlocks can handle > 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for > the number of cpus to be configured to 16383. > > The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and > QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS. > > Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Jan Beulich <jbeulich@suse.com> I'd prefer this to also gain an Arm ack, though. Jan > --- a/xen/arch/Kconfig > +++ b/xen/arch/Kconfig > @@ -6,7 +6,7 @@ config PHYS_ADDR_T_32 > > config NR_CPUS > int "Maximum number of CPUs" > - range 1 4095 > + range 1 16383 > default "256" if X86 > default "8" if ARM && RCAR3 > default "4" if ARM && QEMU
On 08.04.24 09:10, Jan Beulich wrote: > On 27.03.2024 16:22, Juergen Gross wrote: >> With lock handling now allowing up to 16384 cpus (spinlocks can handle >> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for >> the number of cpus to be configured to 16383. >> >> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and >> QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS. >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > Acked-by: Jan Beulich <jbeulich@suse.com> > > I'd prefer this to also gain an Arm ack, though. Any comment from Arm side? Juergen > > Jan > >> --- a/xen/arch/Kconfig >> +++ b/xen/arch/Kconfig >> @@ -6,7 +6,7 @@ config PHYS_ADDR_T_32 >> >> config NR_CPUS >> int "Maximum number of CPUs" >> - range 1 4095 >> + range 1 16383 >> default "256" if X86 >> default "8" if ARM && RCAR3 >> default "4" if ARM && QEMU > >
Hi Juergen, Sorry for the late reply. On 29/04/2024 11:33, Juergen Gross wrote: > On 08.04.24 09:10, Jan Beulich wrote: >> On 27.03.2024 16:22, Juergen Gross wrote: >>> With lock handling now allowing up to 16384 cpus (spinlocks can handle >>> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for >>> the number of cpus to be configured to 16383. >>> >>> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and >>> QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS. >>> >>> Signed-off-by: Juergen Gross <jgross@suse.com> >> >> Acked-by: Jan Beulich <jbeulich@suse.com> >> >> I'd prefer this to also gain an Arm ack, though. > > Any comment from Arm side? Can you clarify what the new limits mean in term of (security) support? Are we now claiming that Xen will work perfectly fine on platforms with up to 16383? If so, I can't comment for x86, but for Arm, I am doubtful that it would work without any (at least performance) issues. AFAIK, this is also an untested configuration. In fact I would be surprised if Xen on Arm was tested with more than a couple of hundreds cores (AFAICT the Ampere CPUs has 192 CPUs). Cheers,
On 29.04.24 13:04, Julien Grall wrote: > Hi Juergen, > > Sorry for the late reply. > > On 29/04/2024 11:33, Juergen Gross wrote: >> On 08.04.24 09:10, Jan Beulich wrote: >>> On 27.03.2024 16:22, Juergen Gross wrote: >>>> With lock handling now allowing up to 16384 cpus (spinlocks can handle >>>> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for >>>> the number of cpus to be configured to 16383. >>>> >>>> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and >>>> QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS. >>>> >>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>> >>> Acked-by: Jan Beulich <jbeulich@suse.com> >>> >>> I'd prefer this to also gain an Arm ack, though. >> >> Any comment from Arm side? > > Can you clarify what the new limits mean in term of (security) support? Are we > now claiming that Xen will work perfectly fine on platforms with up to 16383? > > If so, I can't comment for x86, but for Arm, I am doubtful that it would work > without any (at least performance) issues. AFAIK, this is also an untested > configuration. In fact I would be surprised if Xen on Arm was tested with more > than a couple of hundreds cores (AFAICT the Ampere CPUs has 192 CPUs). I think we should add a security support limit for the number of physical cpus similar to the memory support limit we already have in place. For x86 I'd suggest 4096 cpus for security support (basically the limit we have with this patch), but I'm open for other suggestions, too. I have no idea about any sensible limits for Arm32/Arm64. Juergen
Hi Juergen, On 29/04/2024 12:28, Jürgen Groß wrote: > On 29.04.24 13:04, Julien Grall wrote: >> Hi Juergen, >> >> Sorry for the late reply. >> >> On 29/04/2024 11:33, Juergen Gross wrote: >>> On 08.04.24 09:10, Jan Beulich wrote: >>>> On 27.03.2024 16:22, Juergen Gross wrote: >>>>> With lock handling now allowing up to 16384 cpus (spinlocks can handle >>>>> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit >>>>> for >>>>> the number of cpus to be configured to 16383. >>>>> >>>>> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and >>>>> QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS. >>>>> >>>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>>> >>>> Acked-by: Jan Beulich <jbeulich@suse.com> >>>> >>>> I'd prefer this to also gain an Arm ack, though. >>> >>> Any comment from Arm side? >> >> Can you clarify what the new limits mean in term of (security) >> support? Are we now claiming that Xen will work perfectly fine on >> platforms with up to 16383? >> >> If so, I can't comment for x86, but for Arm, I am doubtful that it >> would work without any (at least performance) issues. AFAIK, this is >> also an untested configuration. In fact I would be surprised if Xen on >> Arm was tested with more than a couple of hundreds cores (AFAICT the >> Ampere CPUs has 192 CPUs). > > I think we should add a security support limit for the number of physical > cpus similar to the memory support limit we already have in place. > > For x86 I'd suggest 4096 cpus for security support (basically the limit we > have with this patch), but I'm open for other suggestions, too. > > I have no idea about any sensible limits for Arm32/Arm64. I am not entirely. Bertrand, Michal, Stefano, should we use 192 (the number of CPUs from Ampere)? Cheers,
diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig index 67ba38f32f..308ce129a8 100644 --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -6,7 +6,7 @@ config PHYS_ADDR_T_32 config NR_CPUS int "Maximum number of CPUs" - range 1 4095 + range 1 16383 default "256" if X86 default "8" if ARM && RCAR3 default "4" if ARM && QEMU
With lock handling now allowing up to 16384 cpus (spinlocks can handle 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for the number of cpus to be configured to 16383. The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and QINVAL_MAX_ENTRY_NR required to be larger than 2 * CONFIG_NR_CPUS. Signed-off-by: Juergen Gross <jgross@suse.com> --- V5: - new patch (Jan Beulich) --- xen/arch/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)