As far as I know/understand: * At start, all the PCI devices are assigned to dom0. * When a qube with an attached PCI device starts, dom0 assigns the PCI device to the qube, so it is no longer attached to dom0. It never gets actually attached to dom0 automatically (until reboot). If it was, a malicious qube could for example flash a malicious firmware to a USB device and shut down in order to connect the malicious device to dom0. * In order to have some additional protection, rd.qubes.hide_all_usb hides all USB devices. That is, the USB PCI device is attached to dom0, but Linux ignores it, maybe it blacklists related kernel modules.
The behavior you have observed suggests that both detached USB controller and ignored USB controller cause an issue. So, maybe the problem is not in the process of detaching a controller that is being used, but rather in not having the controller available. Intel includes some USB controller in CPU and quick Googling suggests that so does AMD. Maybe there is some AMD-specific code in Linux kernel that expects the USB controller to be available for whatever weird reason. Yes, it sounds strange, but it is the least implausible explanation I was able to find. Regards, Vít Šesták 'v6ak' -- 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/744c4e79-efef-475a-a3dd-41fd3ded10b3%40googlegroups.com.