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 <jgr...@suse.com>
Acked-by: Jan Beulich <jbeul...@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
