Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/61776 )
Change subject: Revert "cpu/x86/lapic: Unconditionally use CPUID leaf 0xb if available" ......................................................................
Patch Set 2:
(1 comment)
Commit Message:
https://review.coreboot.org/c/coreboot/+/61776/comment/f843ed4c_7e8054a0 PS1, Line 16: valid APIC ID.
the cezanne ppr #56569 rev 3.03 has the following definition […]
My expectation had been that AMD implements the standard CPUID set in compliance with IA32 / X86_64 manual. Obviously this assumption is wrong. Bit 21 of ECX (not EAX) CPUID leaf 1 should work, while documented as reserved in #25481.
So the later #55570 rev 3.16 documents leaf 0xb as implemented, while the PCO hardware behaved like earlier rev 3.14? Are the top EDX 24 bits really reserved or zero?
Platforms supporting X2APIC probably should never use XAPIC_ONLY=y. With intel, bottom LAPIC ID bits may have a shift, so the 8 bits of CPUID leaf 0x1 EDX may be insufficient already with MAX_CPUS < 256.
Payloads may need to be modified for X2APIC mode.
From IA32/64 SDM 10.12.2 x2APIC Register Availability
In x2APIC mode, the memory mapped interface is not available and any access to the MMIO interface will behave similar to that of a legacy xAPIC in globally disabled state.
I have also seen kernel messages like this: Switched APIC routing to cluster x2apic.
So SMM may see LAPICs in x2apic mode even with coreboot proper built with XAPIC_ONLY.