On 18.07.2023 15:19, Jan Beulich wrote: > On 29.06.2023 14:17, Alejandro Vallejo wrote: >> --- a/xen/arch/x86/boot/head.S >> +++ b/xen/arch/x86/boot/head.S >> @@ -123,6 +123,7 @@ multiboot2_header: >> .Lbad_ldr_nih: .asciz "ERR: EFI ImageHandle is not provided by bootloader!" >> .Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!" >> .Lbag_alg_msg: .asciz "ERR: Xen must be loaded at a 2Mb boundary!" >> +.Lno_nx_msg: .asciz "ERR: Not an NX-capable CPU!" >> >> .section .init.data, "aw", @progbits >> .align 4 >> @@ -153,6 +154,11 @@ early_error: /* Here to improve the disassembly. */ >> .Lnot_aligned: >> add $sym_offs(.Lbag_alg_msg), %esi >> jmp .Lget_vtb >> +#ifdef CONFIG_REQUIRE_NX >> +.Lno_nx: >> + add $sym_offs(.Lno_nx_msg), %esi >> + jmp .Lget_vtb >> +#endif > > Since I'm in the process of introducing more such paths (for the x86-64-v<N> > series), I'm curious: Have you actually had success with getting any output > from this code path? I see unreadable output come through serial (provided > it's the normal com1 I/O port location where the serial port is), which > likely is because baud rate wasn't configured yet, and hence I might have > success by changing the config of the receiving side. And I see nothing at > all on the screen. While kind of expected when in graphics mode, I wonder > whether this ever worked, or whether this has simply bitrotted because of > never actually coming into play.
Pretty clearly this was broken in the course of adding MB2 support, by b28044226e1c using %esi as the "relocation base" after already having clobbered it. I'm working on a fix. Jan
