Re: NetBSD dom0 PVH: hardware interrupts stalls

[Manuel Bouyer <bouyer@antioche.eu.org>]

On Mon, Nov 23, 2020 at 10:57:13AM +0100, Roger Pau Monné wrote:
> > [...]
> > OK.
> > I finally found where the EOI occurs (it's within a macro so s simple grep
> > didn't show it).
> > 
> > When interrupts are not masked (e.g. via cli), the ioapic halder is called.
> > From here, 2 paths can happen:
> > a) the software interrupt priority level (called spl in BSD world) allows the
> >   driver's handler to run. In this case it's called, then the interrupt
> >   is unmasked at ioapic level, and EOI'd at lapic.
> > b) the software interrupt priority level doesn't allow this driver's handler to
> >   run. In this case, the interrupt is marked as pending in software,
> >   explicitely masked at the iopic level and EOI'd at lapic.
> >   Later, when the spl is lowered, the driver's interrupt handler is run,
> >   then the interrupt is unmasked at ioapic level, and EOI'd at lapic
> >   (this is the same path as a)). here we may EOI the lapic twice, and the
> >   second time when there's no hardware interrupt pending any more.
> > 
> > I suspect it's case b) which causes the problem with Xen.
> 
> Case b) should be handled fine AFAICT. If there's no interrupt pending
> in the lapic ISR the EOI is just a noop. Iff there's somehow another
> vector pending in ISR you might actually be EOIing the wrong vector,
> and thus this would be a bug in NetBSD. I certainly don't know much of
> NetBSD interrupt model in order to know whether this second EOI is just
> not necessary or whether it could cause issues.
> 
> Can you actually assert that disabling this second unneeded EOI does
> solve the problem?

I tried this, and it didn't change anything ...

I'm out of idea to try.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--