aboutsummaryrefslogtreecommitdiff
path: root/python
AgeCommit message (Collapse)Author
2019-09-19Replace '-machine accel=xyz' with '-accel xyz'Thomas Huth
We've got a separate option to configure the accelerator nowadays, which is shorter to type and the preferred way of specifying an accelerator. Use it in the source and examples to show that it is the favored option. (However, do not touch the places yet which also specify other machine options or multiple accelerators - these are currently still better handled with one single "-machine" statement instead) Signed-off-by: Thomas Huth <thuth@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20190904052739.22123-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2019-07-19iotests: Add @has_quit to vm.shutdown()Max Reitz
If a test has issued a quit command already (which may be useful to do explicitly because the test wants to show its effects), QEMUMachine.shutdown() should not do so again. Otherwise, the VM may well return an ECONNRESET which will lead QEMUMachine.shutdown() to killing it, which then turns into a "qemu received signal 9" line. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-07-01machine.py: minor delintingJohn Snow
Since we're out in a new module, do a quick cursory pass of some of the more obvious style issues. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20190627212816.27298-3-jsnow@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-07-01python/qemu: split QEMUMachine out from underneath __init__.pyJohn Snow
It's not obvious that something named __init__.py actually houses important code that isn't relevant to python packaging glue. Move the QEMUMachine and related error classes out into their own module. Adjust users to the new import location. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20190627212816.27298-2-jsnow@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-06-14event_match: always match on None valueJohn Snow
Before, event_match didn't always recurse if the event value was not a dictionary, and would instead check for equality immediately. By delaying equality checking to post-recursion, we can allow leaf values like "5" to match "None" and take advantage of the generic None-returns-True clause. This makes the matching a little more obviously consistent at the expense of being able to check for explicit None values, which is probably not that important given what this function is used for. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20190528183857.26167-1-jsnow@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-06-14QEMUMachine: add events_wait methodJohn Snow
Instead of event_wait which looks for a single event, add an events_wait which can look for any number of events simultaneously. However, it will still only return one at a time, whichever happens first. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20190523170643.20794-4-jsnow@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-05-02scripts/qemu.py: support adding a console with the default serial deviceCleber Rosa
The set_console() utility function either adds a device based on the explicitly given device type, or adds a known good type of device based on the machine type. But, for a number of machine types, it may be impossible or inconvenient to add the devices by means of "-device" command line options, and then it may better to just use the "-serial" option and let QEMU itself, based on the machine type, set the device accordingly. To achieve that, the behavior of set_console() now flags the intention to add a console device on launch(), and if no explicit device type is given the "-serial" option is going to be added to the QEMU command line, instead of raising exceptions. Based on testing with different machine types, the CONSOLE_DEV_TYPES is not necessary anymore, so it's being removed, as is the logic to use it. Signed-off-by: Cleber Rosa <crosa@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190312171824.5134-13-crosa@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-07Merge remote-tracking branch 'remotes/cleber/tags/python-next-pull-request' ↵Peter Maydell
into staging Python queue, 2019-02-22 Python: * introduce "python" directory with module namespace * log QEMU launch command line on qemu.QEMUMachine Acceptance Tests: * initrd 4GiB+ test * migration test * multi vm support in test class * bump Avocado version and drop ":avocado: enable" # gpg: Signature made Fri 22 Feb 2019 19:37:07 GMT # gpg: using RSA key 657E8D33A5F209F3 # gpg: Good signature from "Cleber Rosa <crosa@redhat.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 7ABB 96EB 8B46 B94D 5E0F E9BB 657E 8D33 A5F2 09F3 * remotes/cleber/tags/python-next-pull-request: Acceptance tests: expect boot to extract 2GiB+ initrd with linux-v4.16 Acceptance tests: use linux-3.6 and set vm memory to 4GiB tests.acceptance: adds simple migration test tests.acceptance: adds multi vm capability for acceptance tests scripts/qemu.py: log QEMU launch command line Introduce a Python module structure Acceptance tests: drop usage of ":avocado: enable" Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-22scripts/qemu.py: log QEMU launch command lineCleber Rosa
Even when the launch of QEMU succeeds, it's useful to have the command line recorded. Reviewed-by: Caio Carrara <ccarrara@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20190202005610.24048-2-crosa@redhat.com> Signed-off-by: Cleber Rosa <crosa@redhat.com>
2019-02-22Introduce a Python module structureCleber Rosa
This is a simple move of Python code that wraps common QEMU functionality, and are used by a number of different tests and scripts. By treating that code as a real Python module, we can more easily: * reuse code * have a proper place for the module's own unittests * apply a more consistent style * generate documentation Signed-off-by: Cleber Rosa <crosa@redhat.com> Reviewed-by: Caio Carrara <ccarrara@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20190206162901.19082-2-crosa@redhat.com> Signed-off-by: Cleber Rosa <crosa@redhat.com>