Revision tags: v8.1.2 |
|
#
684750ab |
| 06-Oct-2023 |
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> |
python/qemu: rename command() to cmd()
Use a shorter name. We are going to move in iotests from qmp() to command() where possible. But command() is longer than qmp() and don't look better. Let's ren
python/qemu: rename command() to cmd()
Use a shorter name. We are going to move in iotests from qmp() to command() where possible. But command() is longer than qmp() and don't look better. Let's rename.
You can simply grep for '\.command(' and for 'def command(' to check that everything is updated (command() in tests/docker/docker.py is unrelated).
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-id: 20231006154125.1068348-6-vsementsov@yandex-team.ru [vsementsov: also update three occurrences in tests/avocado/machine_aspeed.py and keep r-b] Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
Revision tags: v8.1.2 |
|
#
684750ab |
| 06-Oct-2023 |
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> |
python/qemu: rename command() to cmd()
Use a shorter name. We are going to move in iotests from qmp() to command() where possible. But command() is longer than qmp() and don't look better. Let's ren
python/qemu: rename command() to cmd()
Use a shorter name. We are going to move in iotests from qmp() to command() where possible. But command() is longer than qmp() and don't look better. Let's rename.
You can simply grep for '\.command(' and for 'def command(' to check that everything is updated (command() in tests/docker/docker.py is unrelated).
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-id: 20231006154125.1068348-6-vsementsov@yandex-team.ru [vsementsov: also update three occurrences in tests/avocado/machine_aspeed.py and keep r-b] Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
Revision tags: v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3 |
|
#
c03f57fd |
| 08-Aug-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
Revert "tests: Use separate virtual environment for avocado"
This reverts commit e8e4298feadae7924cf7600bb3bcc5b0a8d7cbe9.
ensuregroup allows to specify both the acceptable versions of avocado, and
Revert "tests: Use separate virtual environment for avocado"
This reverts commit e8e4298feadae7924cf7600bb3bcc5b0a8d7cbe9.
ensuregroup allows to specify both the acceptable versions of avocado, and a locked version to be used when avocado is not installed as a system pacakge. This lets us install avocado in pyvenv/ using "mkvenv.py" and reuse the distro package on Fedora and CentOS Stream (the only distros where it's available).
ensuregroup's usage of "(>=..., <=...)" constraints when evaluating the distro package, and "==" constraints when installing it from PyPI, makes it possible to avoid conflicts between the known-good version and a package plugins included in the distro.
This is because package plugins have "==" constraints on the version that is included in the distro, and, using "pip install avocado==88.1" on a venv that includes system packages will result in an error:
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible. avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
But at the same time, if the venv does not include a system distribution of avocado then we can install a known-good version and stick to LTS releases.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1663 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3 |
|
#
c03f57fd |
| 08-Aug-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
Revert "tests: Use separate virtual environment for avocado"
This reverts commit e8e4298feadae7924cf7600bb3bcc5b0a8d7cbe9.
ensuregroup allows to specify both the acceptable versions of avocado, and
Revert "tests: Use separate virtual environment for avocado"
This reverts commit e8e4298feadae7924cf7600bb3bcc5b0a8d7cbe9.
ensuregroup allows to specify both the acceptable versions of avocado, and a locked version to be used when avocado is not installed as a system pacakge. This lets us install avocado in pyvenv/ using "mkvenv.py" and reuse the distro package on Fedora and CentOS Stream (the only distros where it's available).
ensuregroup's usage of "(>=..., <=...)" constraints when evaluating the distro package, and "==" constraints when installing it from PyPI, makes it possible to avoid conflicts between the known-good version and a package plugins included in the distro.
This is because package plugins have "==" constraints on the version that is included in the distro, and, using "pip install avocado==88.1" on a venv that includes system packages will result in an error:
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible. avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
But at the same time, if the venv does not include a system distribution of avocado then we can install a known-good version and stick to LTS releases.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1663 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0, v8.0.3, v7.2.4 |
|
#
e8e4298f |
| 05-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)", 2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for tests
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)", 2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when using a distro-provided package and wanting a "==" constraint when installing Avocado from PyPI; this would provide the best of both worlds in terms of resiliency for both distros that have required packages and distros that don't.
The conflict is visible also for meson, where we would like to install the latest 0.63.x version but also accept a distro 1.1.x version. But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv includes a system avocado. The distro will package plugins that have "==" constraints on the version that is included in the distro, and, using "pip install avocado==88.1" on a venv that includes system packages will result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible. avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible. make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system avocado, because that would result in the installation of v101.0 which is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked) tuple, like this hypothetical TOML that would be committed inside python/ and used by mkvenv.py:
[meson] meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs] # 6.0 drops support for Python 3.7 sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" } sphinx_rtd_theme = { minimum = "0.5" }
[avocado] avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora and CentOS Stream (the only distros where it's available). But until this is implemented, keep avocado in a separate venv. There is still the benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3 |
|
#
9c6692db |
| 11-May-2023 |
John Snow <jsnow@redhat.com> |
tests: Use configure-provided pyvenv for tests
This patch changes how the avocado tests are provided, ever so slightly. Instead of creating a new testing venv, use the configure-provided 'pyvenv' in
tests: Use configure-provided pyvenv for tests
This patch changes how the avocado tests are provided, ever so slightly. Instead of creating a new testing venv, use the configure-provided 'pyvenv' instead, and install optional packages into that.
Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-20-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3 |
|
#
9c6692db |
| 11-May-2023 |
John Snow <jsnow@redhat.com> |
tests: Use configure-provided pyvenv for tests
This patch changes how the avocado tests are provided, ever so slightly. Instead of creating a new testing venv, use the configure-provided 'pyvenv' in
tests: Use configure-provided pyvenv for tests
This patch changes how the avocado tests are provided, ever so slightly. Instead of creating a new testing venv, use the configure-provided 'pyvenv' instead, and install optional packages into that.
Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-20-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
8b869aa5 |
| 24-Apr-2023 |
Thomas Huth <thuth@redhat.com> |
scripts/device-crash-test: Add a parameter to run with TCG only
We're currently facing the problem that the device-crash-test script runs twice as long in the CI when a runner supports KVM - which s
scripts/device-crash-test: Add a parameter to run with TCG only
We're currently facing the problem that the device-crash-test script runs twice as long in the CI when a runner supports KVM - which sometimes results in a timeout of the CI job. To get a more deterministic runtime here, add an option to the script that allows to run it with TCG only.
Reported-by: Eldon Stegall <eldon-qemu@eldondev.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230414145845.456145-3-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230424092249.58552-6-alex.bennee@linaro.org>
show more ...
|
#
8b869aa5 |
| 24-Apr-2023 |
Thomas Huth <thuth@redhat.com> |
scripts/device-crash-test: Add a parameter to run with TCG only
We're currently facing the problem that the device-crash-test script runs twice as long in the CI when a runner supports KVM - which s
scripts/device-crash-test: Add a parameter to run with TCG only
We're currently facing the problem that the device-crash-test script runs twice as long in the CI when a runner supports KVM - which sometimes results in a timeout of the CI job. To get a more deterministic runtime here, add an option to the script that allows to run it with TCG only.
Reported-by: Eldon Stegall <eldon-qemu@eldondev.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230414145845.456145-3-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230424092249.58552-6-alex.bennee@linaro.org>
show more ...
|
#
8b869aa5 |
| 24-Apr-2023 |
Thomas Huth <thuth@redhat.com> |
scripts/device-crash-test: Add a parameter to run with TCG only
We're currently facing the problem that the device-crash-test script runs twice as long in the CI when a runner supports KVM - which s
scripts/device-crash-test: Add a parameter to run with TCG only
We're currently facing the problem that the device-crash-test script runs twice as long in the CI when a runner supports KVM - which sometimes results in a timeout of the CI job. To get a more deterministic runtime here, add an option to the script that allows to run it with TCG only.
Reported-by: Eldon Stegall <eldon-qemu@eldondev.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230414145845.456145-3-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230424092249.58552-6-alex.bennee@linaro.org>
show more ...
|
Revision tags: v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
1d8cf47e |
| 26-May-2022 |
John Snow <jsnow@redhat.com> |
tests: run 'device-crash-test' from tests/venv
Remove the sys.path hacking from device-crash-test, and add in a little user-friendly message for anyone who was used to running this script directly f
tests: run 'device-crash-test' from tests/venv
Remove the sys.path hacking from device-crash-test, and add in a little user-friendly message for anyone who was used to running this script directly from the source tree.
Modify the GitLab job recipes to create the tests/venv first, then run device-crash-test from that venv.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220526000921.1581503-10-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
1d8cf47e |
| 26-May-2022 |
John Snow <jsnow@redhat.com> |
tests: run 'device-crash-test' from tests/venv
Remove the sys.path hacking from device-crash-test, and add in a little user-friendly message for anyone who was used to running this script directly f
tests: run 'device-crash-test' from tests/venv
Remove the sys.path hacking from device-crash-test, and add in a little user-friendly message for anyone who was used to running this script directly from the source tree.
Modify the GitLab job recipes to create the tests/venv first, then run device-crash-test from that venv.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220526000921.1581503-10-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
4f8db871 |
| 29-Apr-2022 |
Ben Widawsky <ben.widawsky@intel.com> |
hw/pxb: Allow creation of a CXL PXB (host bridge)
This works like adding a typical pxb device, except the name is 'pxb-cxl' instead of 'pxb-pcie'. An example command line would be as follows: -dev
hw/pxb: Allow creation of a CXL PXB (host bridge)
This works like adding a typical pxb device, except the name is 'pxb-cxl' instead of 'pxb-pcie'. An example command line would be as follows: -device pxb-cxl,id=cxl.0,bus="pcie.0",bus_nr=1
A CXL PXB is backward compatible with PCIe. What this means in practice is that an operating system that is unaware of CXL should still be able to enumerate this topology as if it were PCIe.
One can create multiple CXL PXB host bridges, but a host bridge can only be connected to the main root bus. Host bridges cannot appear elsewhere in the topology.
Note that as of this patch, the ACPI tables needed for the host bridge (specifically, an ACPI object in _SB named ACPI0016 and the CEDT) aren't created. So while this patch internally creates it, it cannot be properly used by an operating system or other system software.
Also necessary is to add an exception to scripts/device-crash-test similar to that for exiting pxb as both must created on a PCIexpress host bus.
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Signed-off-by: Jonathan.Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220429144110.25167-15-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.0.0, v7.0.0-rc4, v7.0.0-rc3 |
|
#
37094b6d |
| 30-Mar-2022 |
John Snow <jsnow@redhat.com> |
python: rename qemu.aqmp to qemu.qmp
Now that we are fully switched over to the new QMP library, move it back over the old namespace. This is being done primarily so that we may upload this package
python: rename qemu.aqmp to qemu.qmp
Now that we are fully switched over to the new QMP library, move it back over the old namespace. This is being done primarily so that we may upload this package simply as "qemu.qmp" without introducing confusion over whether or not "aqmp" is a new protocol or not.
The trade-off is increased confusion inside the QEMU developer tree. Sorry!
Note: the 'private' member "_aqmp" in legacy.py also changes to "_qmp"; not out of necessity, but just to remove any traces of the "aqmp" name.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Beraldo Leal <bleal@redhat.com> Acked-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org> Message-id: 20220330172812.3427355-8-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
Revision tags: v7.0.0-rc2, v7.0.0-rc1, v7.0.0-rc0, v6.1.1, v6.2.0, v6.2.0-rc4, v6.2.0-rc3, v6.2.0-rc2 |
|
#
206439cd |
| 18-Nov-2021 |
John Snow <jsnow@redhat.com> |
scripts/device-crash-test: Use a QMP timeout
Despite all the previous fixes, it's still possible for device-crash-test to wedge itself in the case that QEMU terminates *so quickly* that it doesn't e
scripts/device-crash-test: Use a QMP timeout
Despite all the previous fixes, it's still possible for device-crash-test to wedge itself in the case that QEMU terminates *so quickly* that it doesn't even begin a connection attempt to our QMP client. Python will just joyfully wait ad infinitum for a connection that will now never arrive.
The real fix is to use asyncio to simultaneously poll both the health of the launched process AND the connection attempt. That's quite a bit more invasive than just setting a connection timeout, though.
Do the very simplest thing for now.
Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20211118204620.1897674-7-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
Revision tags: v6.2.0-rc1 |
|
#
418ce020 |
| 12-Nov-2021 |
Thomas Huth <thuth@redhat.com> |
Revert "device-crash-test: Ignore errors about a bus not being available"
This reverts commit ca89d15f8e42f2e5eac5bd200af38fdbfb32e875.
There is already an entry for this kind of messages earlier i
Revert "device-crash-test: Ignore errors about a bus not being available"
This reverts commit ca89d15f8e42f2e5eac5bd200af38fdbfb32e875.
There is already an entry for this kind of messages earlier in the ERROR_RULE_LIST - when I added this patch, I just got fooled by the other errors that occur due to a race between QMP connection and QEMU terminating early (which still spit out the 'No bus found' messages in their backtrace), but these other problems have now fortunately been tackled by John Snow, so we certainly don't need this duplicated entry here anymore.
Message-Id: <20211112072220.108580-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
c398a241 |
| 11-Nov-2021 |
John Snow <jsnow@redhat.com> |
scripts/device-crash-test: hide tracebacks for QMP connect errors
Generally, the traceback for a connection failure is uninteresting and all we need to know is that the connection attempt failed.
R
scripts/device-crash-test: hide tracebacks for QMP connect errors
Generally, the traceback for a connection failure is uninteresting and all we need to know is that the connection attempt failed.
Reduce the verbosity in these cases, except when debugging.
Signed-off-by: John Snow <jsnow@redhat.com> Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20211111143719.2162525-6-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
76f86e78 |
| 11-Nov-2021 |
John Snow <jsnow@redhat.com> |
scripts/device-crash-test: don't emit AQMP connection errors to stdout
These errors are expected, so they shouldn't clog up terminal output. In the event that they're *not* expected, we'll be seeing
scripts/device-crash-test: don't emit AQMP connection errors to stdout
These errors are expected, so they shouldn't clog up terminal output. In the event that they're *not* expected, we'll be seeing an awful lot more output concerning the nature of the failure.
Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20211111143719.2162525-5-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
47b43acd |
| 11-Nov-2021 |
John Snow <jsnow@redhat.com> |
scripts/device-crash-test: simplify Exception handling
We don't need to handle KeyboardInterruptError specifically; we can instead tighten the scope of the broad Exception handlers to only catch "Ex
scripts/device-crash-test: simplify Exception handling
We don't need to handle KeyboardInterruptError specifically; we can instead tighten the scope of the broad Exception handlers to only catch "Exception", which has the effect of allowing all BaseException classes that do not inherit from Exception to be raised through.
KeyboardInterruptError and a few other important ones are BaseExceptions, so this does the same thing with less code.
Signed-off-by: John Snow <jsnow@redhat.com> Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20211111143719.2162525-4-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
Revision tags: v6.2.0-rc0, v6.0.1, v6.1.0, v6.1.0-rc4, v6.1.0-rc3, v6.1.0-rc2, v6.1.0-rc1, v6.1.0-rc0, v6.0.0, v6.0.0-rc5, v6.0.0-rc4, v6.0.0-rc3, v6.0.0-rc2, v6.0.0-rc1, v6.0.0-rc0 |
|
#
ca89d15f |
| 23-Mar-2021 |
Thomas Huth <thuth@redhat.com> |
device-crash-test: Ignore errors about a bus not being available
Recent QEMU versions now sometimes exit cleanly with an error message that a bus is not available for a specified device. Don't flag
device-crash-test: Ignore errors about a bus not being available
Recent QEMU versions now sometimes exit cleanly with an error message that a bus is not available for a specified device. Don't flag those as an error in the device-crash-test script.
Message-Id: <20210323164718.1393792-1-thuth@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
#
879be3af |
| 22-Feb-2021 |
Daniel P. Berrangé <berrange@redhat.com> |
hw/scsi: remove 'scsi-disk' device
The 'scsi-hd' and 'scsi-cd' devices provide suitable alternatives.
Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.
hw/scsi: remove 'scsi-disk' device
The 'scsi-hd' and 'scsi-cd' devices provide suitable alternatives.
Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
#
b5010183 |
| 22-Feb-2021 |
Daniel P. Berrangé <berrange@redhat.com> |
hw/ide: remove 'ide-drive' device
The 'ide-hd' and 'ide-cd' devices provide suitable alternatives.
Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
#
1a14d4e1 |
| 02-Feb-2021 |
Eduardo Habkost <ehabkost@redhat.com> |
device-crash-test: Remove problematic language
Replace "whitelist" in the device-crash-test script with "rule list".
I'm using "rule list" instead of "allow list" or "pass list" because the list is
device-crash-test: Remove problematic language
Replace "whitelist" in the device-crash-test script with "rule list".
I'm using "rule list" instead of "allow list" or "pass list" because the list is not used only for expected/allowed errors. It also contain rules specifying which errors shouldn't be ignored and/or should be fatal.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210202191207.4103973-1-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
show more ...
|
Revision tags: v5.2.0, v5.2.0-rc4, v5.2.0-rc3, v5.2.0-rc2, v5.2.0-rc1, v5.2.0-rc0 |
|
#
8a478365 |
| 26-Oct-2020 |
Eduardo Habkost <ehabkost@redhat.com> |
device-crash-test: Check if path is actually an executable file
After the transition to Meson, the build directory now have subdirectories named "qemu-system-*.p", and device-crash-test will try to
device-crash-test: Check if path is actually an executable file
After the transition to Meson, the build directory now have subdirectories named "qemu-system-*.p", and device-crash-test will try to execute them as if they were binaries. This results in errors like:
PermissionError: [Errno 13] Permission denied: './qemu-system-or1k.p'
When generating the default list of binaries to test, check if the path is actually a file and if it's executable.
Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20201026125238.2752882-1-ehabkost@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v5.0.1, v5.1.0, v5.1.0-rc3 |
|
#
64ed6f92 |
| 03-Aug-2020 |
Paolo Bonzini <pbonzini@redhat.com> |
meson: link emulators without Makefile.target
The binaries move to the root directory, e.g. qemu-system-i386 or qemu-arm. This requires changes to qtests, CI, etc.
Signed-off-by: Marc-André Lureau
meson: link emulators without Makefile.target
The binaries move to the root directory, e.g. qemu-system-i386 or qemu-arm. This requires changes to qtests, CI, etc.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|