On Fri, Sep 16, 2022 at 05:08:59PM +0200, Adam Szewczyk wrote:
> Sorry, I always forgot that default answer is "answer" to not "answer to
> all".
>
> My xl dmesg after calling those debug-keys is:
Trimming the trace:
> (XEN) MSI information:
> (XEN) MSI 125 vec=72 lowest edge assert log lowest dest=00000100
> mask=0/ /?
> (XEN) MSI 138 vec=62 lowest edge assert log lowest dest=00000001
> mask=0/ /?
> (XEN) MSI 139 vec=6a lowest edge assert log lowest dest=00000010
> mask=0/ /?
> (XEN) IRQ information:
> (XEN) IRQ: 125 vec:72 PCI-MSI status=030 aff:{8}/{0-11}
> in-flight=0 d94:151(-M-)
> (XEN) IRQ: 138 vec:62 PCI-MSI status=030 aff:{0}/{0-11}
> in-flight=0 d92:151(---)
> (XEN) IRQ: 139 vec:6a PCI-MSI status=010 aff:{4}/{0-11}
> in-flight=0 d92:150(---)
Was domain with ID 94 your OpenBSD box? There's another domain with
passthrough devices (ID 92).
If your OpenBSD domain is the one with ID 94 it seems like the
interrupt source is masked, so no interrupts will be injected to the
guest. That however might be just the response from the guest after
seeing that the interrupt source is not behaving correctly.
Are yuo using a debug hypervisor? If not it would be helpful to do so,
in order to maybe get more information on `xl dmesg`.
Can you also paste the QEMU log for the OpeNSD domain? Those logs are
in /var/log/xen/qemu-dm-<domain name>.log, on most distros, not sure
if QubesOS puts them at the same place.
Regards, Roger.
