Re: [PATCH] x86/MSI: adjust permitted vector range

[Jan Beulich <jbeulich@xxxxxxxx>]

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@xxxxxxxx>
>> ---
>> 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