Re: [PATCH v2 3/5] x86/IDT: Generate bsp_idt[] at build time

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.03.2025 01:02, Andrew Cooper wrote:
> ... rather than dynamically at boot time.  Aside from less runtime overhead,
> this approach is less fragile than the preexisting autogen stubs mechanism.
> 
> We can manage this with some linker calculations.  See patch comments for full
> details.
> 
> For simplicity, we create a new set of entry stubs here, and clean up the old
> ones in the subsequent patch.  bsp_idt[] needs to move from .bss to .data.
> 
> No functional change yet; the boot path still (re)writes bsp_idt[] at this
> juncture.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> v2:
>  * Shuffle semicolon position
>  * Eclair magic comment for multi-include files
> 
> There's something differnet about LLD vs LD.  Without the ABSOLUTE() in
> gen-idt.lds.h, LD is fine but LLD puts out symbols in the form:
> 
>   x86_IDT_entry_0xff_ADDR1|0000000000002fb0|   t  |            NOTYPE|        
>         |     |.text
>   x86_IDT_entry_0xff_ADDR2|0000000000004020|   a  |            NOTYPE|        
>         |     |*ABS*
> 
> which causes a slew of errors making symbols for xen-syms:
> 
>   .xen-syms.0.S:20:8: error: out of range literal value
>    .long 0x15a0 - (((((((261 >> 8) * 0xffff000000000000) | (261 << 39))) + 
> ((1 << 39) / 2)) + (64 << 30)) + (1 << 30))
>          ^
> 
> owing to half the symbols being t rather than a.  Moreover, this is reliable
> for the full FreeBSD builds, but interminttent on randconfig.  I haven't
> figured out which other option is having an effect.
> 
> Forcing them all to absolute works in both toolchains.

Just to double-check: Making these symbols absolute does not collide with
the .reloc section generation that we do for xen.efi, does it? That is, the
absence of relocations for the IDT merely means that we must not use the
IDT or any of its entries prior to relocating Xen back to its linked
addresses. Or, if e.g. we fetched an entry's address from the IDT earlier
on, we'd need to be aware that it's the linked address we fetch, not the
one matching where we execute. If that's a correct understanding of mine
and also matches your intentions:
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan