aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-07-15ui/gtk: Add scale optionWeifeng Liu3-18/+34
Allow user to set a preferred scale (defaulting to 1) of the virtual display. Along with zoom-to-fix=false, this would be helpful for users running QEMU on hi-dpi host desktop to achieve pixel to pixel display -- e.g., if the scale factor of a user's host desktop is set to 200%, then they can set a 0.5 scale for the virtual display to avoid magnification that might cause blurriness. Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20250601045245.36778-3-weifeng.liu.z@gmail.com>
2025-07-15ui/gtk: Add keep-aspect-ratio optionWeifeng Liu3-6/+19
When aspect ratio of host window and that of guest display are not aligned, we can either zoom the guest content to fill the whole host window or add padding to respect aspect ratio of the guest. Add an option keep-aspect-ratio to allow users to select their preferred behavior in this case. Suggested-by: BALATON Zoltan <balaton@eik.bme.hu> Suggested-by: Kim, Dongwon <dongwon.kim@intel.com> Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20250601045245.36778-2-weifeng.liu.z@gmail.com>
2025-07-15hw/display: Allow injection of virtio-gpu EDID nameAndrew Keesler6-2/+97
Thanks to 72d277a7, 1ed2cb32, and others, EDID (Extended Display Identification Data) is propagated by QEMU such that a virtual display presents legitimate metadata (e.g., name, serial number, preferred resolutions, etc.) to its connected guest. This change adds the ability to specify the EDID name for a particular virtio-vga display. Previously, every virtual display would have the same name: "QEMU Monitor". Now, we can inject names of displays in order to test guest behavior that is specific to display names. We provide the ability to inject the display name from the frontend since this is guest visible data. Furthermore, this makes it clear where N potential display outputs would get their name from (which will be added in a future change). Note that we have elected to use a struct here for output data for extensibility - we intend to add per-output fields like resolution in a future change. It should be noted that EDID names longer than 12 bytes will be truncated per spec (I think?). Testing: verified that when I specified 2 outputs for a virtio-gpu with edid_name set, the names matched those that I configured with my vnc display. -display vnc=localhost:0,id=aaa,display=vga,head=0 \ -display vnc=localhost:1,id=bbb,display=vga,head=1 \ -device '{"driver":"virtio-vga", "max_outputs":2, "id":"vga", "outputs":[ { "name":"AAA" }, { "name":"BBB" } ]}' Signed-off-by: Andrew Keesler <ankeesler@google.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20250709121126.2946088-2-ankeesler@google.com>
2025-07-15ui/spice: Blit the scanout texture if its memory layout is not linearVivek Kasireddy2-6/+78
In cases where the scanout buffer is provided as a texture (e.g. Virgl) we need to check to see if it has a linear memory layout or not. If it doesn't have a linear layout, then blitting it onto the texture associated with the display surface (which already has a linear layout) seems to ensure that there is no corruption seen regardless of which encoder or decoder is used. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Frediano Ziglio <freddy77@gmail.com> Cc: Dongwon Kim <dongwon.kim@intel.com> Cc: Michael Scherle <michael.scherle@rz.uni-freiburg.de> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Message-Id: <20250617043546.1022779-8-vivek.kasireddy@intel.com>
2025-07-15ui/spice: Create a new texture with linear layout when gl=on is specifiedVivek Kasireddy3-0/+89
Since most encoders/decoders (invoked by Spice) may not work properly with tiled memory associated with a texture, we need to create another texture that has linear memory layout and use that instead. Note that, there does not seem to be a direct way to indicate to the GL implementation that a texture's backing memory needs to be linear. Instead, we have to do it in a roundabout way where we need to first create a tiled texture and import that as a memory object to create a new texture that has a linear memory layout. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Frediano Ziglio <freddy77@gmail.com> Cc: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Co-developed-by: Michael Scherle <michael.scherle@rz.uni-freiburg.de> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Message-Id: <20250617043546.1022779-7-vivek.kasireddy@intel.com>
2025-07-15ui/console-gl: Add a helper to create a texture with linear memory layoutVivek Kasireddy2-0/+51
There are cases where we do not want the memory layout of a texture to be tiled as the component processing the texture would not know how to de-tile either via software or hardware. Therefore, ensuring that the memory backing the texture has a linear layout is absolutely necessary in these situations. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Frediano Ziglio <freddy77@gmail.com> Cc: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Co-developed-by: Michael Scherle <michael.scherle@rz.uni-freiburg.de> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Message-Id: <20250617043546.1022779-6-vivek.kasireddy@intel.com>
2025-07-15ui/spice: Add an option to submit gl_draw requests at fixed rateVivek Kasireddy4-10/+70
In the specific case where the display layer (virtio-gpu) is using dmabuf, and if remote clients are enabled (-spice gl=on,port=xxxx), it makes sense to limit the maximum (streaming) rate (refresh rate) to a fixed value using the GUI refresh timer. Otherwise, the updates or gl_draw requests would be sent as soon as the Guest submits a new frame which is not optimal as it would lead to increased network traffic and wastage of GPU cycles if the frames get dropped. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Frediano Ziglio <freddy77@gmail.com> Cc: Dongwon Kim <dongwon.kim@intel.com> Cc: Michael Scherle <michael.scherle@rz.uni-freiburg.de> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Message-Id: <20250617043546.1022779-5-vivek.kasireddy@intel.com>
2025-07-15ui/spice: Add an option for users to provide a preferred video codecVivek Kasireddy2-0/+24
Giving users an option to choose a particular codec will enable them to make an appropriate decision based on their hardware and use-case. Note that, the Spice server would use this codec with Gstreamer encoder and only when gl=on is specified. If no codec is provided, then the codec gstreamer:h264 would be used as default. And, for the case where gl=off, the default codec to be used is determined by the Spice server. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Frediano Ziglio <freddy77@gmail.com> Cc: Dongwon Kim <dongwon.kim@intel.com> Cc: Michael Scherle <michael.scherle@rz.uni-freiburg.de> Cc: Daniel P. Berrangé <berrange@redhat.com> [ Marc-Andre - fix unused variables warnings ] Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Message-Id: <20250617043546.1022779-4-vivek.kasireddy@intel.com>
2025-07-15Merge tag 'pull-10.1-rc0-maintainer-140725-1' of ↵Stefan Hajnoczi19-86/+352
https://gitlab.com/stsquad/qemu into staging maintainer updates (gitlab, plugins, gdbstub, docs) - update check-units script to take -n <top> argument - fix execlog plugin to handle tab separators - add gdb XML file for alpha - add gdb XML file for sparc64 - use :kbd: in docs to highlight key sequences - clean up rst formatting in virtio-net-failover docs # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmh0374ACgkQ+9DbCVqe # KkR0gQf/a9Au455+OWEhG3uLGkMZZaFM6QJv8W3wBBZoRg59LMXkUIhEtyVfdmt5 # SDyA79nw1G0iP2qlKQV02R++CrBHMJILtYOMoLTbkWV9Lft4h+uPC27SE17DkNPS # 4b4TchlJ3DpOFi0XmYZuIwH/8CPpTdVCLcA5zEXT0Q8nKjk0JsGiOQxoHH+p3ad5 # +mgvlmITDpU88OCilDYgmrD5iSe/WLzwszV9D6JTfQakfM7J9G87sj4iMK+En+iu # 0rsRBk2gwahy4cfqaiaELTtarqadM1TaNwaRvt6vun+Hp12pypDhogG1Mh5e2eCB # /nFwjcswRRk+kd26993AiK8Soomwiw== # =Md3/ # -----END PGP SIGNATURE----- # gpg: Signature made Mon 14 Jul 2025 06:45:18 EDT # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * tag 'pull-10.1-rc0-maintainer-140725-1' of https://gitlab.com/stsquad/qemu: gdbstub: add the GDB register XML files for sparc64. docs/system: clean-up formatting of virtio-net-failover docs: use :kbd: role in sphinx docs plugins: fix inclusion of user-mode APIs target/alpha: Add GDB XML feature file contrib/plugins/execlog: Add tab to the separator search of insn_disas gitlab: add -n option to check-units script gitlab: use argparse in check-units script Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-07-15net/af-xdp: Support pinned map path for AF_XDP socketsDaniel Borkmann3-17/+118
Extend 'inhibit=on' setting with the option to specify a pinned XSK map path along with a starting index (default 0) to push the created XSK sockets into. Example usage: # ./build/qemu-system-x86_64 [...] \ -netdev af-xdp,ifname=enp2s0f0np0,id=net0,mode=native,queues=2,start-queue=14,inhibit=on,map-path=/sys/fs/bpf/xsks_map,map-start-index=14 \ -device virtio-net-pci,netdev=net0 [...] This is useful for the case where an existing XDP program with XSK map is present on the AF_XDP supported phys device and the XSK map is not yet populated. For example, the former could have been pre-loaded onto the netdevice by a control plane, which later launches QEMU to populate it with XSK sockets. Normally, the main idea behind 'inhibit=on' is that the QEMU instance doesn't need to have a lot of privileges to use the pre-loaded program and the pre-created sockets, but this mentioned use-case here is different where QEMU still needs privileges to create the sockets. The 'map-start-index' parameter is optional and defaults to 0. It allows flexible placement of the XSK sockets, and is up to the user to specify when the XDP program with XSK map was already preloaded. In the simplest case the queue-to-map-slot mapping is just 1:1 based on ctx->rx_queue_index but the user might as well have a different scheme (or smaller map size, e.g. ctx->rx_queue_index % max_size) to push the inbound traffic to one of the XSK sockets. Note that the bpf_xdp_query_id() is now only tested for 'inhibit=off' since only in the latter case the libxdp takes care of installing the XDP program which was installed based on the s->xdp_flags pointing to either driver or skb mode. For 'inhibit=on' we don't make any assumptions and neither go down the path of probing all possible options in which way the user installed the XDP program. Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Ilya Maximets <i.maximets@ovn.org> Cc: Jason Wang <jasowang@redhat.com> Cc: Anton Protopopov <aspsk@isovalent.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-07-15net/af-xdp: Fix up cleanup path upon failure in queue creationDaniel Borkmann1-4/+4
While testing, it turned out that upon error in the queue creation loop, we never trigger the af_xdp_cleanup() handler. This is because we pass errp instead of a local err pointer into the various AF_XDP setup functions instead of a scheme like: bool fn(..., Error **errp) { Error *err = NULL; foo(arg, &err); if (err) { handle the error... error_propagate(errp, err); return false; } ... } The same is true for the attachment probing with bpf_xdp_query_id(). With a conversion into the above format, the af_xdp_cleanup() handler is called as expected. Note the error_propagate() handles a NULL err internally. Fixes: cb039ef3d9e3 ("net: add initial support for AF_XDP network backend") Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Ilya Maximets <i.maximets@ovn.org> Cc: Jason Wang <jasowang@redhat.com> Cc: Anton Protopopov <aspsk@isovalent.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-07-15net/af-xdp: Remove XDP program cleanup logicDaniel Borkmann1-12/+0
There are two issues with the XDP program removal in af_xdp_cleanup(): 1) Starting from libxdp 1.3.0 [0] the XDP program gets automatically detached when we call xsk_socket__delete() for the last successfully configured queue. libxdp internally keeps track of that. For QEMU we require libxdp >= 1.4.0. Given QEMU is not loading the program, lets also not attempt to remove it and delegate this instead. 2) The removal logic is incorrect anyway because we are setting n_queues into the last queue that never has xdp_flags on failure, so the logic is always skipped since the non-zero test for s->xdp_flags in af_xdp_cleanup() fails. Fixes: cb039ef3d9e3 ("net: add initial support for AF_XDP network backend") Suggested-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Cc: Ilya Maximets <i.maximets@ovn.org> Cc: Jason Wang <jasowang@redhat.com> Cc: Anton Protopopov <aspsk@isovalent.com> Link: https://github.com/xdp-project/xdp-tools/commit/38c2914988fd5c1ef65f2381fc8af9f3e8404e2b [0] Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-07-15esp.c: only allow ESP commands permitted in the current asc_modeMark Cave-Ayland3-0/+46
If an ESP command is issued in an incorrect mode then an illegal command interrupt should be generated. Add a new esp_cmd_is_valid() function to indicate whether the ESP command is valid for the current mode, and if not then raise the illegal command interrupt. This fixes WinNT MIPS which issues ICCS after a Chip Reset which is not permitted, but will fail with an INACCESSIBLE_BOOT_DEVICE error unless an interrupt is generated. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: 83428f7a97 ("esp.c: move write_response() non-DMA logic to esp_do_nodma()") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2464 Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250711204636.542964-8-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15esp.c: add asc_mode property to indicate the current ESP modeMark Cave-Ayland2-1/+27
Add a new asc_mode property to ESPState which indicates the current mode of the ESP and update the ESP state machine accordingly. Bump the vmstate version and include migration logic to ensure that asc_mode is set to initiator mode such that any commands in progress will always continue. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250711204636.542964-7-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15esp.c: only call dma_memory_write function if transfer length is non-zeroMark Cave-Ayland1-1/+5
In the cases where mixed DMA/non-DMA transfers are used or no data is available, it is possible for the calculated transfer length to be zero. Only call the dma_memory_write function where the transfer length is non-zero to avoid invoking the DMA engine for a zero length transfer which can have side-effects (along with generating additional tracing noise). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250711204636.542964-6-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15esp.c: only call dma_memory_read function if transfer length is non-zeroMark Cave-Ayland1-7/+13
In the cases where mixed DMA/non-DMA transfers are used or no data is available, it is possible for the calculated transfer length to be zero. Only call the dma_memory_read function where the transfer length is non-zero to avoid invoking the DMA engine for a zero length transfer which can have side-effects (along with generating additional tracing noise). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250711204636.542964-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15esp.h: remove separate ESPState typedefMark Cave-Ayland1-2/+0
This is not needed as it is now handled by the OBJECT_DECLARE_SIMPLE_TYPE() macro. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250711204636.542964-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15esp.c: improve comment in esp_transfer_data()Mark Cave-Ayland1-2/+3
Whilst working on the previous patch, the existing comment was not enough to document when the TI command codepath was being used. Update and improve the comment accordingly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250711204636.542964-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15esp.c: only raise IRQ in esp_transfer_data() for CMD_SEL, CMD_SELATN and ↵Mark Cave-Ayland1-2/+3
CMD_TI commands Clarify the logic in esp_transfer_data() to ensure that the deferred interrupt code can only be triggered for CMD_SEL, CMD_SELATN and CMD_TI commands. This should already be the case, but make it explicit to ensure the logic isn't triggered unexpectedly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250711204636.542964-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15hw/microblaze: Add missing FDT dependencyBernhard Beschow1-2/+2
These boards ship with a bundled DTB, and dtc will be required for generating these from device tree sources. Prepare for that by adding an FDT dependency. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250708204806.1898-2-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15hw/intc/loongarch_extioi: Remove unnecessary 'qemu/typedefs.h' includePhilippe Mathieu-Daudé1-1/+0
"qemu/typedefs.h" is already included by "qemu/osdep.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-Id: <20250708085859.7885-2-philmd@linaro.org>
2025-07-15hw/mips: Restrict ITU to TCGPhilippe Mathieu-Daudé3-3/+4
MIPS Inter-Thread Communication Unit is implemented using TCG. Check for TCG both in Kconfig and CPS source. Fixes: 2321d971b6f ("hw/mips: Add dependency MIPS_CPS -> MIPS_ITU") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250702164953.18579-1-philmd@linaro.org>
2025-07-15roms: re-remove execute bit from hppa-firmware*Cole Robinson2-0/+0
This was fixed in c9d77526bddba0803a1fa982fb59ec98057150f9 for 9.2.0 but regressed in db34be329162cf6b06192703065e6c1010dbe3c5 in 10.0.0 When the bit is present, rpmbuild complains about missing ELF build-id Signed-off-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Helge Deller <deller@gmx.de> Message-ID: <52d0edfbb9b2f63a866f0065a721f3a95da6f8ba.1747590860.git.crobinso@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15tests/tcg/mips: Add tests for MIPS CRC32[c] instructionsAleksandar Rakic10-0/+1208
Signed-off-by: Yongbok Kim <yongbok.kim@mips.com> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Aleksandar Rakic <aleksandar.rakic@htecgroup.com> Reviewed-by: Aleksandar Rikalo <arikalo@gmail.com> Message-ID: <20250214173702.2308488-3-aleksandar.rakic@htecgroup.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-07-15target/mips: Have gen_[d]lsa() callers add 1 to shift amount argumentPhilippe Mathieu-Daudé5-13/+8
Having the callee add 1 to shift amount is misleading (see the NM_LSA case in decode_nanomips_32_48_opc() where we have to manually substract 1). Rather have the callers pass a modified $sa. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20241112172022.88348-4-philmd@linaro.org>
2025-07-15target/mips: Convert Octeon LX instructions to decodetreePhilippe Mathieu-Daudé3-3/+21
Use Octeon decodetree to call gen_lx() for the LX instructions. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20241111222936.59869-4-philmd@linaro.org>
2025-07-15target/mips: Extract generic gen_lx() helperPhilippe Mathieu-Daudé2-36/+20
Extract gen_lx() from gen_mips_lx(); inline the Octeon check in decode_opc_special3_legacy(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20241111222936.59869-3-philmd@linaro.org>
2025-07-15target/mips: Extract gen_base_index_addr() helperPhilippe Mathieu-Daudé2-14/+14
Factor out gen_base_index_addr() which is used twice but we'll use it more. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20241111222936.59869-2-philmd@linaro.org>
2025-07-15target/mips: Add support for emulation of CRC32 instructionsYongbok Kim8-4/+78
Add emulation of MIPS' CRC32 (Cyclic Redundancy Check) instructions. Reuse zlib crc32() and Linux crc32c(). Corresponding disassembly has been added in commit 99029be1c28 ("target/mips: Add implementation of GINVT instruction"). Signed-off-by: Yongbok Kim <yongbok.kim@mips.com> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Aleksandar Rakic <aleksandar.rakic@htecgroup.com> Reviewed-by: Aleksandar Rikalo <arikalo@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <PA4PR09MB486489692D843DDFC25F3CF1846B2@PA4PR09MB4864.eurprd09.prod.outlook.com>
2025-07-14file-posix: Fix aio=threads performance regression after enablign FUAKevin Wolf1-14/+15
For aio=threads, we're currently not implementing REQ_FUA in any useful way, but just do a separate raw_co_flush_to_disk() call. This changes behaviour compared to the old state, which used bdrv_co_flush() with its optimisations. As a quick fix, call bdrv_co_flush() again like before. Eventually, we can use pwritev2() to make use of RWF_DSYNC if available, but we'll still have to keep this code path as a fallback, so this fix is required either way. While the fix itself is a one-liner, some new graph locking annotations are needed to convince TSA that the locking is correct. Cc: qemu-stable@nongnu.org Fixes: 984a32f17e8d ("file-posix: Support FUA writes") Buglink: https://issues.redhat.com/browse/RHEL-96854 Reported-by: Tingting Mao <timao@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20250625085019.27735-1-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block/qapi: make @node-name in @BlockDeviceInfo non-optionalFiona Ebner2-4/+2
Since commit 15489c769b ("block: auto-generated node-names"), if the node name of a block driver state is not explicitly specified, it will be auto-generated. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250702123204.325470-3-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block/qapi: include child references in block device infoFiona Ebner3-0/+34
In combination with using a throttle filter to enforce IO limits for a guest device, knowing the 'file' child of a block device can be useful. If the throttle filter is only intended for guest IO, block jobs should not also be limited by the throttle filter, so the block operations need to be done with the 'file' child of the top throttle node as the target. In combination with mirroring, the name of that child is not fixed. Another scenario is when unplugging a guest device after mirroring below a top throttle node, where the mirror target is added explicitly via blockdev-add. After mirroring, the target becomes the new 'file' child of the throttle node. For unplugging, both the top throttle node and the mirror target need to be deleted, because only implicitly added child nodes are deleted automatically, and the current 'file' child of the throttle node was explicitly added (as the mirror target). In other scenarios, it could be useful to follow the backing chain. Note that iotests 191 and 273 use _filter_img_info, so the 'children' information is filtered out there. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250702123204.325470-2-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14blockjob: mark block_job_remove_all_bdrv() as GRAPH_UNLOCKEDFiona Ebner1-1/+1
The function block_job_remove_all_bdrv() calls bdrv_graph_wrlock_drained(), which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-49-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_open_child_common() and its callers GRAPH_UNLOCKEDFiona Ebner3-13/+15
The function bdrv_open_child_common() calls bdrv_graph_wrlock_drained(), which must be called with the graph unlocked. Mark it and its two callers bdrv_open_file_child() and bdrv_open_child() as GRAPH_UNLOCKED. This requires temporarily unlocking in vmdk_parse_extents() and making the locked section shorter in vmdk_open(). Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-48-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_close() as GRAPH_UNLOCKEDFiona Ebner2-2/+2
The functions blk_log_writes_close(), blkverify_close(), quorum_close(), vmdk_close() via vmdk_free_extents(), and other bdrv_close() implementations call bdrv_graph_wrlock_drained(), which must be called with the graph unlocked. They are reached via the BlockDriver's bdrv_close() callback and the bdrv_close() wrapper, which are also marked as GRAPH_UNLOCKED_PTR and GRAPH_UNLOCKED. Furthermore, the function bdrv_close() also calls bdrv_drained_begin() and bdrv_graph_wrlock_drained(), so there are additional reasons for marking it GRAPH_UNLOCKED. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-47-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_close_all() as GRAPH_UNLOCKEDFiona Ebner1-1/+1
The function bdrv_close_all() calls bdrv_drain_all(), which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-46-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_drop_intermediate() as GRAPH_UNLOCKEDFiona Ebner1-3/+4
The function bdrv_drop_intermediate() calls bdrv_drained_begin(), which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-45-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_insert_node() as GRAPH_UNLOCKEDFiona Ebner1-2/+3
The function bdrv_insert_node() calls bdrv_drained_begin() which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-44-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_replace_child_bs() as GRAPH_UNLOCKEDFiona Ebner1-2/+2
The function bdrv_replace_child_bs() calls bdrv_drained_begin() which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-43-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: Allow bdrv_new() with and without graph lockKevin Wolf1-1/+1
bdrv_new() calls bdrv_drained_begin(), which can poll and therefore can't be called while holding the graph lock. One option to make sure that this call is allowed would be marking bdrv_new() GRAPH_UNLOCKED. However, this is actually an unnecessary restriction because we know that we only just created the BlockDriverState and it isn't even part of the graph yet. We can use bdrv_do_drained_begin_quiesce() instead to avoid the polling, which means that bdrv_new() can now safely be called from callers that hold the graph lock as well as from callers that don't. Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block/commit: mark commit_abort() as GRAPH_UNLOCKEDFiona Ebner2-2/+2
The function commit_abort() calls bdrv_drained_begin(), which must be called with the graph unlocked. Also mark the JobDriver's abort() callback as GRAPH_UNLOCKED_PTR, because that is the callback via which commit_abort() is reached. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-41-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block-backend: mark blk_io_limits_disable() as GRAPH_UNLOCKEDFiona Ebner1-1/+1
The function blk_io_limits_disable() calls bdrv_drained_begin(), which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-40-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark blk_drain() as GRAPH_UNLOCKEDFiona Ebner1-1/+1
The function blk_drain() calls bdrv_drained_begin(), which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-39-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark blk_remove_bs() as GRAPH_UNLOCKEDFiona Ebner2-6/+11
The function blk_remove_bs() calls bdrv_graph_wrlock_drained() and can also call bdrv_drained_begin(), both of which which must be called with the graph unlocked. Marking blk_remove_bs() as GRAPH_UNLOCKED requires temporarily unlocking in hmp_drive_del(). Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-38-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_inactivate_all() as GRAPH_UNLOCKEDFiona Ebner1-1/+1
The function bdrv_inactivate_all() calls bdrv_drain_all_begin(), which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-37-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_inactivate() as GRAPH_RDLOCK and move drain to callersFiona Ebner3-39/+50
The function bdrv_inactivate() calls bdrv_drain_all_begin(), which needs to be called with the graph unlocked, so either bdrv_inactivate() should be marked as GRAPH_UNLOCKED or the drain needs to be moved to the callers. The caller in qmp_blockdev_set_active() requires that the locked section covers bdrv_find_node() too, so the latter alternative is chosen. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-36-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block: mark bdrv_reopen_queue() and bdrv_reopen_multiple() as GRAPH_UNLOCKEDFiona Ebner2-5/+7
The function bdrv_reopen_queue() can call bdrv_drain_all_begin(), which must be called with the graph unlocked. The function bdrv_reopen_multiple() calls bdrv_reopen_prepare() which must be called with the graph unlocked. To mark bdrv_reopen_queue() as GRAPH_UNLOCKED, it is necessary to make the locked section in reopen_backing_file() shorter. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-35-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block/stream: mark stream_prepare() as GRAPH_UNLOCKEDFiona Ebner2-2/+2
The function stream_prepare() calls bdrv_drain_all_begin(), which must be called with the graph unlocked. Also mark the JobDriver's prepare() callback as GRAPH_UNLOCKED_PTR, because that is the callback via which stream_prepare() is reached. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-34-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block/snapshot: mark bdrv_all_delete_snapshot() as GRAPH_UNLOCKEDFiona Ebner1-3/+3
The function bdrv_all_delete_snapshot() calls bdrv_drain_all_begin(), which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-33-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2025-07-14block-backend: mark blk_drain_all() as GRAPH_UNLOCKEDFiona Ebner1-1/+1
The function blk_drain_all() calls bdrv_drain_all_begin(), which must be called with the graph unlocked. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20250530151125.955508-32-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
generated by cgit v1.1 at 2025-09-19 23:16:34 +0000