Hi, John,
Thanks for catching this issue.
On Wed, 2023-11-22 at 22:19 +0000, John Sperbeck wrote:
> I have a platform with both LOCAL_APIC and LOCAL_X2APIC entries for
> each CPU. However, the ids for the LOCAL_APIC entries are all
> invalid ids of 255, so they have always been skipped in
> acpi_parse_lapic()
> by this code from f3bf1dbe64b6 ("x86/acpi: Prevent LAPIC id 0xff from
> being
> accounted"):
>
> /* Ignore invalid ID */
> if (processor->id == 0xff)
> return 0;
>
> With the change in this thread, the return value of 0 means that the
> 'count' variable in acpi_parse_entries_array() is incremented. The
> positive return value means that 'has_lapic_cpus' is set, even though
> no entries were actually matched.
So in acpi_parse_madt_lapic_entries, without this patch,
madt_proc[0].count is a positive value on this platform, right?
This sounds like a potential issue because the following checks to fall
back to MPS mode can also break. (If all LOCAL_APIC entries have
apic_id 0xff and all LOCAL_X2APIC entries have apic_id 0xffffffff)
> Then, when the MADT is iterated
> with acpi_parse_x2apic(), the x2apic entries with ids less than 255
> are skipped and most of my CPUs aren't recognized.
>
> I think the original version of this change was okay for this case in
> https://lore.kernel.org/lkml/87pm4bp54z.ffs@tglx/T/
Yeah.
But if we want to fix the potential issue above, we need to do
something more.
Say we can still use acpi_table_parse_entries_array() and convert
acpi_parse_lapic()/acpi_parse_x2apic() to
acpi_subtable_proc.handler_arg and save the real valid entries via the
parameter.
or can we just use num_processors & disabled_cpus to check if there is
any CPU probed when parsing LOCAL_APIC/LOCAL_X2APIC entires?
thanks,
rui
>
> P.S. I could be convinced that the MADT for my platform is somewhat
> ill-formed and that I'm relying on pre-existing behavior. I'm not
> well-versed enough in the topic to know for sure.
|