aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-18build: move sanitizer tests to mesonPaolo Bonzini7-155/+66
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18meson: prepare move of QEMU_CFLAGS to mesonPaolo Bonzini1-24/+29
Clean up the handling of compiler flags in meson.build, splitting the general flags that should be included in subprojects as well, from warning flags that only apply to QEMU itself. The two were mixed in both configure tests and meson tests. This split makes it easier to move the compiler tests piecewise from configure to Meson. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18configure, meson: move --enable-modules to MesonPaolo Bonzini5-29/+20
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18configure: remove pkg-config functionsPaolo Bonzini2-21/+4
All uses of pkg-config have been moved to Meson. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18build: move glib detection and workarounds to mesonPaolo Bonzini4-118/+80
QEMU adds the path to glib.h to all compilation commands. This is simpler due to the pervasive use of static_library, and was grandfathered in from the previous Make-based build system. Until Meson 0.63 the only way to do this was to detect glib in configure and use add_project_arguments, but now it is possible to use add_project_dependencies instead. gmodule is detected in a separate variable, with export enabled for modules and disabled for plugin. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18meson: drop unnecessary declare_dependency()Paolo Bonzini1-3/+1
The libvfio_user_dep variable of subprojects/libvfio-user/lib/meson.build is already a dependency, so there is no need to wrap it with another declare_dependency(). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18meson: add more version numbers to the summaryPaolo Bonzini1-6/+10
Whenever declare_dependency is used to add some compile flags or dependent libraries to the outcome of dependency(), the version of the original dependency is dropped in the summary. Make sure that declare_dependency() has a version argument in those cases. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18meson: remove static_kwargsPaolo Bonzini2-132/+85
After static_kwargs has been changed to an empty dictionary, it has no functional effect and can be removed. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18meson: use prefer_static optionPaolo Bonzini4-14/+8
The option is new in Meson 0.63 and removes the need to pass "static: true" to all dependency and find_library invocation. Actually cleaning up the invocations is left for a separate patch. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18meson: require 0.63.0Paolo Bonzini5-4/+4
This version allows cleanups in modinfo collection, but they only work with Ninja 1.9.x and 1.8.x is still supported. It also supports the equivalent of QEMU's --static option to configure. The wheel file is bumped to 0.63.3, the last release in the 0.63 branch. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18meson: regenerate meson-buildoptions.shPaolo Bonzini1-3/+3
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18python: bump some of the dependenciesPaolo Bonzini2-15/+9
The version of pyflakes that is listed in python/tests/minreqs.txt breaks on Python 3.8 with the following message: AttributeError: 'FlakesChecker' object has no attribute 'CONSTANT' Now that we do not support EOL'd Python versions anymore, we can update to newer, fixed versions. It is a good time to do so, before Python packages start dropping support for Python 3.7 as well! The new mypy is also a bit smarter about which packages are actually being used, so remove the now-unnecessary sections from setup.cfg. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-27-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: mark command as requiredPaolo Bonzini1-0/+1
This is only available in Python 3.7+. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-26-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18configure: Add courtesy hint to Python version failure messageJohn Snow1-1/+4
If we begin requiring Python 3.7+, a few platforms are going to need to install an additional Python interpreter package. As a courtesy to the user, suggest the optional package they might need to install. This will hopefully minimize any downtime caused by the change in Python dependency. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230221012456.2607692-3-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20230511035435.734312-25-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18Python: Drop support for Python 3.6Paolo Bonzini6-17/+16
Python 3.6 was EOL 2021-12-31. Newer versions of upstream libraries have begun dropping support for this version and it is becoming more cumbersome to support. Avocado-framework and qemu.qmp each have their own reasons for wanting to drop Python 3.6, but won't until QEMU does. Versions of Python available in our supported build platforms as of today, with optional versions available in parentheses: openSUSE Leap 15.4: 3.6.15 (3.9.10, 3.10.2) CentOS Stream 8: 3.6.8 (3.8.13, 3.9.16) CentOS Stream 9: 3.9.13 Fedora 36: 3.10 Fedora 37: 3.11 Debian 11: 3.9.2 Alpine 3.14, 3.15: 3.9.16 Alpine 3.16, 3.17: 3.10.10 Ubuntu 20.04 LTS: 3.8.10 Ubuntu 22.04 LTS: 3.10.4 NetBSD 9.3: 3.9.13* FreeBSD 12.4: 3.9.16 FreeBSD 13.1: 3.9.16 OpenBSD 7.2: 3.9.16 Note: Our VM tests install 3.9 explicitly for FreeBSD and 3.10 for NetBSD; the default for "python" or "python3" in FreeBSD is 3.9.16. NetBSD does not appear to have a default meta-package, but offers several options, the lowest of which is 3.7.15. "python39" appears to be a pre-requisite to one of the other packages we request in tests/vm/netbsd. pip, ensurepip and other Python essentials are currently only available for Python 3.10 for NetBSD. CentOS and OpenSUSE support parallel installation of multiple Python interpreters, and binaries in /usr/bin will always use Python 3.6. However, the newly introduced support for virtual environments ensures that all build steps that execute QEMU Python code use a single interpreter. Since it is safe to under our supported platform policy, bump our minimum supported version of Python to 3.7. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20230511035435.734312-24-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18configure: add --enable-pypi and --disable-pypiJohn Snow1-1/+20
In the event that there's no vendored source present and no sufficient version of $package can be found, we will attempt to connect to PyPI to install the package if '--disable-pypi' was not passed. This means that PyPI access is "enabled by default", but there are some subtleties that make this action occur much less frequently than you might imagine: (1) While --enable-pypi is the default, vendored source will always be preferred when found, making PyPI a fallback. This should ensure that configure-time venv building "just works" for almost everyone in almost every circumstance. (2) Because meson source is, at time of writing, vendored directly into qemu.git, PyPI will never be used for sourcing meson. (3) Because Sphinx is an optional dependency, if docs are set to "auto", PyPI will not be used to obtain Sphinx source as a fallback and instead docs will be disabled. If PyPI sourcing of sphinx is desired, --enable-docs should be passed to force the lookup. I chose this as the default behavior to avoid adding new internet lookups to a "default" invocation of configure. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-23-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18configure: bootstrap sphinx with mkvenvJohn Snow5-17/+20
When docs are explicitly requested, require Sphinx>=1.6.0. When docs are explicitly disabled, don't bother to check for Sphinx at all. If docs are set to "auto", attempt to locate Sphinx, but continue onward if it wasn't located. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-22-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18configure: move --enable-docs and --disable-docs back to configureJohn Snow1-0/+6
Move this option back from meson into configure for the purposes of using the configuration value to bootstrap Sphinx in different ways based on this value. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-21-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18tests: Use configure-provided pyvenv for testsJohn Snow7-23/+26
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>
2023-05-18qemu.git: drop meson git submoduleJohn Snow2-3/+0
Now that meson is installed from a vendored wheel, we don't need the git submodule anymore. Drop it. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-19-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18configure: use 'mkvenv ensure meson' to bootstrap mesonJohn Snow2-56/+13
This commit changes how we detect and install meson. It notably removes '--meson='. Currently, configure creates a lightweight Python virtual environment unconditionally using the user's configured $python that inherits system packages. Temporarily, we forced the use of meson source present via git submodule or in the release tarball. With this patch, we restore the ability to use a system-provided meson: If Meson is installed in the build venv and meets our minimum version requirements, we will use that Meson. This includes a system provided meson, which would be visible via system-site packages inside the venv. In the event that Meson is installed but *not for the chosen Python interpreter*, not found, or of insufficient version, we will attempt to install Meson from vendored source into the newly created Python virtual environment. This vendored installation replaces both the git submodule and tarball source mechanisms for sourcing meson. As a result of this patch, the Python interpreter we use for both our own build scripts *and* Meson extensions are always known to be the exact same Python. As a further benefit, there will also be a symlink available in the build directory that points to the correct, configured python and can be used by e.g. manual tests to invoke the correct, configured Python unambiguously. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-18-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18python/wheels: add vendored meson packageJohn Snow1-0/+0
In preference to vendoring meson source, vendor a built distributable ("bdist" in python parlance). This has some benefits: (1) We can get rid of a git submodule, (2) Installing built meson into a venv doesn't require any extra dependencies (the python "wheel" package, chiefly.) (3) We don't treat meson any differently than we would any other python package (we install it, end of story, done.) (4) All future tarball *and* developer checkouts will function offline; No git or PyPI connection needed to fetch meson. Note that because mkvenv prefers vendored packages to PyPI, as mkvenv is currently written we will never consult PyPI for meson. (Do keep in mind that your distribution's meson will be preferred above the vendored version, though.) ``` jsnow@scv ~/s/q/python (python-configure-venv)> python3 scripts/vendor.py pip download --dest /home/jsnow/src/qemu/python/wheels --require-hashes -r /tmp/tmpvo5qav7i Collecting meson==0.61.5 Using cached meson-0.61.5-py3-none-any.whl (862 kB) Saved ./wheels/meson-0.61.5-py3-none-any.whl Successfully downloaded meson ``` Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-17-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18configure: create a python venv unconditionallyJohn Snow1-5/+29
This patch changes the configure script so that it always creates and uses a python virtual environment unconditionally. Meson bootstrapping is temporarily altered to force the use of meson from git or vendored source (as packaged in our source tarballs). A subsequent commit restores the use of distribution-vendored Meson. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-16-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18python: add vendor.py utilityJohn Snow1-0/+74
This is a teeny-tiny script that just downloads any packages we want to vendor from PyPI and stores them in qemu.git/python/wheels/. If I'm hit by a meteor, it'll be easy to replicate what I have done in order to udpate the vendored source. We don't really care which python runs it; it exists as a meta-utility with no external dependencies and we won't package or install it. It will be monitored by the linters/type checkers, though; so it's guaranteed safe on python 3.6+. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-15-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18tests/vm: add py310-expat to NetBSDJohn Snow1-0/+1
NetBSD cannot successfully run "ensurepip" without access to the pyexpat module, which NetBSD debundles. Like the Debian patch, it would be strictly faster long term to install pip/setuptools, and I recommend developers at their workstations take that approach instead. For the purposes of a throwaway VM, there's not really a speed difference for who is responsible for installing pip; us (needs py310-pip) or Python (needs py310-expat). Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20230511035435.734312-14-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18tests/vm: Configure netbsd to use Python 3.10John Snow1-0/+1
NetBSD removes some packages from the Python stdlib, but only re-packages them for Python 3.10. Switch to using Python 3.10. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20230511035435.734312-13-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18tests/docker: add python3-venv dependencyJohn Snow4-4/+8
Several debian-based tests need the python3-venv dependency as a consequence of Debian debundling the "ensurepip" module normally included with Python. As mkvenv.py stands as of this commit, Debian requires EITHER: (A) setuptools and pip, or (B) ensurepip mkvenv is a few seconds faster if you have setuptools and pip, so developers should prefer the first requirement. For the purposes of CI, the time-save is a wash; it's only a matter of who is responsible for installing pip and when; the timing is about the same. Arbitrarily, I chose adding ensurepip to the test configuration because it is normally part of the Python stdlib, and always having it allows us a more consistent cross-platform environment. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20230511035435.734312-12-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: work around broken pip installations on Debian 10John Snow1-16/+56
This is a workaround intended for Debian 10, where the debian-patched pip does not function correctly if accessed from within a virtual environment. We don't support Debian 10 as a build platform any longer, though we do still utilize it for our build-tricore-softmmu CI test. It's also possible that this bug might appear on other derivative platforms and this workaround may prove useful. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-11-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: avoid ensurepip if pip is installedJohn Snow1-3/+64
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: use pip's vendored distlib as a fallbackJohn Snow2-3/+40
distlib is usually not installed on Linux distribution, but it is vendored into pip. Because the virtual environment has pip via ensurepip, we can piggy-back on pip's vendored version. This could break if they move our cheese in the future, but the fix would be simply to require distlib. If it is debundled, as it is on msys, it is simply available directly. Signed-off-by: John Snow <jsnow@redhat.com> [Move to toplevel. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: add console script entry point generationJohn Snow2-0/+117
When creating a virtual environment that inherits system packages, script entry points (like "meson", "sphinx-build", etc) are not re-generated with the correct shebang. When you are *inside* of the venv, this is not a problem, but if you are *outside* of it, you will not have a script that engages the virtual environment appropriately. Add a mechanism that generates new entry points for pre-existing packages so that we can use these scripts to run "meson", "sphinx-build", "pip", unambiguously inside the venv. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-9-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: add --diagnose option to explain "ensure" failuresJohn Snow1-1/+169
This is a routine that is designed to print some usable info for human beings back out to the terminal if/when "mkvenv ensure" fails to locate or install a package during configure time, such as meson or sphinx. Since we are requiring that "meson" and "sphinx" are installed to the same Python environment as QEMU is configured to build with, this can produce some surprising failures when things are mismatched. This method is here to try and ease that sting by offering some actionable diagnosis. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-8-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: add ensure subcommandJohn Snow3-3/+145
This command is to be used to add various packages (or ensure they're already present) into the configure-provided venv in a modular fashion. Examples: mkvenv ensure --online --dir "${source_dir}/python/wheels/" "meson>=0.61.5" mkvenv ensure --online "sphinx>=1.6.0" mkvenv ensure "qemu.qmp==0.0.2" It's designed to look for packages in three places, in order: (1) In system packages, if the version installed is already good enough. This way your distribution-provided meson, sphinx, etc are always used as first preference. (2) In a vendored packages directory. Here I am suggesting qemu.git/python/wheels/ as that directory. This is intended to serve as a replacement for vendoring the meson source for QEMU tarballs. It is also highly likely to be extremely useful for packaging the "qemu.qmp" package in source distributions for platforms that do not yet package qemu.qmp separately. (3) Online, via PyPI, ***only when "--online" is passed***. This is only ever used as a fallback if the first two sources do not have an appropriate package that meets the requirement. The ability to build QEMU and run tests *completely offline* is not impinged. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-7-jsnow@redhat.com> [Use distlib to lookup distributions. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: add nested venv workaroundJohn Snow1-5/+86
Python virtual environments do not typically nest; they may inherit from the top-level system packages or not at all. For our purposes, it would be convenient to emulate "nested" virtual environments to allow callers of the configure script to install specific versions of python utilities in order to test build system features, utility version compatibility, etc. While it is possible to install packages into the system environment (say, by using the --user flag), it's nicer to install test packages into a totally isolated environment instead. As detailed in https://www.qemu.org/2023/03/24/python/, Emulate a nested venv environment by using .pth files installed into the site-packages folder that points to the parent environment when appropriate. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-6-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18mkvenv: add better error message for broken or missing ensurepipJohn Snow1-0/+37
Debian debundles ensurepip for python; NetBSD debundles pyexpat but ensurepip needs pyexpat. Try our best to offer a helpful error message instead of just failing catastrophically. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-5-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18python: add mkvenv.pyJohn Snow6-0/+260
This script will be responsible for building a lightweight Python virtual environment at configure time. It works with Python 3.6 or newer. It has been designed to: - work *offline*, no PyPI required. - work *quickly*, The fast path is only ~65ms on my machine. - work *robustly*, with multiple fallbacks to keep things working. - work *cooperatively*, using system packages where possible. (You can use your distro's meson, no problem.) Due to its unique position in the build chain, it exists outside of the installable python packages in-tree and *must* be runnable without any third party dependencies. Under normal circumstances, the only dependency required to execute this script is Python 3.6+ itself. The script is *faster* by several seconds when setuptools and pip are installed in the host environment, which is probably the case for a typical multi-purpose developer workstation. In the event that pip/setuptools are missing or not usable, additional dependencies may be required on some distributions which remove certain Python stdlib modules to package them separately: - Debian may require python3-venv to provide "ensurepip" - NetBSD may require py310-expat to provide "pyexpat" * (* Or whichever version is current for NetBSD.) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-4-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18python: update pylint configurationJohn Snow1-0/+1
Pylint 2.17.x decided that SocketAddrT was a bad name for a Type Alias for some reason. Sure, fine, whatever. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20230511035435.734312-3-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18python: shut up "pip install" during "make check-minreqs"Paolo Bonzini1-3/+6
"make check-minreqs" runs pip without the --disable-pip-version-check option, which causes the obnoxious "A new release of pip available" message. Recent versions of pip also complain that some of the dependencies in our virtual environment rely on "setup.py install" instead of providing a pyproject.toml file; apparently it is deprecated to install them directly from pip instead of letting the "wheel" package take care of them. So, install "wheel" in the virtual environment. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20230511035435.734312-2-jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18make: clean after distclean deletes source filesSteve Sistare1-4/+2
Run 'make distclean' in a tree, and GNUmakefile is removed. But, GNUmakefile is where we change directory to build. Run 'make distclean' or 'make clean' again, and Makefile applies the clean actions, such as this one, at the top level of the tree. For example, it removes the .d source files in 'meson/test cases/d/*/*.d'. find . \( -name '*.so' -o -name '*.dll' -o \ -name '*.[oda]' -o -name '*.gcno' \) -type f \ ! -path ./roms/edk2/ArmPkg/Library/GccLto/liblto-aarch64.a \ ! -path ./roms/edk2/ArmPkg/Library/GccLto/liblto-arm.a \ -exec rm {} + To fix, remove clean and distclean from UNCHECKED_GOALS, so those targets are "checked", meaning that configure must be run before make. However, the check action does not trigger, because clean does not depend on config-host.mak, so change the action to simply throw an error. Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Message-Id: <1681909700-94095-1-git-send-email-steven.sistare@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18scsi-generic: fix buffer overflow on block limits inquiryPaolo Bonzini1-5/+9
Using linux 6.x guest, at boot time, an inquiry on a scsi-generic device makes qemu crash. This is caused by a buffer overflow when scsi-generic patches the block limits VPD page. Do the operations on a temporary on-stack buffer that is guaranteed to be large enough. Reported-by: Théo Maillart <tmaillart@freebox.fr> Analyzed-by: Théo Maillart <tmaillart@freebox.fr> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18coverity: the definitive COMPONENTS.md updatePaolo Bonzini1-15/+30
The ordering here tries to be logical and matches the one in the website. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18tcg: round-robin: do not use mb_read for rr_current_cpuPaolo Bonzini1-4/+7
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18kvm: Enable dirty ring for arm64Gavin Shan1-2/+21
arm64 has different capability from x86 to enable the dirty ring, which is KVM_CAP_DIRTY_LOG_RING_ACQ_REL. Besides, arm64 also needs the backup bitmap extension (KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP) when 'kvm-arm-gicv3' or 'arm-its-kvm' device is enabled. Here the extension is always enabled and the unnecessary overhead to do the last stage of dirty log synchronization when those two devices aren't used is introduced, but the overhead should be very small and acceptable. The benefit is cover future cases where those two devices are used without modifying the code. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Tested-by: Zhenyu Zhang <zhenyzha@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20230509022122.20888-5-gshan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18kvm: Add helper kvm_dirty_ring_init()Gavin Shan1-29/+47
Due to multiple capabilities associated with the dirty ring for different architectures: KVM_CAP_DIRTY_{LOG_RING, LOG_RING_ACQ_REL} for x86 and arm64 separately. There will be more to be done in order to support the dirty ring for arm64. Lets add helper kvm_dirty_ring_init() to enable the dirty ring. With this, the code looks a bit clean. No functional change intended. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Zhenyu Zhang <zhenyzha@redhat.com> Message-Id: <20230509022122.20888-4-gshan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18kvm: Synchronize the backup bitmap in the last stageGavin Shan2-0/+12
In the last stage of live migration or memory slot removal, the backup bitmap needs to be synchronized when it has been enabled. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Zhenyu Zhang <zhenyzha@redhat.com> Message-Id: <20230509022122.20888-3-gshan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18migration: Add last stage indicator to global dirty logGavin Shan5-20/+25
The global dirty log synchronization is used when KVM and dirty ring are enabled. There is a particularity for ARM64 where the backup bitmap is used to track dirty pages in non-running-vcpu situations. It means the dirty ring works with the combination of ring buffer and backup bitmap. The dirty bits in the backup bitmap needs to collected in the last stage of live migration. In order to identify the last stage of live migration and pass it down, an extra parameter is added to the relevant functions and callbacks. This last stage indicator isn't used until the dirty ring is enabled in the subsequent patches. No functional change intended. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Zhenyu Zhang <zhenyzha@redhat.com> Message-Id: <20230509022122.20888-2-gshan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18meson: Pass -j option to sphinxFabiano Rosas4-0/+26
Save a bit of build time by passing the number of jobs option to sphinx. We cannot use the -j option from make because meson does not support setting build time parameters for custom targets. Use nproc instead or the equivalent sphinx option "-j auto", if that is available (version >=1.7.0). Also make sure our plugins support parallelism and report it properly to sphinx. Particularly, implement the merge_domaindata method in DBusDomain that is used to merge in data from other subprocesses. Tested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Message-Id: <20230503203947.3417-2-farosas@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18target/i386: Fix exception classes for MOVNTPS/MOVNTPD.Ricky Zhou1-2/+3
Before this change, MOVNTPS and MOVNTPD were labeled as Exception Class 4 (only requiring alignment for legacy SSE instructions). This changes them to Exception Class 1 (always requiring memory alignment), as documented in the Intel manual. Message-Id: <20230501111428.95998-3-ricky@rzhou.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18target/i386: Fix exception classes for SSE/AVX instructions.Ricky Zhou1-23/+23
Fix the exception classes for some SSE/AVX instructions to match what is documented in the Intel manual. These changes are expected to have no functional effect on the behavior that qemu implements (primarily >= 16-byte memory alignment checks). For instance, since qemu does not implement the AC flag, there is no difference in behavior between Exception Classes 4 and 5 for instructions where the SSE version only takes <16 byte memory operands. Message-Id: <20230501111428.95998-2-ricky@rzhou.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-18target/i386: Fix and add some comments next to SSE/AVX instructions.Ricky Zhou1-12/+12
Adds some comments describing what instructions correspond to decoding table entries and fixes some existing comments which named the wrong instruction. Message-Id: <20230501111428.95998-1-ricky@rzhou.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.1 at 2025-01-28 14:53:00 +0000