-----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.
