Re: [Xen-devel] [PATCH v2 01/12] x86/IRQ: deal with move-in-progress state in fixup_irqs()

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, May 08, 2019 at 07:03:09AM -0600, Jan Beulich wrote:
> The flag being set may prevent affinity changes, as these often imply
> assignment of a new vector. When there's no possible destination left
> for the IRQ, the clearing of the flag needs to happen right from
> fixup_irqs().
> 
> Additionally _assign_irq_vector() needs to avoid setting the flag when
> there's no online CPU left in what gets put into ->arch.old_cpu_mask.
> The old vector can be released right away in this case.
> 
> Also extend the log message about broken affinity to include the new
> affinity as well, allowing to notice issues with affinity changes not
> actually having taken place. Swap the if/else-if order there at the
> same time to reduce the amount of conditions checked.
> 
> At the same time replace two open coded instances of the new helper
> function.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks,

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

One comment below.

> ---
> v2: Add/use valid_irq_vector().
> v1b: Also update vector_irq[] in the code added to fixup_irqs().
> 
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -99,6 +99,11 @@ void unlock_vector_lock(void)
>      spin_unlock(&vector_lock);
>  }
>  
> +static inline bool valid_irq_vector(unsigned int vector)
> +{
> +    return vector >= FIRST_DYNAMIC_VECTOR && vector <= 
> LAST_HIPRIORITY_VECTOR;
> +}
> +
>  static void trace_irq_mask(u32 event, int irq, int vector, cpumask_t *mask)
>  {
>      struct {
> @@ -242,6 +247,22 @@ void destroy_irq(unsigned int irq)
>      xfree(action);
>  }
>  
> +static void release_old_vec(struct irq_desc *desc)
> +{
> +    unsigned int vector = desc->arch.old_vector;
> +
> +    desc->arch.old_vector = IRQ_VECTOR_UNASSIGNED;
> +    cpumask_clear(desc->arch.old_cpu_mask);
> +
> +    if ( !valid_irq_vector(vector) )
> +        ASSERT_UNREACHABLE();
> +    else if ( desc->arch.used_vectors )
> +    {
> +        ASSERT(test_bit(vector, desc->arch.used_vectors));
> +        clear_bit(vector, desc->arch.used_vectors);
> +    }
> +}
> +
>  static void __clear_irq_vector(int irq)
>  {
>      int cpu, vector, old_vector;
> @@ -285,14 +306,7 @@ static void __clear_irq_vector(int irq)
>          per_cpu(vector_irq, cpu)[old_vector] = ~irq;
>      }
>  
> -    desc->arch.old_vector = IRQ_VECTOR_UNASSIGNED;
> -    cpumask_clear(desc->arch.old_cpu_mask);
> -
> -    if ( desc->arch.used_vectors )
> -    {
> -        ASSERT(test_bit(old_vector, desc->arch.used_vectors));
> -        clear_bit(old_vector, desc->arch.used_vectors);
> -    }
> +    release_old_vec(desc);
>  
>      desc->arch.move_in_progress = 0;
>  }
> @@ -517,12 +531,21 @@ next:
>          /* Found one! */
>          current_vector = vector;
>          current_offset = offset;
> -        if (old_vector > 0) {
> -            desc->arch.move_in_progress = 1;
> -            cpumask_copy(desc->arch.old_cpu_mask, desc->arch.cpu_mask);
> +
> +        if ( old_vector > 0 )

Maybe you could use valid_irq_vector here, or compare against
IRQ_VECTOR_UNASSIGNED?

The fact that IRQ_VECTOR_UNASSIGNED is a negative value is an
implementation detail that shouldn't be exposed directly in the code
IMO.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel