Re: Linux HVM fails to start with PANIC: early exception 0x00 IP 0010:clear_page_orig+0x12/0x40 error 0

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/05/2024 3:48 pm, Andrew Cooper wrote:
> On 12/05/2024 3:16 am, Marek Marczykowski-Górecki wrote:
>> Hi,
>>
>> I've got a report[1] that after some update Linux HVM fails to start with the
>> error as in the subject. It looks to be caused by some change between
>> Xen 4.17.3 and 4.17.4. Here the failure is on Linux 6.6.25 (both dom0
>> and domU), but the 6.1.62 that worked with older Xen before, now fails
>> too. The full error (logged via earlyprintk=xen) is:
>>
>>     [    0.009500] Using GB pages for direct mapping
>>     PANIC: early exception 0x00 IP 10:ffffffffb01c32e2 error 0 cr2 
>> 0xffffa08649801000
>>     [    0.009606] CPU: 0 PID: 0 Comm: swapper Not tainted 
>> 6.6.25-1.qubes.fc37.x86_64 #1
>>     [    0.009665] Hardware name: Xen HVM domU, BIOS 4.17.4 04/26/2024
>>     [    0.009710] RIP: 0010:clear_page_orig+0x12/0x40
>>     [    0.009766] Code: 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 
>> 90 90 90 90 90 90 90 f3 0f 1e fa 31 c0 b9 40 00 00 00 0f 1f 44 00 00 ff c9 
>> <48> 89 07 48 89 47 08 48 89 47 10 48 89 47 18 48 89 47 20 48 89 47
>>     [    0.009862] RSP: 0000:ffffffffb0e03d58 EFLAGS: 00010016 ORIG_RAX: 
>> 0000000000000000
>>     [    0.009915] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 
>> 000000000000003f
>>     [    0.009967] RDX: 0000000000009801 RSI: 0000000000000000 RDI: 
>> ffffa08649801000
>>     [    0.010015] RBP: 0000000000000001 R08: 0000000000000001 R09: 
>> 6b7f283562d74b16
>>     [    0.010063] R10: 0000000000000000 R11: 0000000000000000 R12: 
>> 0000000000000001
>>     [    0.010112] R13: 0000000000000000 R14: ffffffffb0e22a08 R15: 
>> ffffa08640000000
>>     [    0.010161] FS:  0000000000000000(0000) GS:ffffffffb16ea000(0000) 
>> knlGS:0000000000000000
>>     [    0.010214] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>     [    0.010257] CR2: ffffa08649801000 CR3: 0000000008e80000 CR4: 
>> 00000000000000b0
>>     [    0.010310] Call Trace:
>>     [    0.010341]  <TASK>
>>     [    0.010372]  ? early_fixup_exception+0xf7/0x190
>>     [    0.010416]  ? early_idt_handler_common+0x2f/0x3a
>>     [    0.010460]  ? clear_page_orig+0x12/0x40
>>     [    0.010501]  ? alloc_low_pages+0xeb/0x150
>>     [    0.010541]  ? __kernel_physical_mapping_init+0x1d2/0x630
>>     [    0.010588]  ? init_memory_mapping+0x83/0x160
>>     [    0.010631]  ? init_mem_mapping+0x9a/0x460
>>     [    0.010669]  ? memblock_reserve+0x6d/0xf0
>>     [    0.010709]  ? setup_arch+0x796/0xf90
>>     [    0.010748]  ? start_kernel+0x63/0x420
>>     [    0.010787]  ? x86_64_start_reservations+0x18/0x30
>>     [    0.010828]  ? x86_64_start_kernel+0x96/0xa0
>>     [    0.010868]  ? secondary_startup_64_no_verify+0x18f/0x19b
>>     [    0.010918]  </TASK>
>>
>> I'm pretty sure the exception 0 is misleading here, I don't see how it
>> could be #DE.
>>
>> More logs (including full hypervisor log) are attached to the linked
>> issue.
>>
>> This is on HP 240 g7, and my educated guess is it's Intel Celeron N4020
>> CPU. I cannot reproduce the issue on different hardware.
>>
>> PVH domains seems to work.
>>
>> Any ideas what could have happened here?
> Yes.
>
> Revert the microcode back to revision 0x38 for now.

The regression is fixed in revision 0x42.

~Andrew