Revision tags: v8.2.4 |
|
#
eef0bae3 |
| 30-Apr-2024 |
Fabiano Rosas <farosas@suse.de> |
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases have passed so now it's time to remove it.
Deprecation commit 66db46ca83 ("migration: Deprecate block migration").
Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
show more ...
|
Revision tags: v8.2.4 |
|
#
eef0bae3 |
| 30-Apr-2024 |
Fabiano Rosas <farosas@suse.de> |
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases have passed so now it's time to remove it.
Deprecation commit 66db46ca83 ("migration: Deprecate block migration").
Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
show more ...
|
Revision tags: v8.2.4 |
|
#
eef0bae3 |
| 30-Apr-2024 |
Fabiano Rosas <farosas@suse.de> |
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases have passed so now it's time to remove it.
Deprecation commit 66db46ca83 ("migration: Deprecate block migration").
Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
show more ...
|
Revision tags: v8.2.4 |
|
#
eef0bae3 |
| 30-Apr-2024 |
Fabiano Rosas <farosas@suse.de> |
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases have passed so now it's time to remove it.
Deprecation commit 66db46ca83 ("migration: Deprecate block migration").
Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
show more ...
|
Revision tags: v8.2.4 |
|
#
eef0bae3 |
| 30-Apr-2024 |
Fabiano Rosas <farosas@suse.de> |
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases
migration: Remove block migration
The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases have passed so now it's time to remove it.
Deprecation commit 66db46ca83 ("migration: Deprecate block migration").
Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
show more ...
|
Revision tags: v8.2.3, v7.2.11, v9.0.0, v9.0.0-rc4, v9.0.0-rc3, v9.0.0-rc2, v9.0.0-rc1, v9.0.0-rc0 |
|
#
1f2355f5 |
| 12-Mar-2024 |
Ilya Leoshkevich <iii@linux.ibm.com> |
meson: Make DEBUG_REMAP a meson option
Currently DEBUG_REMAP is a macro that needs to be manually #defined to be activated, which makes it hard to have separate build directories dedicated to testin
meson: Make DEBUG_REMAP a meson option
Currently DEBUG_REMAP is a macro that needs to be manually #defined to be activated, which makes it hard to have separate build directories dedicated to testing the code with it. Promote it to a meson option.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20240312002402.14344-1-iii@linux.ibm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
#
1dfd42c4 |
| 28-Mar-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/rdma: Remove deprecated pvrdma device and rdmacm-mux helper
The whole RDMA subsystem was deprecated in commit e9a54265f5 ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem") released i
hw/rdma: Remove deprecated pvrdma device and rdmacm-mux helper
The whole RDMA subsystem was deprecated in commit e9a54265f5 ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem") released in v8.2.
Remove: - PVRDMA device - generated vmw_pvrdma/ directory from linux-headers - rdmacm-mux tool from contrib/
Cc: Yuval Shaia <yuval.shaia.ml@gmail.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240328130255.52257-2-philmd@linaro.org>
show more ...
|
Revision tags: v8.2.2, v7.2.10, v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0 |
|
#
2bbc4875 |
| 13-Dec-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
meson: fix type of "relocatable" option
Since the option is of boolean type, the default value should be a boolean rather than a string.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
Revision tags: v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0, v8.1.2, v8.1.1, v7.2.6, v8.0.5 |
|
#
cca15756 |
| 30-Aug-2023 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
build-sys: add a "pixman" feature
For now, pixman is mandatory, but we set config_host.h and Kconfig. Once compilation is fixed, "pixman" will become actually optional.
Signed-off-by: Marc-André Lu
build-sys: add a "pixman" feature
For now, pixman is mandatory, but we set config_host.h and Kconfig. Once compilation is fixed, "pixman" will become actually optional.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0, v8.0.3, v7.2.4 |
|
#
0d9e8c0b |
| 12-Jun-2023 |
Maciej S. Szmigiero <maciej.szmigiero@oracle.com> |
Add Hyper-V Dynamic Memory Protocol driver (hv-balloon) base
This driver is like virtio-balloon on steroids: it allows both changing the guest memory allocation via ballooning and (in the next patch
Add Hyper-V Dynamic Memory Protocol driver (hv-balloon) base
This driver is like virtio-balloon on steroids: it allows both changing the guest memory allocation via ballooning and (in the next patch) inserting pieces of extra RAM into it on demand from a provided memory backend.
The actual resizing is done via ballooning interface (for example, via the "balloon" HMP command). This includes resizing the guest past its boot size - that is, hot-adding additional memory in granularity limited only by the guest alignment requirements, as provided by the next patch.
In contrast with ACPI DIMM hotplug where one can only request to unplug a whole DIMM stick this driver allows removing memory from guest in single page (4k) units via ballooning.
After a VM reboot the guest is back to its original (boot) size.
In the future, the guest boot memory size might be changed on reboot instead, taking into account the effective size that VM had before that reboot (much like Hyper-V does).
For performance reasons, the guest-released memory is tracked in a few range trees, as a series of (start, count) ranges. Each time a new page range is inserted into such tree its neighbors are checked as candidates for possible merging with it.
Besides performance reasons, the Dynamic Memory protocol itself uses page ranges as the data structure in its messages, so relevant pages need to be merged into such ranges anyway.
One has to be careful when tracking the guest-released pages, since the guest can maliciously report returning pages outside its current address space, which later clash with the address range of newly added memory. Similarly, the guest can report freeing the same page twice.
The above design results in much better ballooning performance than when using virtio-balloon with the same guest: 230 GB / minute with this driver versus 70 GB / minute with virtio-balloon.
During a ballooning operation most of time is spent waiting for the guest to come up with newly freed page ranges, processing the received ranges on the host side (in QEMU and KVM) is nearly instantaneous.
The unballoon operation is also pretty much instantaneous: thanks to the merging of the ballooned out page ranges 200 GB of memory can be returned to the guest in about 1 second. With virtio-balloon this operation takes about 2.5 minutes.
These tests were done against a Windows Server 2019 guest running on a Xeon E5-2699, after dirtying the whole memory inside guest before each balloon operation.
Using a range tree instead of a bitmap to track the removed memory also means that the solution scales well with the guest size: even a 1 TB range takes just a few bytes of such metadata.
Since the required GTree operations aren't present in every Glib version a check for them was added to the meson build script, together with new "--enable-hv-balloon" and "--disable-hv-balloon" configure arguments. If these GTree operations are missing in the system's Glib version this driver will be skipped during QEMU build.
An optional "status-report=on" device parameter requests memory status events from the guest (typically sent every second), which allow the host to learn both the guest memory available and the guest memory in use counts.
Following commits will add support for their external emission as "HV_BALLOON_STATUS_REPORT" QMP events.
The driver is named hv-balloon since the Linux kernel client driver for the Dynamic Memory Protocol is named as such and to follow the naming pattern established by the virtio-balloon driver. The whole protocol runs over Hyper-V VMBus.
The driver was tested against Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019 guests and obeys the guest alignment requirements reported to the host via DM_CAPABILITIES_REPORT message.
Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
show more ...
|
Revision tags: v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0, v8.0.3, v7.2.4 |
|
#
0d9e8c0b |
| 12-Jun-2023 |
Maciej S. Szmigiero <maciej.szmigiero@oracle.com> |
Add Hyper-V Dynamic Memory Protocol driver (hv-balloon) base
This driver is like virtio-balloon on steroids: it allows both changing the guest memory allocation via ballooning and (in the next patch
Add Hyper-V Dynamic Memory Protocol driver (hv-balloon) base
This driver is like virtio-balloon on steroids: it allows both changing the guest memory allocation via ballooning and (in the next patch) inserting pieces of extra RAM into it on demand from a provided memory backend.
The actual resizing is done via ballooning interface (for example, via the "balloon" HMP command). This includes resizing the guest past its boot size - that is, hot-adding additional memory in granularity limited only by the guest alignment requirements, as provided by the next patch.
In contrast with ACPI DIMM hotplug where one can only request to unplug a whole DIMM stick this driver allows removing memory from guest in single page (4k) units via ballooning.
After a VM reboot the guest is back to its original (boot) size.
In the future, the guest boot memory size might be changed on reboot instead, taking into account the effective size that VM had before that reboot (much like Hyper-V does).
For performance reasons, the guest-released memory is tracked in a few range trees, as a series of (start, count) ranges. Each time a new page range is inserted into such tree its neighbors are checked as candidates for possible merging with it.
Besides performance reasons, the Dynamic Memory protocol itself uses page ranges as the data structure in its messages, so relevant pages need to be merged into such ranges anyway.
One has to be careful when tracking the guest-released pages, since the guest can maliciously report returning pages outside its current address space, which later clash with the address range of newly added memory. Similarly, the guest can report freeing the same page twice.
The above design results in much better ballooning performance than when using virtio-balloon with the same guest: 230 GB / minute with this driver versus 70 GB / minute with virtio-balloon.
During a ballooning operation most of time is spent waiting for the guest to come up with newly freed page ranges, processing the received ranges on the host side (in QEMU and KVM) is nearly instantaneous.
The unballoon operation is also pretty much instantaneous: thanks to the merging of the ballooned out page ranges 200 GB of memory can be returned to the guest in about 1 second. With virtio-balloon this operation takes about 2.5 minutes.
These tests were done against a Windows Server 2019 guest running on a Xeon E5-2699, after dirtying the whole memory inside guest before each balloon operation.
Using a range tree instead of a bitmap to track the removed memory also means that the solution scales well with the guest size: even a 1 TB range takes just a few bytes of such metadata.
Since the required GTree operations aren't present in every Glib version a check for them was added to the meson build script, together with new "--enable-hv-balloon" and "--disable-hv-balloon" configure arguments. If these GTree operations are missing in the system's Glib version this driver will be skipped during QEMU build.
An optional "status-report=on" device parameter requests memory status events from the guest (typically sent every second), which allow the host to learn both the guest memory available and the guest memory in use counts.
Following commits will add support for their external emission as "HV_BALLOON_STATUS_REPORT" QMP events.
The driver is named hv-balloon since the Linux kernel client driver for the Dynamic Memory Protocol is named as such and to follow the naming pattern established by the virtio-balloon driver. The whole protocol runs over Hyper-V VMBus.
The driver was tested against Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019 guests and obeys the guest alignment requirements reported to the host via DM_CAPABILITIES_REPORT message.
Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
show more ...
|
#
e20d68aa |
| 09-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
configure, meson: use command line options to configure qemu-ga
Preserve the functionality of the environment variables, but allow using the command line instead.
Signed-off-by: Paolo Bonzini <pbon
configure, meson: use command line options to configure qemu-ga
Preserve the functionality of the environment variables, but allow using the command line instead.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
655e2a77 |
| 05-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's install has been re
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's install has been relocatable: if you move qemu-system-x86_64 from /usr/bin to /home/username/bin, it will start looking for firmware in /home/username/share/qemu. Previously, you would get a non-relocatable install where the moved QEMU will keep looking for firmware in /usr/share/qemu.
Windows almost always wants relocatable installs, and in fact that is why QEMU 5.2 introduced relocatability in the first place. However, newfangled distribution mechanisms such as AppImage (https://docs.appimage.org/reference/best-practices.html), and possibly NixOS, also dislike using at runtime the absolute paths that were established at build time.
On POSIX systems you almost never care; if you do, your usecase dictates which one is desirable, so there's no single answer. Obviously relocatability works fine most of the time, because not many people have complained about QEMU's switch to relocatable install, and that's why until now there was no way to disable relocatability.
But a non-relocatable, non-modular binary can help if you want to do experiments with old firmware and new QEMU or vice versa (because you can just upgrade/downgrade the firmware package, and use rpm2cpio or similar to extract the QEMU binaries outside /usr), so allow both. This patch allows one to build a non-relocatable install using a new option to configure. Why? Because it's not too hard, and because it helps the user double check the relocatability of their install.
Note that the same code that handles relocation also lets you run QEMU from the build tree and pick e.g. firmware files from the source tree transparently. Therefore that part remains active with this patch, even if you configure with --disable-relocatable.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
e20d68aa |
| 09-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
configure, meson: use command line options to configure qemu-ga
Preserve the functionality of the environment variables, but allow using the command line instead.
Signed-off-by: Paolo Bonzini <pbon
configure, meson: use command line options to configure qemu-ga
Preserve the functionality of the environment variables, but allow using the command line instead.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
655e2a77 |
| 05-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's install has been re
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's install has been relocatable: if you move qemu-system-x86_64 from /usr/bin to /home/username/bin, it will start looking for firmware in /home/username/share/qemu. Previously, you would get a non-relocatable install where the moved QEMU will keep looking for firmware in /usr/share/qemu.
Windows almost always wants relocatable installs, and in fact that is why QEMU 5.2 introduced relocatability in the first place. However, newfangled distribution mechanisms such as AppImage (https://docs.appimage.org/reference/best-practices.html), and possibly NixOS, also dislike using at runtime the absolute paths that were established at build time.
On POSIX systems you almost never care; if you do, your usecase dictates which one is desirable, so there's no single answer. Obviously relocatability works fine most of the time, because not many people have complained about QEMU's switch to relocatable install, and that's why until now there was no way to disable relocatability.
But a non-relocatable, non-modular binary can help if you want to do experiments with old firmware and new QEMU or vice versa (because you can just upgrade/downgrade the firmware package, and use rpm2cpio or similar to extract the QEMU binaries outside /usr), so allow both. This patch allows one to build a non-relocatable install using a new option to configure. Why? Because it's not too hard, and because it helps the user double check the relocatability of their install.
Note that the same code that handles relocation also lets you run QEMU from the build tree and pick e.g. firmware files from the source tree transparently. Therefore that part remains active with this patch, even if you configure with --disable-relocatable.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
e20d68aa |
| 09-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
configure, meson: use command line options to configure qemu-ga
Preserve the functionality of the environment variables, but allow using the command line instead.
Signed-off-by: Paolo Bonzini <pbon
configure, meson: use command line options to configure qemu-ga
Preserve the functionality of the environment variables, but allow using the command line instead.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
655e2a77 |
| 05-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's install has been re
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's install has been relocatable: if you move qemu-system-x86_64 from /usr/bin to /home/username/bin, it will start looking for firmware in /home/username/share/qemu. Previously, you would get a non-relocatable install where the moved QEMU will keep looking for firmware in /usr/share/qemu.
Windows almost always wants relocatable installs, and in fact that is why QEMU 5.2 introduced relocatability in the first place. However, newfangled distribution mechanisms such as AppImage (https://docs.appimage.org/reference/best-practices.html), and possibly NixOS, also dislike using at runtime the absolute paths that were established at build time.
On POSIX systems you almost never care; if you do, your usecase dictates which one is desirable, so there's no single answer. Obviously relocatability works fine most of the time, because not many people have complained about QEMU's switch to relocatable install, and that's why until now there was no way to disable relocatability.
But a non-relocatable, non-modular binary can help if you want to do experiments with old firmware and new QEMU or vice versa (because you can just upgrade/downgrade the firmware package, and use rpm2cpio or similar to extract the QEMU binaries outside /usr), so allow both. This patch allows one to build a non-relocatable install using a new option to configure. Why? Because it's not too hard, and because it helps the user double check the relocatability of their install.
Note that the same code that handles relocation also lets you run QEMU from the build tree and pick e.g. firmware files from the source tree transparently. Therefore that part remains active with this patch, even if you configure with --disable-relocatable.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
e20d68aa |
| 09-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
configure, meson: use command line options to configure qemu-ga
Preserve the functionality of the environment variables, but allow using the command line instead.
Signed-off-by: Paolo Bonzini <pbon
configure, meson: use command line options to configure qemu-ga
Preserve the functionality of the environment variables, but allow using the command line instead.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
655e2a77 |
| 05-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's install has been re
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's install has been relocatable: if you move qemu-system-x86_64 from /usr/bin to /home/username/bin, it will start looking for firmware in /home/username/share/qemu. Previously, you would get a non-relocatable install where the moved QEMU will keep looking for firmware in /usr/share/qemu.
Windows almost always wants relocatable installs, and in fact that is why QEMU 5.2 introduced relocatability in the first place. However, newfangled distribution mechanisms such as AppImage (https://docs.appimage.org/reference/best-practices.html), and possibly NixOS, also dislike using at runtime the absolute paths that were established at build time.
On POSIX systems you almost never care; if you do, your usecase dictates which one is desirable, so there's no single answer. Obviously relocatability works fine most of the time, because not many people have complained about QEMU's switch to relocatable install, and that's why until now there was no way to disable relocatability.
But a non-relocatable, non-modular binary can help if you want to do experiments with old firmware and new QEMU or vice versa (because you can just upgrade/downgrade the firmware package, and use rpm2cpio or similar to extract the QEMU binaries outside /usr), so allow both. This patch allows one to build a non-relocatable install using a new option to configure. Why? Because it's not too hard, and because it helps the user double check the relocatability of their install.
Note that the same code that handles relocation also lets you run QEMU from the build tree and pick e.g. firmware files from the source tree transparently. Therefore that part remains active with this patch, even if you configure with --disable-relocatable.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, 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 |
|
#
cd9adbef |
| 21-Mar-2023 |
Gurchetan Singh <gurchetansingh@chromium.org> |
gfxstream + rutabaga: meson support
- Add meson detection of rutabaga_gfx - Build virtio-gpu-rutabaga.c + associated vga/pci files when present
Signed-off-by: Gurchetan Singh <gurchetansingh@chro
gfxstream + rutabaga: meson support
- Add meson detection of rutabaga_gfx - Build virtio-gpu-rutabaga.c + associated vga/pci files when present
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Alyssa Ross <hi@alyssa.is> Tested-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Antonio Caggiano <quic_acaggian@quicinc.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, 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 |
|
#
cd9adbef |
| 21-Mar-2023 |
Gurchetan Singh <gurchetansingh@chromium.org> |
gfxstream + rutabaga: meson support
- Add meson detection of rutabaga_gfx - Build virtio-gpu-rutabaga.c + associated vga/pci files when present
Signed-off-by: Gurchetan Singh <gurchetansingh@chro
gfxstream + rutabaga: meson support
- Add meson detection of rutabaga_gfx - Build virtio-gpu-rutabaga.c + associated vga/pci files when present
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Alyssa Ross <hi@alyssa.is> Tested-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Antonio Caggiano <quic_acaggian@quicinc.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
show more ...
|
#
a0bc5997 |
| 30-Sep-2023 |
Richard Henderson <richard.henderson@linaro.org> |
build: Remove --enable-gprof
This build option has been deprecated since 8.0. Remove all CONFIG_GPROF code that depends on that, including one errant check using TARGET_GPROF.
Acked-by: Alex Bennée
build: Remove --enable-gprof
This build option has been deprecated since 8.0. Remove all CONFIG_GPROF code that depends on that, including one errant check using TARGET_GPROF.
Acked-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
#
a0bc5997 |
| 30-Sep-2023 |
Richard Henderson <richard.henderson@linaro.org> |
build: Remove --enable-gprof
This build option has been deprecated since 8.0. Remove all CONFIG_GPROF code that depends on that, including one errant check using TARGET_GPROF.
Acked-by: Alex Bennée
build: Remove --enable-gprof
This build option has been deprecated since 8.0. Remove all CONFIG_GPROF code that depends on that, including one errant check using TARGET_GPROF.
Acked-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
#
a0bc5997 |
| 30-Sep-2023 |
Richard Henderson <richard.henderson@linaro.org> |
build: Remove --enable-gprof
This build option has been deprecated since 8.0. Remove all CONFIG_GPROF code that depends on that, including one errant check using TARGET_GPROF.
Acked-by: Alex Bennée
build: Remove --enable-gprof
This build option has been deprecated since 8.0. Remove all CONFIG_GPROF code that depends on that, including one errant check using TARGET_GPROF.
Acked-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
#
c64023b0 |
| 24-Aug-2023 |
Thomas Huth <thuth@redhat.com> |
meson.build: Make keyutils independent from keyring
Commit 0db0fbb5cf ("Add conditional dependency for libkeyutils") tried to provide a possibility for the user to disable keyutils if not required b
meson.build: Make keyutils independent from keyring
Commit 0db0fbb5cf ("Add conditional dependency for libkeyutils") tried to provide a possibility for the user to disable keyutils if not required by makeing it depend on the keyring feature. This looked reasonable at a first glance (the unit test in tests/unit/ needs both), but the condition in meson.build fails if the feature is meant to be detected automatically, and there is also another spot in backends/meson.build where keyutils is used independently from keyring. So let's remove the dependency on keyring again and introduce a proper meson build option instead.
Cc: qemu-stable@nongnu.org Fixes: 0db0fbb5cf ("Add conditional dependency for libkeyutils") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1842 Message-ID: <20230824094208.255279-1-thuth@redhat.com> Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|