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

~Andrew