port-amd64/53694: I/O APIC IDs mismatch

[mlelstv%netbsd.org@localhost]

>Number:         53694
>Category:       port-amd64
>Synopsis:       I/O APIC IDs mismatch
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 01 14:55:00 +0000 2018
>Originator:     mlelstv%netbsd.org@localhost
>Release:        NetBSD 8.99.25
>Organization:
	
>Environment:
	
	
System: NetBSD slowpoke 8.99.25 NetBSD 8.99.25 (SLOWPOKE) #52: Thu Nov 1 14:02:55 CET 2018 mlelstv@gossam:/home/netbsd-current/obj.amd64/home/netbsd-current/src/sys/arch/amd64/compile/SLOWPOKE amd64
Architecture: x86_64
Machine: amd64
>Description:

The system boots with:

ioapic0 at mainbus0 apid 128: pa 0xfec00000, version 0x21, 24 pins
[     1.000003] ioapic0: autoconfiguration error: can't remap to apid 128
[     1.000003] ioapic1 at mainbus0 apid 129: pa 0xefc00000, version 0x21, 32 pins
[     1.000003] ioapic1: autoconfiguration error: can't remap to apid 129
[     1.000003] ioapic2 at mainbus0 apid 130: pa 0xb7a00000, version 0x21, 32 pins
[     1.000003] ioapic2: autoconfiguration error: can't remap to apid 130


The APIC IDs 128,129,130 come from ACPI. The code in sys/arch/x86/x86/mpacpi.c
however treats IDs as 4bit numbers in the APIC ID register. When comparing
the 4bit number with the value from ACPI the check fails, the code tries to
correct the "wrong" value but writes back the full 8bit value into the
assumed 4bit field, trashing 4 more bits that are assumed to be reserved.

The Intel documentation reveals that in xapic mode (that's what is mostly
used), older chips like P6 and Pentium use a 4bit APIC ID field while
newer chips like Pentium 4 or Xeon use an 8bit field. Newer chips also
know a x2apic mode where the whole 32bit APIC ID register is used.

Neither Linux nor FreeBSD care about the old chips in xapic mode but always
use an 8bit APIC ID. Linux also supports the x2apic mode.

As APIC IDs > 15 are probably only existent in ACPI tables for newer chips
it is accidentally correct that the 8bit value is written. Correcting the
bug by masking the value might have unwanted side effects.

>How-To-Repeat:
Run a system that uses 8-bit IDs for the APICs.

>Fix:
It's probably sufficient to follow Linux or FreeBSD and always use an
8bit field.

>Unformatted: