Re: [PATCH] x86/irq: Return -EEXIST from map_domain_pirq()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.05.2026 02:15, Jason Andryuk wrote:
> commit bfc341a65cfb ("x86: Make the hypercall PHYSDEVOP_alloc_irq_vector
> hypercall dummy.") modified map_domain_pirq() to return 0 when an irq or
> pirq is already mapped, when it previously returned -EINVAL.  This
> occured when moving map_domain_pirq()'s call from
> PHYSDEVOP_alloc_irq_vector into PHYSDEVOP_apic_write.
> 
> However, this means other callers cannot detect when a pirq or irq is
> already mapped.  Since success is returned but the pirq is not
> connected, it will never fire.
> 
> Modify map_domain_pirq() to return -EEXIST.  -EINVAL is already returned
> elsewhere in map_domain_pirq(), so -EEXIST allows identifying this case.
> With that, squash -EEXIST in ioapic_guest_write() so the behavior does not
> change.

What about the function's uses from allocate_and_map_[gm]si_pirq()? Don't they
then also need to cope with getting back -EEXIST to keep externally visible
behavior unaltered? Else those cases want discussing in the description, I
suppose.

> Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> ---
> I'm not sure whether or not this warrants a Fixes.  Nothing in tree
> today is broken, so I did not add one.

In which case this then also isn't 4.22 material, I guess?

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2315,6 +2315,8 @@ int ioapic_guest_write(unsigned long physbase, unsigned 
> int reg, u32 val)
>          ret = map_domain_pirq(hardware_domain, pirq, irq,
>                                MAP_PIRQ_TYPE_GSI, NULL);
>          write_unlock(&hardware_domain->event_lock);
> +        if ( ret == -EEXIST )
> +            ret = 0;
>          if ( ret < 0 )
>              return ret;

Slightly shorter

        if ( ret < 0 && ret != -EEXIST )
            return ret;

?

Jan