On Mon, Feb 02, 2026 at 05:12:40PM +0100, Jan Beulich wrote: > 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).
It's possible that we could add a range between FIRST_IRQ_VECTOR and FIRST_DYNAMIC_VECTOR that could be used for fixed low priority vectors. > 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. Acked-by: Roger Pau Monné <[email protected]> Thanks, Roger.
