Re: NetBSD dom0 PVH: hardware interrupts stalls

[Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>]

On Fri, Nov 27, 2020 at 02:40:22PM +0100, Jan Beulich wrote:
> On 27.11.2020 14:31, Manuel Bouyer wrote:
> > On Fri, Nov 27, 2020 at 02:18:54PM +0100, Jan Beulich wrote:
> >> 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.
> > 
> > yes, I did keep the hvm_gsi_deassert() patch because I expected it
> > to make things easier, as it allows to interract with Xen without changing
> > interrupt states.
> 
> Right, but then we'd need to see the beginning of the trace,
> rather than it starting at (in this case) about 95,000. Yet ...
> 
> > I removed it, here's a new trace
> > 
> > http://www-soc.lip6.fr/~bouyer/xen-log12.txt
> 
> ... hmm, odd - no change at all:
> 
> 95572 hvm_gsi_assert irq 34 trig 1 assert count 1

But I can confirm that now, entering ^A^A^A gets interrupt going in again

-- 
Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
     NetBSD: 26 ans d'experience feront toujours la difference
--