Not sure of which commit this corresponds from a coreboot perspective, would have to dig libreboot to find out if necessary…
A quick search didn’t provide direct bug report neither from coreboot nor libreboot for usb controller.
Logs from appvms (console logs, which includes dmesg report from qubes) are present, and rotated, under dom0’s /var/log/xen/console directory (from memory here).
You might want to provide clear logs from there, bringing them to qubes through qvm-copy-to-vm calls for working/non-working scenarios.
Insight is that coreboot is not initializing usb controllers properly/iommu is not setuped properly in firmware.
2016 firmware might be before cbmem was integrated into coreboot so that coreboot logs are reported to OS (to be figured out if debugging coreboot is needed).
The best place to discuss that might be on libreboot mailing list. From recent merge of osboot into libreboot, I expect more people to have interest into libreboot for their Qubes supported boards.
Some kind of behavior isolation might be needed here to make sure of the nature of the problem. We are actually talking about a pci passthrough of a usb controller into a HVM (sys-usb) so we are talking about iommu reliable support from firmware, ACPI enumaration from firmware and then Xen passthrough to sys-usb under qubes use case.
A good first step would be to confirm that booting for example Tails LiveCD results in the same 50% usb contoller discovery/usage rate? If its 100% success, then going into digging IOMMU issues and CPU version/ microcode applied versions and then digging into IOMMU issues might be helpful to resolve the issue. Goal here is to isolate causes.
Next steps:
- expose failing/success logs from dom0 for sys-usb attempting to get that usb controller passethrough
- confirmation that a normal (non-xen, no passthrough) is able to deal with usb controller 100%of the time.
And then go from there?