On 25/02/2025 2:33 pm, Jan Beulich wrote: > On 25.02.2025 13:54, Andrew Cooper wrote: >> On 25/02/2025 9:00 am, Jan Beulich wrote: >>> On 24.02.2025 17:05, Andrew Cooper wrote: >>>> Having variables named idt_table[] and idt_tables[] is not ideal. >>>> >>>> Use X86_IDT_VECTORS and remove IDT_ENTRIES. State the size of bsp_idt[] in >>>> idt.h so that load_system_tables() and cpu_smpboot_alloc() can use sizeof() >>>> rather than opencoding the calculation. >>>> >>>> Move the variable into a new traps-init.c, to make a start at splitting >>>> traps.c in half. >>> Hmm, I'd expect a file of that name to contain only __init code/data, and >>> hence for it to be possible to ... >>> >>>> --- a/xen/arch/x86/Makefile >>>> +++ b/xen/arch/x86/Makefile >>>> @@ -65,6 +65,7 @@ obj-y += spec_ctrl.o >>>> obj-y += srat.o >>>> obj-y += string.o >>>> obj-y += time.o >>>> +obj-y += traps-init.o >>> ... use >>> >>> obj-bin-y += traps-init.init.o >>> >>> here. >> AP bringup and S3 resume will have a rather hard time working if that >> were the case. >> >> Plenty of it does end up being __init, but not all. > Hmm, yes. Yet then, taking into consideration what you put in that file > right in this series (which there's nothing init-ish about, as the tables > are needed until we reboot / shut down / crash), what's the designated > pattern for what is to go where?
Configuring event handling turns out to be pretty disjoint from actual event handling, and traps.c is already too complicated. If you can suggest a better name than traps-init.c then I'm all ears, but I couldn't think of one. Other commits I've got in the next batch of cleanup are: x86/traps: Move subarch_percpu_traps_init() into traps-init.c x86/traps: Move load_system_tables() into traps-init.c x86/traps: Simplify early exception setup x86/traps: Fold init_idt_traps() and trap_init() into their single callers x86/traps: Introduce new init APIs x86/traps: Move percpu_traps_init() into traps-init.c x86/traps: Move cpu_init() out of trap_init() which gives some idea of what's changing, although this isn't complete yet. Even things like LER setup end up moving in here. Setting up FRED requires the cmdline, feature scan, and a determination of pv_shim, all of which precludes it from being used for early exception handling. Therefore, what I've ended up trying to arrange is: 1) early_exception_init() (start of day) 2) traps_init() (replaces the current trap_init()) 3) percpu_traps_init() where early_exception_init() is even more simple than what we have today, and traps_init() tailcalls percpu_traps_init() to remove some duplication we've got. ~Andrew
