On 22.09.2026 10:31, Oleksii Kurochko wrote: > On 9/21/26 2:32 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> Introduce imsic_vsfile_attach() to initialize the AIA-related state needed >>> for a vCPU to have a working guest interrupt file. >>> >>> A guest (VS) interrupt file must be mapped to one of a pCPU's >>> hardware interrupt files (if they exist), so the pCPU a vCPU will actually >>> run on needs to be known first. arch_vcpu_create() is therefore not a >>> suitable place to call vcpu_aia_init(), since the pCPU assigned to a >>> vCPU can still change before it is first scheduled. To avoid >>> reassigning the VS interrupt file id and remapping it to a different >>> pCPU's hardware interrupt file, imsic_vsfile_attach() is called from a >>> later point in the scheduling path (e.g. continue_new_vcpu()). >> >> Hmm, why does first-time handling need to be this different from the >> handling of a vCPU moving across pCPU-s? The sole difference should be >> "no state to load" vs "load state that was saved on the old pCPU". > > Generally I think it could be the same but not all the steps done in > migration functions aren't needed for new vCPU (despite of the fact they > aren't harmful). For new vCPU it seems to me it is enough only to attach > h/w interrupt file to vCPU.
Sure, yet still imo you want to aim at re-using as much code as possible, especially when otherwise you introduce multiple very similar but not exactly identical variants of logic. Jan
