On 08/12/2021 11:47, Jan Beulich wrote:
> With "nosmp" I did observe a flood of "APIC error on CPU0: 04(04), Send
> accept error" log messages on an AMD system. And rightly so - nothing
> excludes the use of the shorthand in send_IPI_mask() in this case. Set
> "unaccounted_cpus" to "true" also when command line restrictions are the
> cause.
>
> Note that PV-shim mode is unaffected by this change, first and foremost
> because "nosmp" and "maxcpus=" are ignored in this case.
>
> Fixes: 5500d265a2a8 ("x86/smp: use APIC ALLBUT destination shorthand when
> possible")
> Signed-off-by: Jan Beulich <[email protected]>
Acked-by: Andrew Cooper <[email protected]>
> ---
> While in "nosmp" mode it's probably benign that we switch to the bigsmp
> APIC driver simply because there are more than 8 physical CPUs, I
> suppose that's inefficient when "maxcpus=" with a value between 2 and 8
> (inclusive) is in use. Question is whether that's worthwhile to find a
> solution for.
Honestly, the concept of "nosmp" needs deleting. We inherited it from
Linux and it wasn't terribly appropriate even back then.
Nowadays, even if we happen to boot with 1 cpu, there are normal things
we talk to (the IOMMUs most obviously) which are smp-like.
None of these command line restricted settings can be used in
production, because neither Intel nor AMD support, and both require us
to boot all logical processors. Everything playing in this area is a
maintenance burden only.
~Andrew
