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.