[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/4] x86/IRQ: bail early from irq_guest_eoi_timer_fn() when nothing is in flight



>>> On 05.06.19 at 19:15, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 08/05/2019 13:46, Jan Beulich wrote:
>> @@ -1130,8 +1130,10 @@ static void irq_guest_eoi_timer_fn(void
>>          }
>>      }
>>  
>> -    if ( action->in_flight != 0 )
>> -        goto out;
>> +    if ( action->in_flight )
>> +        printk(XENLOG_G_WARNING
>> +               "IRQ%d: %d handlers still in flight at forced EOI\n",
>> +               desc->irq, action->in_flight);
> 
> AFACIT, this condition can be triggered by a buggy/malicious guest, by
> it simply ignoring or masking the line interrupt at the vIO-APIC.

I don't think it can, no. Or else the ASSERT_UNREACHABLE() below
here would be invalid to add.

> The message would be far more useful if it identified the domain in
> question, which looks like it can be obtained from the middle of the loop.

That very loop has just taken care of decrementing ->in_flight for
all such guests.

Also note that there could be more than one offending domain, for
shared IRQs. Plus the loop you're referring to can specifically _not_
be used for identifying the domain(s), because for the ones
processed there we _did_ decrement ->in_flight. If this message
gets logged, we simply have no idea why ->in_flight is _still_ non-
zero. This could be a BUG_ON(), but it seems more in line with our
general idea of how we would like to deal with such cases to try
and keep the system running here in release builds.

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.