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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/03/2025 2:09 pm, Jan Beulich wrote:
> 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?

I don't know for sure.  I'd be lying if I said I understood how that
really worked.

But, the boot of a real xen.efi in GitlabCI is happy with the series,
including the recovery selftests.

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

Today, the IDT is a block of zeroes until we get into __start_xen() and
construct it by hand.

Safe use of the exception handlers also relies on the percpu areas, so
use of the IDT isn't viably moving any earlier.

Even with FRED, I haven't moved it earlier, because there's no point. 
We're only a handful of instructions ahead of being in 32bit mode, where
it would be useless to us.

For EFI boot, we run on the system IDT and are expected to keep it
intact (probably until EBS), so I don't see any point using it earlier
there either.

> If that's a correct understanding of mine
> and also matches your intentions:
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.  I'm pretty confident we're not going to be inclined to use it
earlier than __start_xen().

~Andrew