3.0 to 3.1 in place upgrade broke USB VMs

[Vincent Adultman]

The in place upgrade from 3.0 to 3.1 broke my two USB VMs (one controller with ports, one controller with devices) which were both set to auto start and working on 3.0.

The error is similar to that where devices are assigned to another running VM -  this is not the case however.

livirt.libvirtError: Requested operation is not valid: PCI device xyz is in use by driver xenlight, domain usbvm

sys-net still auto starts and everything else seems to work.  Both VMs start fine without the USB devices assigned.

I've tried hiding the devices from dom0 in case this made any difference using the kernel line in the docs, but this has made no difference.

TIA

[Vincent Adultman]

Apologies, this appears to be the shared RMRR problem discussed in

https://github.com/QubesOS/qubes-issues/issues/1544

This is indeed in the FAQ, but I was thrown by the doc at

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

stating the problem began in R3.0, when by this experience it actually seems to have been introduced in R3.1 xen 4.6?. Pity as it was nice having USB ports and built-in USB devices in separate VMs. Although I guess it's for the best, as I was relying on the reset ability which apparently wasn't supported by the hardware...

In any case, worth a note on https://www.qubes-os.org/doc/upgrade-to-r3.1/ page?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Sounds like it could have been introduced in R3.1 Xen 4.6 for you
specifically due to your hardware. If that's the case, it wouldn't
be a good idea to note this on the page, since it might not apply
to others.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX56cvAAoJENtN07w5UDAwsDMP/Avq9gWOOFSZTiEq3tJgXRD9
B6WEMhrnn/ThDLIaTOaL2dGP2vfttSmY/M/OLiRqMNpri7TprYD6wI0/+z+DnHaL
LRVNDKzkcn727wRc+K9IteOAs2SOg1LfVweaLZXWvMmIsqbyXdV14X+HMsFk3FR6
ZGHmCgcsOAAW9nhLxBK4+US5jxC+I52r/Ofo9Rq68Be3lCoydq9z6gQ6Pek/cELM
+GyeSQPSR0BQRG1z8Ppbn2ig40uncdNkZ2ImnWnrFsFu1w8SZgLthtBKiwg0d3Wf
qFFd68Tx2vvsNHQGsqtqP7tYOfRXd2uIZaRlqBjqqF6K/iqDhxJaq9HNtBY+QTPa
ML/CRBcE0EiPufLdSwxECzgZz0jeTTwHR2Hd8yqXEmlqUPRLelml69n/xzCvulZ3
ZF7tyXGjfOUca14PKCxUFgASlxOXogfu3DbJ5QQGoAkGBnfsXjBbmP0XCDlSU7OL
6VqNk7ttToXflpiS84yzSyY/T1YPBh7o5svUumXdcbYTmotMhl+kTHB66dqsn365
9PyJpdwNfpnpKQXzOTcRLZu4nbBMGdSlSfaEONRArdBbbMDF6yHEMrsb9DVRkvaP
C5AyOdq2L1Qn7FLNeqDqapWjCBaHv3v9dVQTl50jm0BDpA9tmlXzpjx8db+8+ugv
27fiZriXsdeEeP6B7Suh
=i+Ur
-----END PGP SIGNATURE-----

[Vincent Adultman]

Sounds like it could have been introduced in R3.1 Xen 4.6 for you

specifically due to your hardware. If that's the case, it wouldn't

be a good idea to note this on the page, since it might not apply

to others.

- --

Andrew David Wong (Axon)

Community Manager, Qubes OS

https://www.qubes-os.org

Thanks Andrew. That's interesting, I'd assumed it was a binary proposition introduced in 4.6 having only briefly scanned http://www.gossamer-threads.com/lists/xen/devel/391684 

If not I take your point however I still feel it should be referenced in some way on the upgrade instructions page to stop others potentially wasting the same time I did, and subsequently the lists time IF they run into it.

If the issue does not apply to users hardware, user will simply have no problem with their existing device to VM assignments and proposed note is ignored. Without a note, if it does apply to their hardware they may (stupidly) like me read the existing FAQ entry and assume pci strictreset is not the problem as otherwise problem would have begun in R3.0...

So perhaps it's the FAQ entry that needs clarifying? From a naive point of view, it makes sense that USB controllers might share some resources but on what appears to be "sensible" hardware that has one controller for USB ports and another for webcam etc it came as more of a surprise.

Best

Vince

[Marek Marczykowski-Górecki]

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

On Sun, Sep 25, 2016 at 08:06:19AM -0400, 'Vincent Adultman' via qubes-users wrote:
>> Sounds like it could have been introduced in R3.1 Xen 4.6 for you
>> specifically due to your hardware. If that's the case, it wouldn't
>> be a good idea to note this on the page, since it might not apply
>> to others.
>

> Thanks Andrew. That's interesting, I'd assumed it was a binary proposition introduced in 4.6 having only briefly scanned http://www.gossamer-threads.com/lists/xen/devel/391684

Yes, exactly. Previous Xen version didn't have that check. "Shared RMRR"
problem applies to most (if not all) USB controllers.

> So perhaps it's the FAQ entry that needs clarifying? From a naive point of view, it makes sense that USB controllers might share some resources but on what appears to be "sensible" hardware that has one controller for USB ports and another for webcam etc it came as more of a surprise.

Probably. But including link to it from upgrade instruction is good idea
too. Added.

- --
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 v2

iQEcBAEBCAAGBQJX58o8AAoJENuP0xzK19csG4cH/3kWIMFH6TR5dhwOkbWIxoAm
bKLgGRfOfOCSZaGbLDS0+qUOqu1q7Ats6M6fkTEOe/8wrBTGWExddxlapbeel89p
p0zGYNtfLtzjs5pcqRXMkihb1S9CCoXME3hRnQVb+v3Y/O82Xs7hSq+4XhsjN1DH
T53bsR4dkt/04YHnorhBVZA0Lv1zLh/mOgu3LN64pDb0DbFueWjlvw0eNdyWgMzr
eXds5E30wzD4N7y4n0D4cS56SbZhJrWcDkSTsvHGhimyXd3GFP9OZnIZpWu7epSu
zyCTIDwvW5Q8Q/osFA6dkDZNYgrci6sl/JdTEjHDYLKP5oEPLWkX2yjILAXKexg=
=NARb
-----END PGP SIGNATURE-----