On 25.02.2025 17:20, Andrew Cooper wrote: > 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.
traps-setup.c maybe? Just to avoid the "init" in the name. Jan > 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
