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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.05.19 at 11:04, <roger.pau@xxxxxxxxxx> wrote:
> 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>

Thanks.

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

Not in this patch, but I'd like to widen the use of valid_irq_vector()
subsequently, which would likely also include this case.

Jan


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