On Wed, 2023-08-09 at 20:53 +0100, Edwin Török wrote:
> On Mon, 2023-08-07 at 21:45 +0100, 'Edwin Török' via qubes-users
> wrote:
> >
> > Must NOT use a USB qube. Using a USB qube results in an
> > instant
> > host reboot as soon as the USB qube is booted (same issue happen on
> > KVM
> > when attempting to pass through any USB controller, even if the
> > controller is in an IOMMU group of its own). There is a newer BIOS
> > with
> > newer AGESA available, I'll have to retry using that. Using
> > permissive
> > mode or non-strict PCI reset doesn't help:
>
> New BIOS doesn't help, but I found one source of the host reboot: bus
> reset of the USB3 controller PCI device.
>
> /sys/bus/pci/devices/0000:13:00.0/reset_method has 'bus',
> and its parent /sys/bus/pci/devices/0000:00:08.3/reset_method has
> 'pm'.
> No FLR on these (which is confirmed by 'lspci' it says FLReset-).
>
> Changing 'bus' to 'pm', and performing an unbind from
> /sys/bus/pci/drivers/xhci_hcd, and then echoing '1' to 'reset' seems
> to
> survive and it no longer causes the system to power off.
> (now I don't know whether the problem is with reseting the device, or
> resetting the parent's secondary bus, IIUC even if parent device's
> reset method is pm, secondary bus will still be reset if that is what
> the child does).
>
> Note that all the other USB controller's reset_method is already
> 'pm'.
>
> All but one USB controller is in D3hot (which is expected), the other
> is D0. Is a bus reset of a device in D3hot even valid?
I tried plugging a USB device in the controller so it went to D0 and
changes reset method to pm on its own, but that didn't help.
However I found out that I *can* pass-through 2/4 USB controllers,
these ones are safe to pass through:
```
+-02.1-[06-10]----00.0-[07-10]--+-00.0-[08]--
| +-0c.0-[0f]----00.0
Advanced Micro Devices, Inc. [AMD] Device [1022:43f7]
+-08.1-[12]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Raphael
[1002:164e]
| +-00.3 Advanced Micro Devices, Inc. [AMD]
Device [1022:15b6]
```
These ones are NOT safe to pass through, they result in instant power
off of the host, followed by a poweron couple of seconds later:
```
+-08.1-[12]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Raphael
[1002:164e]
| +-00.4 Advanced Micro Devices, Inc. [AMD]
Device [1022:15b7]
+-08.3-[13]----00.0 Advanced Micro Devices, Inc. [AMD] Device
[1022:15b8]
```
This is very weird because 12.03 and 12.04 are quite similar from a
topology point of view.
I'm not sure what Qubes could do to detect or avoid this situation, but
perhaps just hiding the USB controllers that are in D3hot instead of
passing them through is the safer option?
But even that becomes unsafe if I plug a USB device into 12.04.
Anyway I have a workaround now to at least pass some of my USB devices
through, and I have my Yubikey working in my 'vault' VM.
Best regards,
--Edwin
>
> Although changing the 'reset_method' still doesn't make device pass-
> through work: attempting to pass it through still causes a host
> reboot
> (although more like a poweroff followed by a powerup than a warm
> reboot, I tried disabling various options in the BIOS but it still
> powers off directly, e.g. the PSP/SMU debug mode appeared promising
> but
> didn't help).
>
> Best regards,
> --Edwin
--
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/f88f1793125271923f2b884139d3a336a608599b.camel%40etorok.net.
