On 18/03/2025 3:26 pm, Jan Beulich wrote: > On 17.03.2025 20:20, Andrew Cooper wrote: >> Something I overlooked when last cleaning up exception handling is that a TSS >> is not necessary if IST isn't configured, and IST isn't necessary until we're >> running guest code. >> >> Introduce early_traps_init() which is far more minimal than init_idt_traps(); >> bsp_ist[] is constructed without IST settings, so all early_traps_init() >> needs >> to do is load the IDT, and invalidate TR/LDTR. >> >> Put the remaining logic into traps_init(), later on boot. Note that >> load_system_tables() already contains enable_each_ist(), so the call is >> simply >> dropped. >> >> This removes some complexity prior to having exception support, and lays the >> groundwork to not even allocate a TSS when using FRED. >> >> No practical change. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Given the present state of thing: > Reviewed-by: Jan Beulich <jbeul...@suse.com>
Thanks. > What worries me slightly is that ... > >> @@ -63,6 +88,13 @@ void __init traps_init(void) >> /* Replace early pagefault with real pagefault handler. */ >> _update_gate_addr_lower(&bsp_idt[X86_EXC_PF], entry_PF); >> >> + this_cpu(idt) = bsp_idt; >> + this_cpu(gdt) = boot_gdt; >> + if ( IS_ENABLED(CONFIG_PV32) ) >> + this_cpu(compat_gdt) = boot_compat_gdt; > ... this being done later now requires more care with e.g. play_dead(). Hmm. There are multiple things at play here. load_system_tables() is the important one to defer, and when FRED is active there really is no IDT. However, when we're using IDT for early handing, we probably ought to have the pointer set up. So I think this block wants to move back early. It's also used in NMI crash shootdown too. > Yet if and when needed, this setting up could of course be moved earlier > again. It's not entirely clear to me why you specifically want it here > and not in early_traps_init(). Because I was looking to not even set up an IDT when FRED is in use. But as said, we probably want to set it up, and then invalidate it when turning on FRED. > 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. 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. ~Andrew
