Re: bogus MADT X2APIC entry [Re: illegal instruction in kernel at boot]

Manuel Bouyer <[email protected]> Mon, 30 Sep 2024 19:03:23 +0200
Newsgroups gmane.os.netbsd.ports.x86-64
Message-ID <[email protected]>
On Mon, Sep 30, 2024 at 12:09:47PM +0900, Rin Okuyama wrote:
> On 2024/09/29 1:23, Manuel Bouyer wrote:
> > On Sun, Sep 29, 2024 at 12:35:32AM +0900, Rin Okuyama wrote:
> > > Hi,
> > > 
> > > This thread?
> > > 
> > > https://mail-index.netbsd.org/port-amd64/2023/12/30/msg003666.html
> > 
> > Yes that's it. I didn't look back enough.
> > 
> > The complete sentence from the latest ACPI spec is:
> > "On some legacy OSes, Logical processors with APIC ID values less than 255 (whether in XAPIC or X2APIC mode) must use the Processor Local APIC structure to convey their APIC information to OSPM, and those processors must be declared in the DSDT using the Processor() keyword. Logical processors with APIC ID values 255 and greater must use the Processor Local x2APIC structure and be declared using the Device() keyword."
> > 
> > To me this doens't means that the OS has to reject X2APICs with ID < 255.
> > It also doesn't prevent an APCI implementation from using X2APICs with low
> > IDs if it doens't care about legacy OSes.
> > 
> > I am reading it wrong ?
> > 
> 
> Probably no. Other OSes do not seem to check this also.
> 
> I've briefly discussed with msaitoh@. Our Sapphire Rapids
> box does not boot even with this check is removed. However,
> unfortunately, we cannot examine further at the very moment.
> 
> Please go ahead :)

Commited. Will request pullup to netbsd-10, but maybe after 10.1 ?
I don't know if this could cause issues if a system has APICs registered in
both in local apic and x2apic structures 

-- 
Manuel Bouyer <[email protected]>
     NetBSD: 26 ans d'experience feront toujours la difference
--