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? Jan
