Re: [PATCH 4/4] x86/traps: Introduce early_traps_init() and simplify setup

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/03/2025 6:52 am, Jan Beulich wrote:
> On 20.03.2025 18:56, Andrew Cooper wrote:
>> On 18/03/2025 3:26 pm, Jan Beulich wrote:
>>> The sole dependency is percpu_init_areas(),
>>> which runs - as even visible from patch context here - ahead of
>>> early_traps_init().
>> percpu_init_areas() isn't even a dependency.  Notice how it only starts
>> from CPU1.  CPU0 (which is what this_cpu() refers to in both of these
>> functions) is correct (i.e. 0) at build time.
> Oh, right.
>
>> I still intend to remove percpu_init_areas().  It's all build-time
>> constant; it just needs doing by the assembler, rather than the
>> compiler, as (-(long)__per_cpu_start) is not an integer constant expression.
> Except that this value also cannot be expressed by a relocation, afaict,
> so the assembler would choke when trying to write the object file. (Same
> for x86'es alternative initializer.)

Yeah, I found that while experimenting.

However, the PROVIDE_HIDDEN() trick I used for IDT autogen does work.

There are a couple of nasty thing.  While we have ASM_INT() now, we
don't have ASM_PTR() or equivalent, which is needed because this is a
common file and we can't just use .quad.

Also, because this is an asm() block in a C file, we can't use any of
linkage.h; opencoding it isn't too bad, but it also appears that
__read_mostly doesn't honour -fdata-sections.

~Andrew