Re: NetBSD dom0 PVH: hardware interrupts stalls

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Nov 23, 2020 at 03:31:50PM +0100, Manuel Bouyer wrote:
> On Mon, Nov 23, 2020 at 01:51:12PM +0100, Roger Pau Monné wrote:
> > Hm, yes, it's quite weird. Do you know whether a NetBSD kernel can be
> > multibooted from pxelinux with Xen? I would like to see if I can
> > reproduce this myself.
> 
> Yes, if Xen+linux can boot, Xen+netbsd should boot too.
> In a previous mail I wrote:
> In case it helps, I put by Xen and netbsd kernels at
> http://www-soc.lip6.fr/~bouyer/netbsd-dom0-pvh/
> I boot it from the NetBSD boot loader with:
> menu=Boot Xen PVH:load /netbsd-test console=com0 root=dk0 -vx; multiboot 
> /xen-te
> st.gz dom0_mem=1024M console=com2 com2=57600,8n1 loglvl=all guest_loglvl=all 
> gnt
> tab_max_nr_frames=64 dom0=pvh iommu=debug
> I guess with grub this would be
> kernel /xen-test.gz dom0_mem=1024M console=com2 com2=57600,8n1 loglvl=all 
> guest_
> loglvl=all gnttab_max_nr_frames=64 dom0=pvh iommu=debug
> module /netbsd-test console=com0 root=dk0 -vx
> 
> (yes, com2 for xen and com0 for netbsd, that's not a bug :)
> You can enter the NetBSD debugger with
> +++++
> you can then enter commands, lile
> sh ev /i
> to see the interrupt counters
> 
> > 
> > I have the following patch also which will print a warning message
> > when GSI 34 is injected from hardware or when Xen performs an EOI
> > (either from a time out or when reacting to a guest one). I would
> > expect at least the interrupt injection one to trigger together with
> > the existing message.
> 
> It's quite verbose. I put the full log at
> http://www-soc.lip6.fr/~bouyer/xen-log4.txt

OK, I'm afraid this is likely too verbose and messes with the timings.

I've been looking (again) into the code, and I found something weird
that I think could be related to the issue you are seeing, but haven't
managed to try to boot the NetBSD kernel provided in order to assert
whether it solves the issue or not (or even whether I'm able to
repro it). Would you mind giving the patch below a try?

Thanks, Roger.
---8<---
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 6b1305a3e5..ebd6c8e933 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -174,7 +174,6 @@ static void pt_irq_time_out(void *data)
          * In the identity mapped case the EOI can also be done now, this way
          * the iteration over the list of domain pirqs is avoided.
          */
-        hvm_gsi_deassert(irq_map->dom, dpci_pirq(irq_map)->pirq);
         irq_map->flags |= HVM_IRQ_DPCI_EOI_LATCH;
         pt_irq_guest_eoi(irq_map->dom, irq_map, NULL);
         spin_unlock(&irq_map->dom->event_lock);