Claudia: TLDR; check bottom of https://community.amd.com/thread/241650, looks like there was a recently released related updated. Not sure if applicable to your situation.
> This caused a very sneaky problem on my machine. My USB controllers are in > the same group as my > GPU, sound card, and SATA controller. So when sys-usb (or > rd.qubes.hide_all_usb) takes over those > two USB controllers, everything stops working. [4] It was quite difficult to > trace. It would have > been much easier to diagnose if grouping was enforced somewhere. I would much > rather have an error > in my logs about being unable to assign USB controllers, than have my whole > screen freeze up with > no indication why. (I got lucky that it just crashed; if something interferes > with your SATA > controller's address space it can cause disk corruption. [5]) > > I don't really know who's at fault here. Qubes? Xen? AMD? Dell? The improper grouping is probably somewhere in AGESA, which is provided to the manufacturers by AMD. It could be because of hardware related limitations, which again are supplied by AMD. Sometimes vendors take liberties (cost cutting measures) with both and break functionality, as their primary/sole concern is that Windows boots. This can especially be the case with consumer class machines such as Ryzen. Agree it would be nice if Xen handled this failure mode more gracefully. Not sure there is much Qubes can do here, though. On the other hand, my older AMD (pre-Ryzen) consumer laptop running Coreboot has correct groupings. > Intel systems > seem to just to have better grouping usually (or, are less likely to crash > when grouping rules are > violated). [6] I think that is overbroad. There are plenty of Intel systems with broken passthrough. iommu=no-igfx itself is a workaround for broken passthrough of Intel graphics. There are also plenty of AMD systems with properly implemented passthrough. > Thoughts? Is there anything Qubes can do to do avoid splitting up IOMMU > groups? Is there anything > Qubes *should* do? Should Qubes attempt to guess the IOMMU groups before > taking over devices? > Should the USB Qube option be disabled on AMD systems (you can still manually > set up sys-usb of > course)? Should we just blame Xen for not enforcing IOMMU groups in the first > place? Ultimately, it's a hardware/firmware issue. Threadripper and Epyc based AMD systems ought to be more thoroughly vetted to support passthrough. My suggestions are to disable automatic IOMMU grouping in your UEFI configuration, if possible. Otherwise, try a newer firmware version with updated AGESA code and see if it helps, or possibly add a card with additional USB controllers as that should appear in its own group. -- 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/336a9dc9-8409-3496-f0e2-9d24c06d47ab%40danwin1210.me.
