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 <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.
I am not entirely. Bertrand, Michal, Stefano, should we use 192 (the
number of CPUs from Ampere)?
Cheers,
--
Julien Grall