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

Rin Okuyama <[email protected]> Sun, 29 Sep 2024 00:35:32 +0900
Newsgroups gmane.os.netbsd.ports.x86-64
Message-ID <[email protected]>
Hi,

This thread?

https://mail-index.netbsd.org/port-amd64/2023/12/30/msg003666.html

Thanks,
rin

On 2024/09/29 0:25, Manuel Bouyer wrote:
> On Thu, Sep 26, 2024 at 05:48:30PM +0200, Manuel Bouyer wrote:
>>> [...]
>>
>> I made some progress.  Actually it's in aesni_probe, and more specifically
>> when it calls fpu_area_restore() from fpu_kern_enter().
>> cr4 is 0x678 and xsave_feature is 0x2e7 at fpu_area_restore() entry
>> so CR4_OSFXSR is there.
>> I tried disabling FPU_SAVE_XSAVEOPT, keeping only FPU_SAVE_XSAVE but this
>> didn't help. Disabling XSAVE completely avoids the illegal instruction
>> (which means that fxrstor is working) but a NULL function pointer
>> cause a panic at a later point.
>>
>> I suspect that, for this CPU some more bits needs to be enabled in one of the
>> config registers, or our fxsavel is called with inappropriate arguments
>> (x86_xsave_feature would have a wrong value). I'm not familiar with x86 FPU
>> so some help is welcome
> 
> It turns out that no CPUs are detected, so cpu_init() is not called and the
> FPU is not initialised.
> CPUs are skipped because of this in mpacpi_config_cpu():
>                 /* ACPI spec: "Logical processors with APIC ID values
>                  * less than 255 must use the Processor Local APIC
>                  * structure to convey their APIC information to OSPM."
>                  * But Xen with PVH dom0 breaks this ACPI spec.
>                  */
>                 if (x2apic->LocalApicId <= 0xff && vm_guest != VM_GUEST_XENPVH) {
>                         printf("bogus MADT X2APIC entry (id = 0x%"PRIx32")\n",
>                             x2apic->LocalApicId);
>                         break;
>                 }
> 
> Removing this (see attached patch) makes the kernel boot up to starting init.
> 
> I think I've seen a discussion about this not long ago but I couldn't
> find it in the archives. Is this check still relevant ?
> Should I commit the attached patch ?
> It may help for kern/57737 too.
>