Re: NetBSD dom0 PVH: hardware interrupts stalls

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.11.2020 14:13, Manuel Bouyer wrote:
> On Fri, Nov 27, 2020 at 12:29:35PM +0100, Jan Beulich wrote:
>> On 27.11.2020 11:59, Roger Pau Monné wrote:
>>> --- a/xen/arch/x86/hvm/irq.c
>>> +++ b/xen/arch/x86/hvm/irq.c
>>> @@ -187,6 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi)
>>>       * to know if the GSI is pending or not.
>>>       */
>>>      spin_lock(&d->arch.hvm.irq_lock);
>>> +    if ( gsi == TRACK_IRQ )
>>> +        debugtrace_printk("hvm_gsi_assert irq %u trig %u assert count 
>>> %u\n",
>>> +                          gsi, trig, hvm_irq->gsi_assert_count[gsi]);
>>
>> This produces
>>
>> 81961 hvm_gsi_assert irq 34 trig 1 assert count 1
>>
>> Since the logging occurs ahead of the call to assert_gsi(), it
>> means we don't signal anything to Dom0, because according to our
>> records there's still an IRQ in flight. Unfortunately we only
>> see the tail of the trace, so it's not possible to tell how / when
>> we got into this state.
>>
>> Manuel - is this the only patch you have in place? Or did you keep
>> any prior ones? Iirc there once was one where Roger also suppressed
>> some de-assert call.
> 
> Yes, I have some of the previous patches (otherwise Xen panics).
> Attached is the diffs I currently have 

I think you want to delete the hunk dropping the call to
hvm_gsi_deassert() from pt_irq_time_out(). Iirc it was that
addition which changed the behavior to just a single IRQ ever
making it into Dom0. And it ought to be only the change to
msix_write() which is needed to avoid the panic.

Jan