In fimd_update_memory_section() we attempt ot find and map part of
the RAM MR which backs the framebuffer, based on guest-configurable
size and start address.
If the guest configures framebuffer settings which result in a
zero-sized framebuffer, we hit an assertion(), because
memory_region_find() will return a NULL mem_section.mr.
Explicitly check for the zero-size case and treat this as a
guest error.
Because we now have a code path which can reach error_return without
calling memory_region_find to set w->mem_section, we must NULL out
w->mem_section.mr after the unref of the old MR, so that error_return
does not incorrectly double-unref the old MR.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1407
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20251107143913.1341358-1-peter.maydell@linaro.org
error_fatal is passed to vmstate_load_state() and vmstate_save_state()
functions. This was introduced in commit c632ffbd74. This would exit(1)
on error, and therefore does not allow to propagate the error back to
the caller.
To maintain consistency with prior error handling i.e. either propagating
the error to the caller or reporting it, we must set the error within a
local Error object instead of using error_fatal.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Link: https://lore.kernel.org/r/20251028-solve_error_fatal_regression-v2-1-dab24c808a28@redhat.com
[peterx: always uninit var ret, per Akihiko]
[peterx: touchups on line ordering, spacings etc.]
Signed-off-by: Peter Xu <peterx@redhat.com>
There is no clear need for this extra intermediary structure between
the audio backend and its user.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
There are 2 sets of functions since the introduction of multi-channel
Volume structure: AUD_set_volume_{in,out} and audio_set_volume_{in,out}.
Use the AUD_ prefix for consistency with other audio.c functions. Rename
the stereo function with "_lr" suffix.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
xenfb_mouse_event() has a switch statement whose controlling
expression move->axis is an enum InputAxis. The enum values are
INPUT_AXIS_X and INPUT_AXIS_Y, encoded as 0 and 1. The switch has a
case for both axes. In addition, it has an unreachable default label.
This convinces Coverity that move->axis can be greater than 1. It
duly reports a buffer overrun when it is used to subscript an array
with two elements.
Replace the unreachable code by g_assert_not_reached().
Resolves: Coverity CID 1613906
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250729111226.3627499-1-armbru@redhat.com>
[PMD: s/abort/g_assert_not_reached/]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
This commit removes the redundant vmstate_save_state_with_err()
function.
Previously, commit 969298f9d7 introduced vmstate_save_state_with_err()
to handle error propagation, while vmstate_save_state() existed for
non-error scenarios.
This is because there were code paths where vmstate_save_state_v()
(called internally by vmstate_save_state) did not explicitly set
errors on failure.
This change unifies error handling by
- updating vmstate_save_state() to accept an Error **errp argument.
- vmstate_save_state_v() ensures errors are set directly within the errp
object, eliminating the need for two separate functions.
All calls to vmstate_save_state_with_err() are replaced with
vmstate_save_state(). This simplifies the API and improves code
maintainability.
vmstate_save_state() that only calls vmstate_save_state_v(),
by inference, also has errors set in errp in case of failure.
The errors are reported using error_report_err().
If we want the function to exit on error, then &error_fatal is
passed.
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Arun Menon <armenon@redhat.com>
Tested-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Link: https://lore.kernel.org/r/20250918-propagate_tpm_error-v14-24-36f11a6fb9d3@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
This is an incremental step in converting vmstate loading
code to report error via Error objects instead of directly
printing it to console/monitor.
It is ensured that vmstate_load_state() must report an error
in errp, in case of failure.
The errors are temporarily reported using error_report_err().
This is removed in the subsequent patches in this series,
when we are actually able to propagate the error to the calling
function using errp. Whereas, if we want the function to exit on
error, then error_fatal is passed.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Arun Menon <armenon@redhat.com>
Tested-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Link: https://lore.kernel.org/r/20250918-propagate_tpm_error-v14-2-36f11a6fb9d3@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
We added @error_warn some two years ago in commit 3ffef1a55c (error:
add global &error_warn destination). It has multiple issues:
* error.h's big comment was not updated for it.
* Function contracts were not updated for it.
* ERRP_GUARD() is unaware of @error_warn, and fails to mask it from
error_prepend() and such. These crash on @error_warn, as pointed
out by Akihiko Odaki.
All fixable. However, after more than two years, we had just of 15
uses, of which the last few patches removed seven as unclean or
otherwise undesirable, adding back five elsewhere. I didn't look
closely enough at the remaining seven to decide whether they are
desirable or not.
I don't think this feature earns its keep. Drop it.
Thanks-to: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20250923091000.3180122-14-armbru@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
The definitions from console.h are not needed in the bcm2835_fb.h
header file yet, so let's move it to the place that really needs
its definitions, i.e. into the bcm2835_fb.c file.
This way the header can also be used by code that is not compiled
with the CFLAGS that are required for pixman or OpenGL (in case
their headers do not reside under /usr/include).
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250508144120.163009-3-thuth@redhat.com>
In the xnlx_dp_init() function we create the s->dpcd and
s->edid objects with qdev_new(); then in xlnx_dp_realize()
we realize the dpcd with qdev_realize() and the edid with
qdev_realize_and_unref().
This is inconsistent, and both ways result in a memory
leak for the instance_init -> deinit lifecycle tested
by device-introspect-test:
Indirect leak of 1968 byte(s) in 1 object(s) allocated from:
#0 0x5aded4d54e23 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-aarch64+0x24ffe23) (BuildId: 9f1e6c5
3fecd904ba5fc1f521d7da080a0e4103b)
#1 0x71fbfac9bb09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x5aded7b9211c in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:767:15
#3 0x5aded7b92240 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12
#4 0x5aded7b773e4 in qdev_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/qdev.c:149:19
#5 0x5aded54458be in xlnx_dp_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/display/xlnx_dp.c:1272:20
Direct leak of 344 byte(s) in 1 object(s) allocated from:
#0 0x5aded4d54e23 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-aarch64+0x24ffe23) (BuildId: 9f1e6c53fecd904ba5fc1f521d7da080a0e4103b)
#1 0x71fbfac9bb09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x5aded7b9211c in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:767:15
#3 0x5aded7b92240 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12
#4 0x5aded7b773e4 in qdev_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/qdev.c:149:19
#5 0x5aded5445a56 in xlnx_dp_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/display/xlnx_dp.c:1275:22
Instead, explicitly object_unref() after we have added the objects as
child properties of the device. This means they will automatically
be freed when this device is deinited. When we do this,
qdev_realize() is the correct way to realize them in
xlnx_dp_realize().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-ID: <20250826174956.3010274-3-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In framebuffer_update_display(), Coverity complains because we
multiply two values of type 'int' (which will be done as a 32x32
multiply and so in theory might overflow) and then add the result to
a ram_addr_t, which can be 64 bits.
4GB framebuffers are not plausible anyway, but keep Coverity happy
by adding casts which force these multiplies to be done as 64x64.
Coverity: CID 1487248
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Message-id: 20250710174312.1313177-1-peter.maydell@linaro.org
"qemu/error-report.h" was previously implicitly included. This is no
longer the case following 012842c075.
However, the issue predates this change as `error-report.h` should have
been included when the `warn_report` call was introduced.
Fixes: fa140b9562 ("hw/sm501: allow compiling without PIXMAN")
Signed-off-by: Clément Chigot <chigot@adacore.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250728090518.963573-1-chigot@adacore.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
ramfb is a sysbus device so it can only used for machine types where it
is explicitly enabled:
# git grep machine_class_allow_dynamic_sysbus_dev.*TYPE_RAMFB_DEVICE
hw/arm/virt.c: machine_class_allow_dynamic_sysbus_dev(mc,
TYPE_RAMFB_DEVICE);
hw/i386/microvm.c: machine_class_allow_dynamic_sysbus_dev(mc,
TYPE_RAMFB_DEVICE);
hw/i386/pc_piix.c: machine_class_allow_dynamic_sysbus_dev(m,
TYPE_RAMFB_DEVICE);
hw/i386/pc_q35.c: machine_class_allow_dynamic_sysbus_dev(m,
TYPE_RAMFB_DEVICE);
hw/loongarch/virt.c: machine_class_allow_dynamic_sysbus_dev(mc,
TYPE_RAMFB_DEVICE);
hw/riscv/virt.c: machine_class_allow_dynamic_sysbus_dev(mc,
TYPE_RAMFB_DEVICE);
So these six are the only machine types we have to worry about.
The three x86 machine types (pc, q35, microvm) will actually use the rom
(when booting with seabios).
For arm/riscv/loongarch virt we want to disable the rom.
This patch sets ramfb romfile option to false by default, except for x86
machines types (pc, q35, microvm) which need the rom file when booting
with seabios and machine types <= 10.0 (handling the case of arm virt,
for compat reasons).
At the same time, set the "use-legacy-x86-rom" property to true on those
historical versioned machine types in order to avoid the memory layout
being changed.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Message-ID: <20250717100941.2230408-4-shahuang@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently the ramfb device loads the vgabios-ramfb.bin unconditionally,
but only the x86 need the vgabios-ramfb.bin, this can cause that when
use the release package on arm64 it can't find the vgabios-ramfb.bin.
Because only seabios will use the vgabios-ramfb.bin, load the rom logic
is x86-specific. For other !x86 platforms, the edk2 ships an EFI driver
for ramfb, so they don't need to load the romfile.
So add a new property use-legacy-x86-rom in both ramfb and vfio_pci
device, because the vfio display also use the ramfb_setup() to load
the vgabios-ramfb.bin file.
After have this property, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
For now the default value is true but it will be turned off by default
in subsequent patch when compats get properly handled.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Message-ID: <20250717100941.2230408-2-shahuang@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
UI-related for 10.1
- [PATCH v3 0/2] ui/vnc: Do not copy z_stream
- [PATCH v6 0/7] ui/spice: Enable gl=on option for non-local or remote clients
- [PATCH v6 0/1] Allow injection of virtio-gpu EDID name
- [PATCH 0/2] ui/gtk: Add keep-aspect-ratio and scale option
# -----BEGIN PGP SIGNATURE-----
#
# iQJQBAABCgA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmh19eYcHG1hcmNhbmRy
# ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5cLsEAC1NV4DFQmb0TjuK/Bb
# 81dDED9DGHsYybVy5x3xSqVkJtAoHTC4FmCm8x9T8wwg+utDvCGFfRM1GeMFR/yI
# IzM+2xs9PcG/+7j/HhVLWr9QhoWV/yoKHcjJScfkTrTtZxAQRA3suUdQT1RjvwUY
# NEuKaOx42dEpV7E+OHp8172eG8CWBzFMjH+cx2b6yKoxF1kVsB7kgVb+kCMYBEQi
# 1YHf34G+HGTev+IzzpxnO+P7p2lJ1ud93kCp1Yz8ua5zOUEPiaHkbClFj4M9mdsn
# xvaxby+zJqe33rh8pVr3qD/4R2j35OW7F5uiAQ8C96KF5Eviia8Cno1s4QInpcw/
# sqtorkaP+OLO6sCnvBQqo99iMH2KloCV7b5sUzfxlUkS+3txD1AKRbodz+vhBqMN
# dbESdd1veUFEvi00DGbxfJbbkzVIhxAwad8CNnSjCdsvJdfYLA7TuSEuBtf1lQPF
# lqpVZFB6C3LQMbmTwT9YrOzMtMXQcT+GFpJLOBk0Cxv4rCSil+TeDpEUNXHurYjI
# qWZT+vyGDqyhoZHyQMPsBwAywKgtMC3IwnkKgJdTHroJ57Am86BvZqELRzh8Tffl
# nkdu1uHdNQXT/u8ybU3mStaQ7xMJALL4tlMuIZ5TIkvMeQm4CiViGb/i5LSn/GMk
# lx2JmBwXXf/imsXeBUfxktJFrw==
# =QQ/7
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 15 Jul 2025 02:32:06 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 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu:
tpm: "qemu -tpmdev help" should return success
ui/gtk: Add scale option
ui/gtk: Add keep-aspect-ratio option
hw/display: Allow injection of virtio-gpu EDID name
ui/spice: Blit the scanout texture if its memory layout is not linear
ui/spice: Create a new texture with linear layout when gl=on is specified
ui/console-gl: Add a helper to create a texture with linear memory layout
ui/spice: Add an option to submit gl_draw requests at fixed rate
ui/spice: Add an option for users to provide a preferred video codec
ui/spice: Enable gl=on option for non-local or remote clients
ui/egl-helpers: Error check the fds in egl_dmabuf_export_texture()
ui/vnc: Introduce the VncWorker type
ui/vnc: Do not copy z_stream
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
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>
Venus and later native contexts have their own fence context along with
multiple timelines within. Fences wtih VIRTIO_GPU_FLAG_INFO_RING_IDX in
the flags must be dispatched to be created on the target context. Fence
signaling also has to be handled on the specific timeline within that
target context.
Before this change, venus fencing is completely broken if the host
driver doesn't support implicit fencing with external memory objects.
Frames can go backwards along with random artifacts on screen if the
host driver doesn't attach an implicit fence to the render target. The
symptom could be hidden by certain guest wsi backend that waits on a
venus native VkFence object for the actual payload with limited present
modes or under special configs. e.g. x11 mailbox or xwayland.
After this change, everything related to venus fencing starts making
sense. Confirmed this via guest and host side perfetto tracing.
Cc: qemu-stable@nongnu.org
Fixes: 94d0ea1c19 ("virtio-gpu: Support Venus context")
Signed-off-by: Yiwei Zhang <zzyiwei@gmail.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Message-Id: <20250518152651.334115-1-zzyiwei@gmail.com>
[AJB: remove version history from commit message]
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20250627112512.1880708-16-alex.bennee@linaro.org>
