On 16/10/2025 8:32 am, Jan Beulich wrote:
> Using dynamically allocated / maintained vectors has several downsides:
> - possible nesting of IRQs due to the effects of IRQ migration,
> - reduction of vectors available for devices,
> - IRQs not moving as intended if there's shortage of vectors,
> - higher runtime overhead.
>
> As the vector also doesn't need to be of any priority (first and foremost
> it really shouldn't be of higher or same priority as the timer IRQ, as
> that raises TIMER_SOFTIRQ anyway), avoid any "ordinary" vectors altogther
> and use a vector from the 0x10...0x1f exception vector space. Exception vs
> interrupt can easily be distinguished by checking for the presence of an
> error code.
>
> Fixes: 996576b965cc ("xen: allow up to 16383 cpus")
> Signed-off-by: Jan Beulich <[email protected]>This is so cunning that it took me a while to figure out how this even functioned, given no apparent change to TPR. Having this behaviour under FRED is easy. In fact, allowing the use of vectors 0x10-0x1f under FRED is one "extra" I haven't gotten around to doing yet. But, the problem it introduces under IDT is that for all the other reserved exceptions, we'll panic if we see them. That was the point of setting TPR to 0x10 originally. ~Andrew
