-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Mar 20, 2020 at 01:05:02AM +0100, Vít Šesták wrote: > Hello, > > On March 20, 2020 12:33:31 AM GMT+01:00, "Marek Marczykowski-Górecki" > <marma...@invisiblethingslab.com> wrote: > >I didn't spot VT-d errors, but I'm not entirely sure if I've checked. > >If they are there, this is something definitely worth looking into and > >most likely an issue within iwlwifi driver (or the firmware). It could > >be also worth trying booting Fedora 31 Live directly, but add > >intel_iommu=on kernel option. If that would break it, it's a clear > >indication that the issue is somewhere between firmware and the driver. > > I have tried to add this option, but it remained to work. Does it mean that > the driver itself is OK and the issue is in Xen or stubdom?
Likely, but not surely. Some more ideas what could be wrong: 1. Some config space access is filtered and driver doesn't cope with it. 2. Some extended PCIe feature that driver/firmware assumes present is not implemented in PCI passthrough. 3. Bug in handling any of supported PCIe features. 4. And there is still a possibility for a bug in the driver/firmware. For the first hypothesis, I'd try enabling permissive option (AFAIR didn't helped in itself), but then enable verbose logging in pciback driver: echo 1 > /sys/module/xen_pciback/parameters/verbose_request before starting sys-net. You'll get quite a lot of logs this way, and for understanding them fully, PCI spec would be handy... But maybe there will be some less obscure clues, like messages about explicitly failing requests? For the second hypothesis, I'd take lspci -vv of the device from both sys-net and dom0 (preferably in exact the same time, during enabling the interface, but that's unrealistic). And compare. There will be definitely some differences (more features visible in dom0), but what would be valuable is: - comparing configuration of features visible in both places - correlating missing features with iwlwifi driver It may be also useful to increase iwlwifi log level (I see 'debug' module option, seems to be a bitmask). For the third hypothesis, enable iwlwifi debugging and hope for more details. Decoding that firmware error would also be useful, but unlikely without firmware documentation or source code. If everything above fails, I would thoroughly compare driver behavior on bare metal and in the VM. Start with the driver debug output and if still no clues, then log hardware interactions (may require modifying the driver) and compare them. Some of the above ideas are quite extreme, and tedious to execute... PS adding the list back. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl50F2QACgkQ24/THMrX 1ywLuAgAjd/zJfxu9cHAo4h7vEib+0LWOTx55/hv8cGP9CsKNcpIdY6SJfg2Smy1 nhzh7BwxTkwnzGjYsmLzN+NX8uaTOXiLLdoEhoaOGbLekdsfJnXKLyXdu2AEhFHj ejKYfWTRNLnqDWNViNNhFgx9vbOsasyiQWh0tMJm5cwUkXMz82DTjVqDXBBtgog1 86hMdLcSxRYVNw0q+KL3zmlagpbxDcmwnf0cV6NjyckQ1LWQ+pr/zx3FS74WatJP D7k7dJ1M6rEdEDJaZ+K+XiXkLzJUufuwwKMlN4VL4SFvwmD5aglZm2B0rdcBBF9a 7pGs+ORAnWH4T4gnpiPi5OcfZWjiAQ== =SAV0 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200320010747.GB18599%40mail-itl.