Re: [qubes-users] Solved/Progress [Re: Cannot assign USB controller to App VM anymore (Qubes 3.2)]
Thank you for looking into this! Am Samstag, 3. März 2018 13:28:24 UTC+1 schrieb awokd: > On Fri, March 2, 2018 2:27 pm, Stefan wrote: > > > https://www.qubes-os.org/doc/assigning-devices/ > > > > > > and tried enabling 'permissive' mode as described for R3.2 in the above > > documentation. However, this per se doesn't work, as the target file > > (/sys/bus/pci/drivers/pciback/permissive) > > is not writeable, even for root and even when triggered through systemd. > > Just tested again on R3.2 and the procedure in the doc works, but only for > re-assignable devices (ones using the pciback driver in lspci). Are you > sure you were trying to write the correct :? When I tried with an > un-assignable device, I got: > > bash: echo: write error: No such device > This sounds like the error I got; don't really know what the properties of this USB hub are. I did not follow up as this isn't necessary > > > > >> > >> And xl dmesg shows: > >> > >> > >> XEN) [VT-D] It's disallowed to assign :00:1a.0 with shared RMRR at > >> da8d5000 for Dom5. (XEN) XEN_DOMCTL_assign_device: assign :00:1a.0 > >> to dom5 failed (-1) > >> > > > > For the record, xl dmesg is now telling me that > > [VT-D] It's risky to assign .. with shared RMRR at .. for Dom4 > > Setting pci_strictreset to false is what changed this message from > "disallowed" to "risky". > > > what ever that means. > > > > I don't know which of the options / changes did the trick, but one or > > more of the above seems to enable the camera in 'untrusted'. > > Setting pci_strictreset to false. It indeed looks like it. I reset everything (to the best of my recollection) and played again with the various options to pass through the USB hub to 'untrusted'. And indeed, this time around, setting pci_strictreset to false was enough. I was a 100% positive that I tried that before and it seemed not to work. However, this time, after qvm-reset -s .. I rebooted before trying whether this changed anything. Anyways, thanks again for your help! Stefan -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0682b44e-f24f-4a9d-8663-98c82d3b9a0c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Solved/Progress [Re: Cannot assign USB controller to App VM anymore (Qubes 3.2)]
On Fri, March 2, 2018 2:27 pm, sbore...@gmail.com wrote: > https://www.qubes-os.org/doc/assigning-devices/ > > > and tried enabling 'permissive' mode as described for R3.2 in the above > documentation. However, this per se doesn't work, as the target file > (/sys/bus/pci/drivers/pciback/permissive) > is not writeable, even for root and even when triggered through systemd. Just tested again on R3.2 and the procedure in the doc works, but only for re-assignable devices (ones using the pciback driver in lspci). Are you sure you were trying to write the correct :? When I tried with an un-assignable device, I got: bash: echo: write error: No such device > >> >> And xl dmesg shows: >> >> >> XEN) [VT-D] It's disallowed to assign :00:1a.0 with shared RMRR at >> da8d5000 for Dom5. (XEN) XEN_DOMCTL_assign_device: assign :00:1a.0 >> to dom5 failed (-1) >> > > For the record, xl dmesg is now telling me that > [VT-D] It's risky to assign .. with shared RMRR at .. for Dom4 Setting pci_strictreset to false is what changed this message from "disallowed" to "risky". > what ever that means. > > I don't know which of the options / changes did the trick, but one or > more of the above seems to enable the camera in 'untrusted'. Setting pci_strictreset to false. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bc6c4fe2cd0600f39143797d52ddfef1.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Solved/Progress [Re: Cannot assign USB controller to App VM anymore (Qubes 3.2)]
I seem to have it working; I'll outline the steps in case others run into this. Nevertheless, I'd appreciate an 'authoritative answer' since I was 'fishing blindly'. [More see inline] Am Freitag, 2. März 2018 09:34:18 UTC+1 schrieb sbor...@gmail.com: > Dear Qubes community, > > after using 3.1 and 3.2 in production on my primary laptop > (Lenovo X220), and having used that machine to test Qubes since R2, > I now have the need to make my built in camera available in an App VM (I > choose untrusted, but may a dedicated one later on). > > However, I am failing to pass through the > USB controller to the App VM. [snip] I reread https://www.qubes-os.org/doc/assigning-devices/ and tried enabling 'permissive' mode as described for R3.2 in the above documentation. However, this per se doesn't work, as the target file (/sys/bus/pci/drivers/pciback/permissive) is not writeable, even for root and even when triggered through systemd. However, I then compared the 'kernelopts' of 'sys-net' to those of 'untrusted', and noted that 'iommu=soft swiotlb=8192' where missing in the latter. So I added those, together with forcing 'pci_strictreset False'. After rebooting the whole machine, untrusted has grabbed the usb hub and sees the camera. The expected loss of a USB port due to the strange 'wiring' of the Lenovo X220 is acceptable to me; furthermore, I do plan to attach the pci device only when I know that I'll need the camera. [snip] > > And xl dmesg shows: > > XEN) [VT-D] It's disallowed to assign :00:1a.0 with shared RMRR at > da8d5000 for Dom5. > (XEN) XEN_DOMCTL_assign_device: assign :00:1a.0 to dom5 failed (-1) > For the record, xl dmesg is now telling me that [VT-D] It's risky to assign .. with shared RMRR at .. for Dom4 what ever that means. I don't know which of the options / changes did the trick, but one or more of the above seems to enable the camera in 'untrusted'. Best regards, Stefan -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4d5f0ff0-e25a-4cdd-81f3-d8e98db7525a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
