On 19/04/2023 2:50 pm, Andrew Cooper wrote: > On 19/04/2023 2:43 pm, Thomas Gleixner wrote: >> On Wed, Apr 19 2023 at 14:38, Thomas Gleixner wrote: >>> On Wed, Apr 19 2023 at 11:38, Thomas Gleixner wrote: >>> IOW, the BIOS assignes random numbers to the AP APICs for whatever >>> raisins, which leaves the parallel startup low level code up a creek >>> without a paddle, except for actually reading the APICID back from the >>> APIC. *SHUDDER* >> So Andrew just pointed out on IRC that this might be related to the >> ancient issue of the 3-wire APIC bus where IO/APIC and APIC shared the >> ID space, but that system is definitely post 3-wire APIC :) > Doesn't mean the BIOS code was updated adequately following that. > > What I'm confused by is why this system boots in the first place. I can > only think that's is a system which only has 4-bit APIC IDs, and happens > to function when bit 4 gets truncated off the top of the SIPI destination... https://www.amd.com/system/files/TechDocs/42300_15h_Mod_10h-1Fh_BKDG.pdf This system does still require the IO-APICs to be at 0, and the LAPICs to start at some offset, which is clearly 16 in this case. Also, this system has configurable 4-bit or 8-bit wide APIC IDs, and I can't tell which mode is active just from the manual. But, it does mean that the BIOS has genuinely modified the APIC IDs of the logic processors. This does highlight an error in reasoning with the parallel bringup code. For xAPIC, the APIC_ID register is writeable (at least, model specifically), and CPUID is only the value it would have had at reset. So the AP bringup logic can't actually use CPUID reliably. This was changed in x2APIC, which made the x2APIC_ID immutable. I don't see an option other than the AP bringup code query for xAPIC vs x2APIC mode, and either looking at the real APIC_ID register, or falling back to CPUID. ~Andrew
