aboutsummaryrefslogtreecommitdiff
path: root/python
AgeCommit message (Collapse)Author
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>