Error while assigning USB-Controller to usb-vm

[Fabian Wloch]

Hello,
i just installed Qubes R3 on my Notebook (MSI Gp60 2PE Leopard), which
works fine, beside 1 thing: I cant assign my USB Controller to an
USB-VM.
To be more exactly, only the USB 3.0 Controller is affected.

If i assign the controller to the VM, i get the following Error:
<----------------->
Error starting domain: internal error Unable to reset PCI
device 0000:00:14.0: no FLR, PM reset or bus reset available.
<----------------->

The thing is, that this worked pretty fine under R2, which is why im
wondering why it isnt working now.

I dont really find an answer which is helping me. The only solution i
found, was to assign all other PCI devices to that VM which are running
under the same bus as the mentioned device. But i have no idea how to
find out, which devices are meant actually.
And the thing i mentioned above - under Version R2 it worked, so this
couldnt be the problem, right?

Has anyone any suggestions?

Regards,
Fabian

[Fabian Wloch]

Hello again,
as i expected, i dont have the problem with Qubes R2, everything works
fine there with USB assigning.
By the way, if i dont start the VM before assigning the USB Controller
to it, i dont get any logfiles regarding this VM :(
I´ll test to upgrade manually from R2 to R3 now, maybe this works..

---
Mit freundlichen Grüßen,
Fabian Wloch

[tel]

No suggestions, but I can confirm this problem with a fresh install of R3. As you point out, no problems with R2. 

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a "feature"... Toolstack used in Qubes R2 ignore any errors
during reset of PCI device (either during device assignment to VM, or
cleanup). In R3 we use libvirt, which does not ignore such errors. And
it isn't configurable there.

I'm working on some workaround for that, but the default is correct -
assigning to VM a PCI device which does not support reset isn't safe and
shouldn't be done.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVPUbcAAoJENuP0xzK19csHncH/2LItiyRjkQLvV3bNaAmYzl0
JP+pFmxn8o7Nk7Kj1EnWWW9hhsCmGGut62dlUG1bptEWvXpQnySONu4/e/6EeGr4
VImMuWDmyqz5auHX1EsT5OaBFyPUmoCWdOA78HaMUa6k1Nud7XmUqjaasBWs20OY
PxKqWuQhnVHicvr6aUbAAeTqdVTemkZ2YFBb9GUGAbf3UbHgq659/plZR1DUjWiH
fdR4Im+0HNkiSr4brV1fVNjlSi3J7GFhcLTd2ReJJnvXG/sODS32Zti1p47tKkgq
GyohnAyRNIxpphHBRhLryXPhBK1PdOjLirDhYyrkqNTMCKOVDmCuHk3XKGBxj7c=
=Aw6p
-----END PGP SIGNATURE-----

[Fabian Wloch]

> This is a "feature"... Toolstack used in Qubes R2 ignore any errors
> during reset of PCI device (either during device assignment to VM, or
> cleanup). In R3 we use libvirt, which does not ignore such errors. And
> it isn't configurable there.
> I'm working on some workaround for that, but the default is correct -
> assigning to VM a PCI device which does not support reset isn't safe
> and
> shouldn't be done.

Why exactly isnt it safe?
I mean, i dont really know what (for example) the FLR does
(technically), but as far as i can imagine it "resets" the Device after
releasing it from a VM, so another VM can use it.
But since i use Qubes, i never unattached the USB-Controller from that
vm, nor i shut the usbvm down/the usbvm crashed.
So this is at least safer than not using a usbvm at all, right?

Beside that - so i simply dont use usb hardware till this is fixed.
Luckily i dont do this very often anyways..

-Fabian

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 26, 2015 at 11:11:45PM +0200, Fabian Wloch wrote:
>
> >This is a "feature"... Toolstack used in Qubes R2 ignore any errors
> >during reset of PCI device (either during device assignment to VM, or
> >cleanup). In R3 we use libvirt, which does not ignore such errors. And
> >it isn't configurable there.
> >I'm working on some workaround for that, but the default is correct -
> >assigning to VM a PCI device which does not support reset isn't safe and
> >shouldn't be done.
>
> Why exactly isnt it safe?
> I mean, i dont really know what (for example) the FLR does (technically),
> but as far as i can imagine it "resets" the Device after releasing it from a
> VM, so another VM can use it.
> But since i use Qubes, i never unattached the USB-Controller from that vm,
> nor i shut the usbvm down/the usbvm crashed.
> So this is at least safer than not using a usbvm at all, right?

Theoretically if the device isn't properly reset, it can compromise the
next VM you assign the device to.
In case of UsbVM in practice it shouldn't be a problem, because - as
you've said - you never detach the USB controller from UsbVM. But
libvirt does not know that.
Using UsbVM, even without proper PCI reset, is much safer than leaving
that USB controller in dom0.

> Beside that - so i simply dont use usb hardware till this is fixed. Luckily
> i dont do this very often anyways..

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVPWBQAAoJENuP0xzK19csrDkH/jHPb2QCYvR5yS47JWgkvMt5
jYNHMWhj5/AF/lLYBDOfNMbLM+HHJ+XR32H5CLp5GTsr47NVwQWVIbTrqylq+Jh7
q3g58pC4D5pOcil1MdGmP9pWdwzgces/aKQIw3AAfAwVSRlx+iFnGicK/z0nc79c
fH+JGAMlfjiE7NXjYy9wz17hbziwABDXZ78SJgAiWmyUEEl0HIJ3kK9n0BHEAC2p
O19fvrOuGDlALEQXsF9dn3o7Od0hv7WoZoK9PiOBRJ+e//Q4iKNXviduvL2rQERe
OdGhd3qioUGu9k+4qg2vOyrh+Y3e0D09KjUlOKeEPGnia7iSCs+F0fZkmvlX3VE=
=15+F
-----END PGP SIGNATURE-----

[Zrubi]

On 04/26/15 22:13, Marek Marczykowski-Górecki wrote:

>> If i assign the controller to the VM, i get the following Error:
>> <----------------->
>> Error starting domain: internal error Unable to reset PCI
>> device 0000:00:14.0: no FLR, PM reset or bus reset available.
>> <----------------->

I have the same issue.
My USB VM not start after I upgraded to 3.0-rc1.


--
Zrubi

[Oleg Artemiev]

I've also problem w/ assigning USB controller to VM, but that was only
till I diabled USB 3.0 support in BIOS. After that I have 1 less
controller available, but all ports moved to 2.0 controllers and are
assignable to VMs.

Here is information about problematic 3.0 controller:

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if
30 [XHCI])

May be this trick will work for you also.

[Fabian Wloch]

Hello,
thanks for the hint, but i cant force the adapters to USB 2.0 at all.
I´m only able to activate/deactivate the USB 3.0 support for the BIOS,
but not the USB Controllers itself or the USB 3.0 support.
And this does not help :/

But how i said, nothing really important. But still thanks for the try
:)

-Fabian

[Felipe Dau]

On Sunday, April 26, 2015 at 5:13:25 PM UTC-3, Marek Marczykowski-Górecki wrote:

    I'm working on some workaround for that, but the default is correct -
    assigning to VM a PCI device which does not support reset isn't safe and
    shouldn't be done.

Hi Marek! Have you got any progress? I'm having the same issue and still
haven't found a way to get an usb vm working.

Thanks!

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, there is qvm-prefs pci_strictreset option for that. If you set it
to false, the error would be ignored and the VM will start. Read the
manual of qvm-prefs about that option first.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV3StPAAoJENuP0xzK19cswdgH/Rf9qLewzfeWT8SNekwwSDWr
B54XmRXBL8l9CqR7+NLxK3966q/7/uqGDm7ILUFzjF80UVEIYhMvIwwX82ZiQZ+U
A7xmwK0DKMfNqAeN2f1kI5arr9uX5QuP1OEhFgJtOciRzFxGxv1//FXVYrlkfuuI
RtoTUdPjB/WracmzbrwO8c9WN3v2LIEsyXNxdzpSawH4sbWegd3j2DIsofZ8VIWf
jfGs3fMfMRZrHTXyNOluwPOMO0o5l4EQ4GyCI73RuUmp3d8eQtjkSzmHebrzEvUx
qlwhnlYIPPkuP+vJOkF60DBxXbV9IxJJ7xCX+TjYHQYbMESCbkx3bjDxZyfXjfI=
=lmIV
-----END PGP SIGNATURE-----

[Felipe Dau]

On Tuesday, August 25, 2015 at 11:58:30 PM UTC-3, Marek Marczykowski-Górecki wrote:

Yes, there is qvm-prefs pci_strictreset option for that. If you set it
to false, the error would be ignored and the VM will start. Read the
manual of qvm-prefs about that option first.

Thank you, Marek! That worked.

Could that be added to the documentation in sections related to USB
controllers such as [Creating and Using a USBVM][1]? A quick search
("pci_strictreset site:qubes-os.org") shows that the option is only
mentioned in the qvm-prefs man page, and honestly I didn't know I
could use that because I didn't read the whole DomZeroTools section.

Thanks.

[1]: https://www.qubes-os.org/doc/SecurityGuidelines/#creating-and-using-a-usbvm

[Unman]

On Tue, Sep 01, 2015 at 09:24:19PM -0700, Felipe Dau wrote:
> On Tuesday, August 25, 2015 at 11:58:30 PM UTC-3, Marek

I've put in a PR with an entry in to the FAQ, as it seems to be a common
issue.

unman

[cprise]

Me too. It is Intel "7 series/C210 series" USB host controller.

[mari...@openmailbox.org]

Hi,
Sorry for his ot, but..
I have searched for a UserDoc page where are explained how to get a
usb-vm.

Could you send a link please?

Thanks you

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Sep 07, 2015 at 03:01:22PM +0200, mari...@openmailbox.org wrote:
> Hi,
> Sorry for his ot, but..
> I have searched for a UserDoc page where are explained how to get a usb-vm.
>
> Could you send a link please?

It is here:
https://www.qubes-os.org/doc/UserFaq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot

More links to this section will be added soon.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV7Yy6AAoJENuP0xzK19csbvoH/3BxUoE3sFfmy4kQaKL5sxZK
48xW3g1z6lTAP8PfwYJj089VGGzAIujQhyAYOTDcAEiF1R4Gh3UgiIo5AOn2AZRR
GHiZ+4ZQFLZaVuurtHhEMh6DVvUq45DGvYPhhRST2LrTsJ7Ao0H6ihz6+7IvWu5R
zMrzeCB6MUYMB8ye/X8hRJdAeDEJXXmB6lU/cWC8mthtOnS722Zzb/zhOA/1fJHO
m7TBB0rgRb6wWo8Z4Hmf8u6agJgj8Yrt+e+7x6bKPTg3JZ947Skb90KwFDeF+Onl
8wI2g8gXJDiRHxmQmlFe0LihaDl7c0JyKSSoKYWSrch9Kp4XfjXYizM+OppSdjk=
=y6bw
-----END PGP SIGNATURE-----