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.
>