aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2023-10-07cpu: Correct invalid mentions of 'softmmu' by 'system-mode'Philippe Mathieu-Daudé1-2/+2
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231004090629.37473-4-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-05Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Stefan Hajnoczi46-370/+1250
into staging virtio,pci: features, cleanups vdpa: shadow vq vlan support net migration with cvq cxl: support emulating 4 HDM decoders serial number extended capability virtio: hared dma-buf Fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (53 commits) libvhost-user: handle shared_object msg vhost-user: add shared_object msg hw/display: introduce virtio-dmabuf util/uuid: add a hash function virtio: remove unused next argument from virtqueue_split_read_next_desc() virtio: remove unnecessary thread fence while reading next descriptor virtio: use shadow_avail_idx while checking number of heads libvhost-user.c: add assertion to vu_message_read_default pcie_sriov: unregister_vfs(): fix error path hw/i386/pc: improve physical address space bound check for 32-bit x86 systems amd_iommu: Fix APIC address check vdpa net: follow VirtIO initialization properly at cvq isolation probing vdpa net: stop probing if cannot set features vdpa net: fix error message setting virtio status hw/pci-bridge/cxl-upstream: Add serial number extended capability support hw/cxl: Support 4 HDM decoders at all levels of topology hw/cxl: Fix and use same calculation for HDM decoder block size everywhere hw/cxl: Add utility functions decoder interleave ways and target count. hw/cxl: Push cxl_decoder_count_enc() and cxl_decode_ig() into .c vdpa net: zero vhost_vdpa iova_tree pointer at cleanup ... Conflicts: hw/core/machine.c Context conflict with commit 314e0a84cd5d ("hw/core: remove needless includes") because it removed an adjacent #include.
2023-10-05Merge tag 'pull-tcg-20231004' of https://gitlab.com/rth7680/qemu into stagingStefan Hajnoczi7-15/+15
accel: Introduce AccelClass::cpu_common_[un]realize accel: Target agnostic code movement accel/tcg: Cleanups to use CPUState instead of CPUArchState accel/tcg: Move CPUNegativeOffsetState into CPUState tcg: Split out tcg init functions to tcg/startup.h linux-user/hppa: Fix struct target_sigcontext layout build: Remove --enable-gprof # -----BEGIN PGP SIGNATURE----- # # iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmUdsL4dHHJpY2hhcmQu # aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV/iYggAvDJEyMCAXSSH97BA # wZT/2D/MFIhOMk6xrQRnrXfrG70N0iVKz44jl9j7k1D+9BOHcso//DDJH3c96k9A # MgDb6W2bsWvC15/Qw6BALf5bb/II0MJuCcQvj3CNX5lNkXAWhwIOBhsZx7V9ST1+ # rihN4nowpRWdV5GeCjDGaJW455Y1gc96hICYHy6Eqw1cUgUFt9vm5aYU3FHlat29 # sYRaVYKUL2hRUPPNcPiPq0AaJ8wN6/s8gT+V1UvTzkhHqskoM4ZU89RchuXVoq1h # SvhKElyULMRzM7thWtpW8qYJPj4mxZsKArESvHjsunGD6KEz3Fh1sy6EKRcdmpG/ # II1vkg== # =k2Io # -----END PGP SIGNATURE----- # gpg: Signature made Wed 04 Oct 2023 14:36:46 EDT # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full] # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * tag 'pull-tcg-20231004' of https://gitlab.com/rth7680/qemu: (47 commits) tcg/loongarch64: Fix buid error tests/avocado: Re-enable MIPS Malta tests (GitLab issue #1884 fixed) build: Remove --enable-gprof linux-user/hppa: Fix struct target_sigcontext layout tcg: Split out tcg init functions to tcg/startup.h tcg: Remove argument to tcg_prologue_init accel/tcg: Make cpu-exec-common.c a target agnostic unit accel/tcg: Make icount.o a target agnostic unit accel/tcg: Make monitor.c a target-agnostic unit accel/tcg: Rename target-specific 'internal.h' -> 'internal-target.h' exec: Rename target specific page-vary.c -> page-vary-target.c exec: Rename cpu.c -> cpu-target.c accel: Rename accel-common.c -> accel-target.c accel: Make accel-blocker.o target agnostic accel/tcg: Restrict dump_exec_info() declaration exec: Move cpu_loop_foo() target agnostic functions to 'cpu-common.h' exec: Make EXCP_FOO definitions target agnostic accel/tcg: move ld/st helpers to ldst_common.c.inc accel/tcg: Unify user and softmmu do_[st|ld]*_mmu() accel/tcg: Remove env_tlb() ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-04vhost-user: add shared_object msgAlbert Esteve1-12/+155
Add three new vhost-user protocol `VHOST_USER_BACKEND_SHARED_OBJECT_* messages`. These new messages are sent from vhost-user back-ends to interact with the virtio-dmabuf table in order to add or remove themselves as virtio exporters, or lookup for virtio dma-buf shared objects. The action taken in the front-end depends on the type stored in the virtio shared object hash table. When the table holds a pointer to a vhost backend for a given UUID, the front-end sends a VHOST_USER_GET_SHARED_OBJECT to the backend holding the shared object. The messages can only be sent after successfully negotiating a new VHOST_USER_PROTOCOL_F_SHARED_OBJECT vhost-user protocol feature bit. Finally, refactor code to send response message so that all common parts both for the common REPLY_ACK case, and other data responses, can call it and avoid code repetition. Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-4-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/display: introduce virtio-dmabufAlbert Esteve2-0/+139
This API manages objects (in this iteration, dmabuf fds) that can be shared along different virtio devices, associated to a UUID. The API allows the different devices to add, remove and/or retrieve the objects by simply invoking the public functions that reside in the virtio-dmabuf file. For vhost backends, the API stores the pointer to the backend holding the object. Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-3-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio: remove unused next argument from virtqueue_split_read_next_desc()Ilya Maximets1-10/+8
The 'next' was converted from a local variable to an output parameter in commit: 412e0e81b174 ("virtio: handle virtqueue_read_next_desc() errors") But all the actual uses of the 'i/next' as an output were removed a few months prior in commit: aa570d6fb6bd ("virtio: combine the read of a descriptor") Remove the unused argument to simplify the code. Also, adding a comment to the function to describe what it is actually doing, as it is not obvious that the 'desc' is both an input and an output argument. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Message-Id: <20230927140016.2317404-3-i.maximets@ovn.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio: remove unnecessary thread fence while reading next descriptorIlya Maximets1-2/+0
It was supposed to be a compiler barrier and it was a compiler barrier initially called 'wmb' when virtio core support was introduced. Later all the instances of 'wmb' were switched to smp_wmb to fix memory ordering issues on non-x86 platforms. However, this one doesn't need to be an actual barrier, as its only purpose was to ensure that the value is not read twice. And since commit aa570d6fb6bd ("virtio: combine the read of a descriptor") there is no need for a barrier at all, since we're no longer reading guest memory here, but accessing a local structure. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Message-Id: <20230927140016.2317404-2-i.maximets@ovn.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio: use shadow_avail_idx while checking number of headsIlya Maximets1-3/+15
We do not need the most up to date number of heads, we only want to know if there is at least one. Use shadow variable as long as it is not equal to the last available index checked. This avoids expensive qatomic dereference of the RCU-protected memory region cache as well as the memory access itself. The change improves performance of the af-xdp network backend by 2-3%. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Message-Id: <20230927135157.2316982-1-i.maximets@ovn.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04pcie_sriov: unregister_vfs(): fix error pathVladimir Sementsov-Ogievskiy1-6/+3
local_err must be NULL before calling object_property_set_bool(), so we must clear it on each iteration. Let's also use more convenient error_reportf_err(). Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20230925194040.68592-8-vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/i386/pc: improve physical address space bound check for 32-bit x86 systemsAni Sinha3-3/+35
32-bit x86 systems do not have a reserved memory for hole64. On those 32-bit systems without PSE36 or PAE CPU features, hotplugging memory devices are not supported by QEMU as QEMU always places hotplugged memory above 4 GiB boundary which is beyond the physical address space of the processor. Linux guests also does not support memory hotplug on those systems. Please see Linux kernel commit b59d02ed08690 ("mm/memory_hotplug: disable the functionality for 32b") for more details. Therefore, the maximum limit of the guest physical address in the absence of additional memory devices effectively coincides with the end of "above 4G memory space" region for 32-bit x86 without PAE/PSE36. When users configure additional memory devices, after properly accounting for the additional device memory region to find the maximum value of the guest physical address, the address will be outside the range of the processor's physical address space. This change adds improvements to take above into consideration. For example, previously this was allowed: $ ./qemu-system-x86_64 -cpu pentium -m size=10G With this change now it is no longer allowed: $ ./qemu-system-x86_64 -cpu pentium -m size=10G qemu-system-x86_64: Address space limit 0xffffffff < 0x2bfffffff phys-bits too low (32) However, the following are allowed since on both cases physical address space of the processor is 36 bits: $ ./qemu-system-x86_64 -cpu pentium2 -m size=10G $ ./qemu-system-x86_64 -cpu pentium,pse36=on -m size=10G For 32-bit, without PAE/PSE36, hotplugging additional memory is no longer allowed. $ ./qemu-system-i386 -m size=1G,maxmem=3G,slots=2 qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32) $ ./qemu-system-i386 -machine q35 -m size=1G,maxmem=3G,slots=2 qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32) A new compatibility flag is introduced to make sure pc_max_used_gpa() keeps returning the old value for machines 8.1 and older. Therefore, the above is still allowed for older machine types in order to support compatibility. Hence, the following still works: $ ./qemu-system-i386 -machine pc-i440fx-8.1 -m size=1G,maxmem=3G,slots=2 $ ./qemu-system-i386 -machine pc-q35-8.1 -m size=1G,maxmem=3G,slots=2 Further, following is also allowed as with PSE36, the processor has 36-bit address space: $ ./qemu-system-i386 -cpu 486,pse36=on -m size=1G,maxmem=3G,slots=2 After calling CPUID with EAX=0x80000001, all AMD64 compliant processors have the longmode-capable-bit turned on in the extended feature flags (bit 29) in EDX. The absence of CPUID longmode can be used to differentiate between 32-bit and 64-bit processors and is the recommended approach. QEMU takes this approach elsewhere (for example, please see x86_cpu_realizefn()), With this change, pc_max_used_gpa() also uses the same method to detect 32-bit processors. Unit tests are modified to not run 32-bit x86 tests that use memory hotplug. Suggested-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20230922160413.165702-1-anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04amd_iommu: Fix APIC address checkAkihiko Odaki2-9/+2
An MSI from I/O APIC may not exactly equal to APIC_DEFAULT_ADDRESS. In fact, Windows 17763.3650 configures I/O APIC to set the dest_mode bit. Cover the range assigned to APIC. Fixes: 577c470f43 ("x86_iommu/amd: Prepare for interrupt remap support") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20230921114612.40671-1-akihiko.odaki@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/pci-bridge/cxl-upstream: Add serial number extended capability supportJonathan Cameron1-2/+13
Will be needed so there is a defined serial number for information queries via the Switch CCI. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913133615.29876-1-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/cxl: Support 4 HDM decoders at all levels of topologyJonathan Cameron3-55/+115
Support these decoders in CXL host bridges (pxb-cxl), CXL Switch USP and CXL Type 3 end points. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913132523.29780-5-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/cxl: Fix and use same calculation for HDM decoder block size everywhereJonathan Cameron3-18/+29
In order to avoid having the size of the per HDM decoder register block repeated in lots of places, create the register definitions for HDM decoder 1 and use the offset between the first registers in HDM decoder 0 and HDM decoder 1 to establish the offset. Calculate in each function as this is more obvious and leads to shorter line lengths than a single #define which would need a long name to be specific enough. Note that the code currently only supports one decoder, so the bugs this fixes don't actually affect anything. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230913132523.29780-4-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/cxl: Add utility functions decoder interleave ways and target count.Jonathan Cameron1-6/+54
As an encoded version of these key configuration parameters is available in a register, provide functions to extract it again so as to avoid the need for duplicating the storage. Whilst here update the _enc() function to include additional values as defined in the CXL 3.0 specification. Whilst they are not currently used in the emulation, they may be in future and it is easier to compare with the specification if all values are covered. Add a spec reference for cxl_interleave_ways_enc() for consistency with the target count equivalent (and because it's nice to know where the magic numbers come from). Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913132523.29780-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/cxl: Push cxl_decoder_count_enc() and cxl_decode_ig() into .cJonathan Cameron1-0/+18
There is no strong justification for keeping these in the header so push them down into the associated cxl-component-utils.c file. Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230913132523.29780-2-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi/core: Trace enable and status registers of GPE separatelyBernhard Beschow2-5/+11
The bit positions of both registers are related. Tracing the registers independently results in the same offsets across these registers which eases debugging. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-9-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi: Trace GPE access in all device models, not just PIIX4Bernhard Beschow3-7/+9
Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-8-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/i386/acpi-build: Determine SMI command port just onceBernhard Beschow1-3/+3
The SMI command port is currently hardcoded by means of the ACPI_PORT_SMI_CMD macro. This hardcoding is Intel specific and doesn't match VIA, for example. There is already the AcpiFadtData::smi_cmd attribute which is used when building the FADT. Let's also use it when building the DSDT which confines SMI command port determination to just one place. This allows it to become a property later, thus resolving the Intel assumption. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-7-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/i386: Remove now redundant TYPE_ACPI_GED_X86Bernhard Beschow3-29/+1
Now that TYPE_ACPI_GED_X86 doesn't assign AcpiDeviceIfClass::madt_cpu any more it is the same as TYPE_ACPI_GED. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-6-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi/acpi_dev_interface: Remove now unused #include "hw/boards.h"Bernhard Beschow4-1/+5
The "hw/boards.h" is unused since the previous commit. Since its removal requires include fixes in various unrelated files to keep the code compiling it has been split in a dedicated commit. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi/acpi_dev_interface: Remove now unused madt_cpu virtual methodBernhard Beschow4-18/+0
This virtual method was always set to the x86-specific pc_madt_cpu_entry(), even in piix4 which is also used in MIPS. The previous changes use pc_madt_cpu_entry() otherwise, so madt_cpu can be dropped. Since pc_madt_cpu_entry() is now only used in x86-specific code, the stub in hw/acpi/acpi-x86-stub can be removed as well. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/acpi/cpu: Have build_cpus_aml() take a build_madt_cpu_fn callbackBernhard Beschow2-8/+4
build_cpus_aml() is architecture independent but needs to create architecture- specific CPU AML. So far this was achieved by using a virtual method from TYPE_ACPI_DEVICE_IF. However, build_cpus_aml() would resolve this interface from global (!) state. This makes it quite incomprehensible where this interface comes from (TYPE_PIIX4_PM?, TYPE_ICH9_LPC_DEVICE?, TYPE_ACPI_GED_X86?) an can lead to crashes when the generic code is ported to new architectures. So far, build_cpus_aml() is only called in architecture-specific code -- and only in x86. We can therefore simply pass pc_madt_cpu_entry() as callback to build_cpus_aml(). This is the same callback that would be used through TYPE_ACPI_DEVICE_IF. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/i386/acpi-build: Use pc_madt_cpu_entry() directlyBernhard Beschow4-9/+5
This is x86-specific code, so there is no advantage in using pc_madt_cpu_entry() behind an architecture-agnostic interface. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230908084234.17642-2-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04accel/tcg: Replace CPUState.env_ptr with cpu_env()Richard Henderson6-12/+12
Reviewed-by: Anton Johansson <anjo@rev.ng> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04Merge tag 'misc-pull-request' of https://gitlab.com/marcandre.lureau/qemu ↵Stefan Hajnoczi3-49/+1
into staging Misc fixes and cleanups # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmUcClAcHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5R5FD/9oeCDGXVzkm52K0DoW # 90N5Blda/3exvnS49TEz+rbIxXcy9IBxEKV3aPesCDw0V7Vxy6ZijPA/aHKzQEeP # DOX+0sELWLFRKvNNuXLxPlZcEQDgXkgqoCKf+0jp5oH7TAL2upezMhIr4XlUwG3v # rKQstpmr0Jm9sjsBTL9uIZCJpzglWk7CIbgAlBjOX6MFz0HAManrhBBuguvSZtrW # wYWrdkBEdTK6ranBvRA3IKi4ux/pmNsCpCtuOVT+WOLjC/wmJIE8+pBzlK9eOdqW # bPaxuu4XK1qao1+z6EyoaUtH/UW50EUInGq7aR2Z31/S1BLxqEpFCCnPAw7RGYZO # VlAuiR2U7K7AHFDfp8fJaUNH8a3Zh2wzpba5cyQ7LqVNRVbDhx65sQZw0pA3pjfi # JG0brIpWldD7auJtZTdCxXcoHWxeyfqqzH3a6GpeZzrRwuuAwxv0+yGF3Y2cMJ7+ # lV9JVcei5M+Acq1UfO4BCC77UpXs4Jl0+zyRq02vOJFnfwcLMQ7VjD2A3e00yodj # F5cPnbacI212ynNm925RNv45svaY1hD2Z8kJRV/15/04m9dRv4WHOOTuF3iwZjt1 # 9gp/p949tcEL/rBbDF+9QZiVHTWurVCQ0ZFnNhVnbKm+Hm5nHk5slc2p+VXQ0KB0 # E2mN1irWzLov0K1YZTfetiXo8A== # =3ol2 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 03 Oct 2023 08:34:24 EDT # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'misc-pull-request' of https://gitlab.com/marcandre.lureau/qemu: chardev/char-pty: Avoid losing bytes when the other side just (re-)connected hw/display/ramfb: plug slight guest-triggerable leak on mode setting hw/pc: remove needless includes hw/core: remove needless includes analyze-migration: ignore RAM_SAVE_FLAG_MULTIFD_FLUSH ui/gtk: fix UI info precondition win32: avoid discarding the exception handler ui: add XBGR8888 and ABGR8888 in drm_format_pixman_map ui/console: sanitize search in qemu_graphic_console_is_multihead() ui/console: eliminate QOM properties from qemu_console_is_multihead() ui/console: only walk QemuGraphicConsoles in qemu_console_is_multihead() ui/console: make qemu_console_is_multihead() static input: Allow to choose console with qemu_input_is_absolute Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-04hw/isa/ich9: Add comment on imperfect emulation of PIC vs. I/O APIC routingDavid Woodhouse1-0/+15
As noted in the comment, the PCI INTx lines are supposed to be routed to *both* the PIC and the I/O APIC. It's just that we don't cope with the concept of an IRQ being asserted to two *different* pins on the two irqchips. So we have this hack of routing to I/O APIC only if the PIRQ routing to the PIC is disabled. Which seems to work well enough, even when I try hard to break it with kexec. But should be explicitly documented and understood. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <112a09643b8191c4eae7d92fa247a861ab90a9ee.camel@infradead.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vhost-user: move VhostUserProtocolFeature definition to header fileJonah Palmer3-46/+1
Move the definition of VhostUserProtocolFeature to include/hw/virtio/vhost-user.h. Remove previous definitions in hw/scsi/vhost-user-scsi.c, hw/virtio/vhost-user.c, and hw/virtio/virtio-qmp.c. Previously there were 3 separate definitions of this over 3 different files. Now only 1 definition of this will be present for these 3 files. Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <20230926224107.2951144-4-jonah.palmer@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04qmp: update virtio feature maps, vhost-user-gpio introspectionJonah Palmer2-1/+40
Add new vhost-user protocol feature to vhost-user protocol feature map and enumeration: - VHOST_USER_PROTOCOL_F_STATUS Add new virtio device features for several virtio devices to their respective feature mappings: virtio-blk: - VIRTIO_BLK_F_SECURE_ERASE virtio-net: - VIRTIO_NET_F_NOTF_COAL - VIRTIO_NET_F_GUEST_USO4 - VIRTIO_NET_F_GUEST_USO6 - VIRTIO_NET_F_HOST_USO virtio/vhost-user-gpio: - VIRTIO_GPIO_F_IRQ - VHOST_USER_F_PROTOCOL_FEATURES Add support for introspection on vhost-user-gpio devices. Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <20230926224107.2951144-3-jonah.palmer@oracle.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04qmp: remove virtio_list, search QOM tree insteadJonah Palmer3-69/+29
The virtio_list duplicates information about virtio devices that already exist in the QOM composition tree. Instead of creating this list of realized virtio devices, search the QOM composition tree instead. This patch modifies the QMP command qmp_x_query_virtio to instead recursively search the QOM composition tree for devices of type 'TYPE_VIRTIO_DEVICE'. The device is also checked to ensure it's realized. Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20230926224107.2951144-2-jonah.palmer@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vhost: Add count argument to vhost_svq_poll()Hawkins Jiawei2-15/+23
Next patches in this series will no longer perform an immediate poll and check of the device's used buffers for each CVQ state load command. Instead, they will send CVQ state load commands in parallel by polling multiple pending buffers at once. To achieve this, this patch refactoring vhost_svq_poll() to accept a new argument `num`, which allows vhost_svq_poll() to wait for the device to use multiple elements, rather than polling for a single element. Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <950b3bfcfc5d446168b9d6a249d554a013a691d4.1693287885.git.yin31149@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vdpa: move vhost_vdpa_set_vring_ready to the callerEugenio Pérez2-3/+3
Doing that way allows CVQ to be enabled before the dataplane vqs, restoring the state as MQ or MAC addresses properly in the case of a migration. The patch does it by defining a ->load NetClientInfo callback also for dataplane. Ideally, this should be done by an independent patch, but the function is already static so it would only add an empty vhost_vdpa_net_data_load stub. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230822085330.3978829-5-eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04vdpa: export vhost_vdpa_set_vring_readyEugenio Pérez2-13/+14
The vhost-vdpa net backend needs to enable vrings in a different order than default, so export it. No functional change intended except for tracing, that now includes the (virtio) index being enabled and the return value of the ioctl. Still ignoring return value of this function if called from vhost_vdpa_dev_start, as reorganize calling code around it is out of the scope of this series. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230822085330.3978829-3-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio: don't zero out memory region cache for indirect descriptorsIlya Maximets1-5/+15
Lots of virtio functions that are on a hot path in data transmission are initializing indirect descriptor cache at the point of stack allocation. It's a 112 byte structure that is getting zeroed out on each call adding unnecessary overhead. It's going to be correctly initialized later via special init function. The only reason to actually initialize right away is the ability to safely destruct it. Replacing a designated initializer with a function to only initialize what is necessary. Removal of the unnecessary stack initializations improves throughput of virtio-net devices in terms of 64B packets per second by 6-14 % depending on the case. Tested with a proposed af-xdp network backend and a dpdk testpmd application in the guest, but should be beneficial for other virtio devices as well. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Message-Id: <20230811143423.3258788-1-i.maximets@ovn.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio-net: Expose MAX_VLANHawkins Jiawei1-2/+0
vhost-vdpa shadowed CVQ needs to know the maximum number of vlans supported by the virtio-net device, so QEMU can restore the VLAN state in a migration. Co-developed-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Message-Id: <ca03403319c6405ea7c400836a572255bbc9ceba.1690106284.git.yin31149@gmail.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio-net: do not reset vlan filtering at set_featuresHawkins Jiawei1-3/+1
This function is called after virtio_load, so all vlan configuration is lost in migration case. Just allow all the vlan-tagged packets if vlan is not configured, and trust device reset to clear all filtered vlans. Fixes: 0b1eaa8803 ("virtio-net: Do not filter VLANs without F_CTRL_VLAN") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Hawkins Jiawei <yin31149@gmail.com> Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Message-Id: <95af0d013281282f48ad3f47f6ad1ac4ca9e52eb.1690106284.git.yin31149@gmail.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/virtio: add config support to vhost-user-deviceAlex Bennée1-1/+57
To use the generic device the user will need to provide the config region size via the command line. We also add a notifier so the guest can be pinged if the remote daemon updates the config. With these changes: -device vhost-user-device-pci,virtio-id=41,num_vqs=2,config_size=8 is equivalent to: -device vhost-user-gpio-pci Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230710153522.3469097-11-alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04virtio: add vhost-user-base and a generic vhost-user-deviceAlex Bennée3-0/+398
In theory we shouldn't need to repeat so much boilerplate to support vhost-user backends. This provides a generic vhost-user-base QOM object and a derived vhost-user-device for which the user needs to provide the few bits of information that aren't currently provided by the vhost-user protocol. This should provide a baseline implementation from which the other vhost-user stub can specialise. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230710153522.3469097-8-alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/virtio/meson: Rename softmmu_virtio_ss[] -> system_virtio_ss[]Philippe Mathieu-Daudé1-12/+12
Similarly to commit de6cd7599b ("meson: Replace softmmu_ss -> system_ss"), rename the virtio source set common to all system emulation as 'system_virtio_ss[]'. This is clearer because softmmu can be used for user emulation. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230710100510.84862-1-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/virtio: Build vhost-vdpa.o oncePhilippe Mathieu-Daudé1-1/+2
The previous commit removed the dependencies on the target-specific TARGET_PAGE_FOO macros. We can now move vhost-vdpa.c to the 'softmmu_virtio_ss' source set to build it once for all our targets. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230710100432.84819-1-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/virtio/vhost-vdpa: Use target-agnostic qemu_target_page_mask()Philippe Mathieu-Daudé1-15/+19
Similarly to commit e414ed2c47 ("virtio-iommu: Use target-agnostic qemu_target_page_mask"), Replace the target-specific TARGET_PAGE_SIZE and TARGET_PAGE_MASK definitions by a call to the runtime qemu_target_page_size() helper which is target agnostic. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230710094931.84402-5-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/virtio/vhost-vdpa: Inline TARGET_PAGE_ALIGN() macroPhilippe Mathieu-Daudé1-2/+2
Use TARGET_PAGE_SIZE to calculate TARGET_PAGE_ALIGN (see the rationale in previous commits). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230710094931.84402-4-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/virtio: Propagate page_mask to vhost_vdpa_section_end()Philippe Mathieu-Daudé1-5/+6
Propagate TARGET_PAGE_MASK (see the previous commit for rationale). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230710094931.84402-3-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04hw/virtio: Propagate page_mask to vhost_vdpa_listener_skipped_section()Philippe Mathieu-Daudé1-3/+4
In order to make vhost-vdpa.c a target-agnostic source unit, we need to remove the TARGET_PAGE_SIZE / TARGET_PAGE_MASK / TARGET_PAGE_ALIGN uses. TARGET_PAGE_SIZE will be replaced by the runtime qemu_target_page_size(). The other ones will be deduced from TARGET_PAGE_SIZE. Since the 3 macros are used in 3 related functions (sharing the same call tree), we'll refactor them to only depend on TARGET_PAGE_MASK. Having the following call tree: vhost_vdpa_listener_region_del() -> vhost_vdpa_listener_skipped_section() -> vhost_vdpa_section_end() The first step is to propagate TARGET_PAGE_MASK to vhost_vdpa_listener_skipped_section(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230710094931.84402-2-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-04pci: SLT must be ROMichael S. Tsirkin3-2/+19
current code sets PCI_SEC_LATENCY_TIMER to RW, but for pcie to pcie bridges it must be RO 0 according to pci express spec which says: This register does not apply to PCI Express. It must be read-only and hardwired to 00h. For PCI Express to PCI/PCI-X Bridges, refer to the [PCIe-to-PCI-PCI-X-Bridge] for requirements for this register. also, fix typo in comment where it's made writeable - this typo is likely what prevented us noticing we violate this requirement in the 1st place. Reported-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Message-Id: <de9d05366a70172e1789d10591dbe59e39c3849c.1693432039.git.mst@redhat.com> Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-10-03accel/tcg: Move can_do_io to CPUNegativeOffsetStateRichard Henderson1-1/+1
Minimize the displacement to can_do_io, since it may be touched at the start of each TranslationBlock. It fits into other padding within the substructure. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-03accel/tcg: Remove CPUState.icount_decr_ptrRichard Henderson1-2/+2
We can now access icount_decr directly. Reviewed-by: Anton Johansson <anjo@rev.ng> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-03Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingStefan Hajnoczi36-126/+247
* fix from optionrom build * fix for KVM on Apple M2 * introduce machine property "audiodev" * ui/vnc: Require audiodev= to enable audio * audio: remove QEMU_AUDIO_* and -audio-help support * audio: forbid using default audiodev backend with -audiodev and -nodefaults * remove compatibility code for old machine types * make-release: do not ship dtc sources * build system cleanups # -----BEGIN PGP SIGNATURE----- # # iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmUb0QgUHHBib256aW5p # QHJlZGhhdC5jb20ACgkQv/vSX3jHroOpnAf9EFXfGkXpqQ5Q8ZbVlVc5GQKofMHW # OZwamTBlp/c07+QcQiMxwLhIW0iyDhrfdCjoFSUaTA8O10FM1YrFv4SkUryYb9B3 # bmoTl4NeLvmkxpC47GEeaaBfjyM0G/9Ip9Zsuqx3u+gSzwTbkEstA2u7gcsN0tL9 # VlhMSiV82uHhRC/DJYLxr+8bRYSIm1AeuI8K/O1yags85Kztf3UiQUhePIKLznMH # BdORjD+i46xM1dE8ifpdsunm462cDWz/faAnIH0YVKBlshnQHXKTO+GDA/Fbfl51 # wFfupZXo93wwgawS7elAUzI+gwaKCPRHA8NDcukeO91hTzk6i14y04u5SQ== # =nv64 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 03 Oct 2023 04:30:00 EDT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (24 commits) audio: forbid default audiodev backend with -nodefaults audio: propagate Error * out of audio_init vt82c686 machines: Support machine-default audiodev with fallback hw/ppc: Support machine-default audiodev with fallback hw/arm: Support machine-default audiodev with fallback Introduce machine property "audiodev" audio: remove QEMU_AUDIO_* and -audio-help support audio: simplify flow in audio_init audio: commonize voice initialization audio: return Error ** from audio_state_by_name audio: allow returning an error from the driver init audio: Require AudioState in AUD_add_capture ui/vnc: Require audiodev= to enable audio crypto: only include tls-cipher-suites in emulators scsi-disk: ensure that FORMAT UNIT commands are terminated esp: restrict non-DMA transfer length to that of available data esp: use correct type for esp_dma_enable() in sysbus_esp_gpio_demux() Makefile: build plugins before running TCG tests meson: clean up static_library keyword arguments make-release: do not ship dtc sources ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-03hw/display/ramfb: plug slight guest-triggerable leak on mode settingLaszlo Ersek1-0/+1
The fw_cfg DMA write callback in ramfb prepares a new display surface in QEMU; this new surface is put to use ("swapped in") upon the next display update. At that time, the old surface (if any) is released. If the guest triggers the fw_cfg DMA write callback at least twice between two adjacent display updates, then the second callback (and further such callbacks) will leak the previously prepared (but not yet swapped in) display surface. The issue can be shown by: (1) starting QEMU with "-trace displaysurface_free", and (2) running the following program in the guest UEFI shell: > #include <Library/ShellCEntryLib.h> // ShellAppMain() > #include <Library/UefiBootServicesTableLib.h> // gBS > #include <Protocol/GraphicsOutput.h> // EFI_GRAPHICS_OUTPUT_PROTOCOL > > INTN > EFIAPI > ShellAppMain ( > IN UINTN Argc, > IN CHAR16 **Argv > ) > { > EFI_STATUS Status; > VOID *Interface; > EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop; > UINT32 Mode; > > Status = gBS->LocateProtocol ( > &gEfiGraphicsOutputProtocolGuid, > NULL, > &Interface > ); > if (EFI_ERROR (Status)) { > return 1; > } > > Gop = Interface; > > Mode = 1; > for ( ; ;) { > Status = Gop->SetMode (Gop, Mode); > if (EFI_ERROR (Status)) { > break; > } > > Mode = 1 - Mode; > } > > return 1; > } The symptom is then that: - only one trace message appears periodically, - the time between adjacent messages keeps increasing -- implying that some list structure (containing the leaked resources) keeps growing, - the "surface" pointer is ever different. > 18566@1695127471.449586:displaysurface_free surface=0x7f2fcc09a7c0 > 18566@1695127471.529559:displaysurface_free surface=0x7f2fcc9dac10 > 18566@1695127471.659812:displaysurface_free surface=0x7f2fcc441dd0 > 18566@1695127471.839669:displaysurface_free surface=0x7f2fcc0363d0 > 18566@1695127472.069674:displaysurface_free surface=0x7f2fcc413a80 > 18566@1695127472.349580:displaysurface_free surface=0x7f2fcc09cd00 > 18566@1695127472.679783:displaysurface_free surface=0x7f2fcc1395f0 > 18566@1695127473.059848:displaysurface_free surface=0x7f2fcc1cae50 > 18566@1695127473.489724:displaysurface_free surface=0x7f2fcc42fc50 > 18566@1695127473.969791:displaysurface_free surface=0x7f2fcc45dcc0 > 18566@1695127474.499708:displaysurface_free surface=0x7f2fcc70b9d0 > 18566@1695127475.079769:displaysurface_free surface=0x7f2fcc82acc0 > 18566@1695127475.709941:displaysurface_free surface=0x7f2fcc369c00 > 18566@1695127476.389619:displaysurface_free surface=0x7f2fcc32b910 > 18566@1695127477.119772:displaysurface_free surface=0x7f2fcc0d5a20 > 18566@1695127477.899517:displaysurface_free surface=0x7f2fcc086c40 > 18566@1695127478.729962:displaysurface_free surface=0x7f2fccc72020 > 18566@1695127479.609839:displaysurface_free surface=0x7f2fcc185160 > 18566@1695127480.539688:displaysurface_free surface=0x7f2fcc23a7e0 > 18566@1695127481.519759:displaysurface_free surface=0x7f2fcc3ec870 > 18566@1695127482.549930:displaysurface_free surface=0x7f2fcc634960 > 18566@1695127483.629661:displaysurface_free surface=0x7f2fcc26b140 > 18566@1695127484.759987:displaysurface_free surface=0x7f2fcc321700 > 18566@1695127485.940289:displaysurface_free surface=0x7f2fccaad100 We figured this wasn't a CVE-worthy problem, as only small amounts of memory were leaked (the framebuffer itself is mapped from guest RAM, QEMU only allocates administrative structures), plus libvirt restricts QEMU memory footprint anyway, thus the guest can only DoS itself. Plug the leak, by releasing the last prepared (not yet swapped in) display surface, if any, in the fw_cfg DMA write callback. Regarding the "reproducer", with the fix in place, the log is flooded with trace messages (one per fw_cfg write), *and* the trace message alternates between just two "surface" pointer values (i.e., nothing is leaked, the allocator flip-flops between two objects in effect). This issue appears to date back to the introducion of ramfb (995b30179bdc, "hw/display: add ramfb, a simple boot framebuffer living in guest ram", 2018-06-18). Cc: Gerd Hoffmann <kraxel@redhat.com> (maintainer:ramfb) Cc: qemu-stable@nongnu.org Fixes: 995b30179bdc Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20230919131955.27223-1-lersek@redhat.com>
2023-10-03hw/pc: remove needless includesMarc-André Lureau1-39/+0
The include list is gigantic, make it smaller. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>