aboutsummaryrefslogtreecommitdiffstats
path: root/tox.ini
blob: 313f1eca27f3e8c537194b7d99334158d3acfbc9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
[tox]
minversion = 2.0
skipsdist = True
envlist = py{27,3},pep8,functional{,-py3},coverage

[testenv]
usedevelop=True
passenv = http_proxy HTTP_PROXY https_proxy HTTPS_PROXY no_proxy NO_PROXY BRANCH
setenv =
   VIRTUAL_ENV={envdir}
deps =
    -r{toxinidir}/requirements.txt
    -r{toxinidir}/test-requirements.txt
whitelist_externals = /bin/bash

[testenv:py27]
commands =
  /bin/bash {toxinidir}/tools/run_tests.sh --unit

[testenv:py3]
basepython = python3
commands = {[testenv:py27]commands}

[testenv:pep8]
# for gate testing, scans only the files changed in the last commit
commands =
  /bin/bash tools/coding-checks.sh --pylint HEAD~ '{posargs}'

[testenv:pep8-full]
# For manual testing, scans the whole codebase
commands =
  /bin/bash tools/coding-checks.sh --pylint '{posargs}'

[testenv:coverage]
basepython = python3
commands =
  /bin/bash {toxinidir}/tools/run_tests.sh --coverage

[testenv:functional]
commands =
  /bin/bash {toxinidir}/tools/run_tests.sh --functional

[testenv:functional-py3]
basepython = python3
commands = {[testenv:functional]commands}

[testenv:os-requirements]
commands =
    python {toxinidir}/tools/os-requirements-check.py {envdir}
roller mode there are two completely separate USB busses: One USB 1.1 bus driven by the UHCI controller and one USB 2.0 bus driven by the EHCI controller. Devices must be attached to the correct controller manually. The '-usb' switch will make qemu create the UHCI controller as part of the PIIX3 chipset. The USB 1.1 bus will carry the name "usb-bus.0". You can use the standard -device switch to add a EHCI controller to your virtual machine. It is strongly recommended to specify an ID for the controller so the USB 2.0 bus gets a individual name, for example '-device usb-ehci,id=ehci". This will give you a USB 2.0 bus named "ehci.0". I strongly recomment to also use -device to attach usb devices because you can specify the bus they should be attached to this way. Here is a complete example: qemu -M pc ${otheroptions} \ -drive if=none,id=usbstick,file=/path/to/image \ -usb \ -device usb-ehci,id=ehci \ -device usb-tablet,bus=usb-bus.0 \ -device usb-storage,bus=ehci.0,drive=usbstick This attaches a usb tablet to the UHCI adapter and a usb mass storage device to the EHCI adapter. Companion controller support ---------------------------- Companion controller support has been added recently. The operational model described above with two completely separate busses still works fine. Additionally the UHCI and OHCI controllers got the ability to attach to a usb bus created by EHCI as companion controllers. This is done by specifying the masterbus and firstport properties. masterbus specifies the bus name the controller should attach to. firstport specifies the first port the controller should attach to, which is needed as usually one ehci controller with six ports has three uhci companion controllers with two ports each. There is a config file in docs which will do all this for you, just try ... qemu -readconfig docs/ich9-ehci-uhci.cfg ... then use "bus=ehci.0" to assign your usb devices to that bus. xhci controller support ----------------------- There is also xhci host controller support available. It got a lot less testing than ehci and there are a bunch of known limitations, so ehci may work better for you. On the other hand the xhci hardware design is much more virtualization-friendly, thus xhci emulation uses less resources (especially cpu). If you want to give xhci a try use this to add the host controller ... qemu -device nec-usb-xhci,id=xhci ... then use "bus=xhci.0" when assigning usb devices. More USB tips & tricks ====================== Recently the usb pass through driver (also known as usb-host) and the qemu usb subsystem gained a few capabilities which are available only via qdev properties, i,e. when using '-device'. physical port addressing ------------------------ First you can (for all usb devices) specify the physical port where the device will show up in the guest. This can be done using the "port" property. UHCI has two root ports (1,2). EHCI has four root ports (1-4), the emulated (1.1) USB hub has eight ports. Plugging a tablet into UHCI port 1 works like this: -device usb-tablet,bus=usb-bus.0,port=1 Plugging a hub into UHCI port 2 works like this: -device usb-hub,bus=usb-bus.0,port=2 Plugging a virtual usb stick into port 4 of the hub just plugged works this way: -device usb-storage,bus=usb-bus.0,port=2.4,drive=... You can do basically the same in the monitor using the device_add command. If you want to unplug devices too you should specify some unique id which you can use to refer to the device ... (qemu) device_add usb-tablet,bus=usb-bus.0,port=1,id=my-tablet (qemu) device_del my-tablet ... when unplugging it with device_del. USB pass through hints ---------------------- The usb-host driver has a bunch of properties to specify the device which should be passed to the guest: hostbus=<nr> -- Specifies the bus number the device must be attached to. hostaddr=<nr> -- Specifies the device address the device got assigned by the guest os. hostport=<str> -- Specifies the physical port the device is attached to. vendorid=<hexnr> -- Specifies the vendor ID of the device. productid=<hexnr> -- Specifies the product ID of the device. In theory you can combine all these properties as you like. In practice only a few combinations are useful: (1) vendorid+productid -- match for a specific device, pass it to the guest when it shows up somewhere in the host. (2) hostbus+hostport -- match for a specific physical port in the host, any device which is plugged in there gets passed to the guest. (3) hostbus+hostaddr -- most useful for ad-hoc pass through as the hostaddr isn't stable, the next time you plug in the device it gets a new one ... Note that USB 1.1 devices are handled by UHCI/OHCI and USB 2.0 by EHCI. That means a device plugged into the very same physical port may show up on different busses depending on the speed. The port I'm using for testing is bus 1 + port 1 for 2.0 devices and bus 3 + port 1 for 1.1 devices. Passing through any device plugged into that port and also assign them to the correct bus can be done this way: qemu -M pc ${otheroptions} \ -usb \ -device usb-ehci,id=ehci \ -device usb-host,bus=usb-bus.0,hostbus=3,hostport=1 \ -device usb-host,bus=ehci.0,hostbus=1,hostport=1 enjoy, Gerd -- Gerd Hoffmann <kraxel@redhat.com>