On 02.02.2026 16:54, Roger Pau Monné wrote: > On Wed, Nov 12, 2025 at 04:45:05PM +0100, Jan Beulich wrote: >> It's really FIRST_IRQ_VECTOR vector which is meant here, i.e. effectively >> there is a form of open-coding in use right now. >> >> No change in practice, due to the present aliasing. >> >> Signed-off-by: Jan Beulich <[email protected]> >> --- >> While doing the HPET work I had to fiddle with this, even if in the end >> no vector below FIRST_DYNAMIC_VECTOR is being used there (for now at >> least). >> >> --- a/xen/arch/x86/msi.c >> +++ b/xen/arch/x86/msi.c >> @@ -158,7 +158,7 @@ void msi_compose_msg(unsigned vector, co >> { >> memset(msg, 0, sizeof(*msg)); >> >> - if ( vector < FIRST_DYNAMIC_VECTOR ) >> + if ( vector < FIRST_IRQ_VECTOR ) > > Should vector also be rejected if it's > LAST_IRQ_VECTOR?
That's a good question for which I don't have a good answer. I can't exclude that composing an MSI message (for purposes other than using in an MSI capability) might make sense with a vector above LAST_IRQ_VECTOR. Originally (as hinted at in the post-commit-message remark) this change was part of the HPET work, where it was an actual functional change as in an early version I needed to move FIRST_IRQ_VECTOR down (i.e. decouple it from FIRST_DYNAMIC_VECTOR). There the "composed" message was used to fill HPET_T<n>_ROUTE. Something similar might be wanted elsewhere, and it's not quite clear to me whether in such a situation LAST_IRQ_VECTOR would then also need moving (likely it would). Right here I'm really only after the semantic, but non-functional change. If we can settle on also enforcing an upper bound, I think that would then want to be another change on top. Jan
