On 07/08/2023 2:17 pm, Jan Beulich wrote: > On 07.08.2023 14:55, Simon Gaiser wrote: >> Jan Beulich: >>> On 07.08.2023 11:38, Simon Gaiser wrote: >>>> It seems some firmwares put dummy entries in the ACPI MADT table for non >>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID >>>> 0xff. Linux already has code to handle those cases both in >>>> acpi_parse_lapic [1] as well as in acpi_parse_x2apic [2]. So add the >>>> same check to Xen. >>> I'm afraid it doesn't become clear to me what problem you're trying to >>> solve. >> I want Xen to not think there are possible CPUs that actually never can >> be there. > Did you try using "maxcpus=" on the command line? If that doesn't work > well enough (perhaps because of causing undesirable log messages), maybe > we need some way to say "no CPU hotplug" on the command line.
The ACPI tables are broken, and Xen's parsing of them is wrong. And irrespective - it's unreasonable to have users work around bugs in Xen by adding more command line. > >> Without ignoring those dummy entries Xen thinks my NUC has 2 sockets and >> that there are 8 logical CPUs that are currently disabled but could be >> hotplugged. > Yet it's exactly this which ACPI is telling us here (with some vagueness, > which isn't easy to get around; see below). > >> I'm moderately sure that soldering in another CPU is not supported, even >> less so at runtime ;] > On your system. What about others, which are hotplug-capable? It is required that all APIC ID are stated *ahead of time*. Entries with 0xFF and 0xFFFFFFFF at boot are entirely invalid. Furthermore, given debugging that I just did with Thomas, it's very clear that noone has tried really hotplugging CPUs under Xen. The layering violation is rather hilarious to watch. ~Andrew
