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 <jbeulich@suse.com>
---
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 )
         return;
 
     if ( cpu_mask )

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 <jbeulich@suse.com>
> ---
> 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?

Thanks, Roger.

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 <jbeulich@suse.com>
>> ---
>> 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

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 <jbeulich@suse.com>
> >> ---
> >> 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é <roger.pau@citrix.com>

Thanks, Roger.