f89761d3 | 02-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
vga: move dirty memory region code together
Take into account split screen mode close to wrap around, which is the other special case for dirty memory region computation.
Signed-off-by: Paolo Bonzi
vga: move dirty memory region code together
Take into account split screen mode close to wrap around, which is the other special case for dirty memory region computation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
ab75ecb7 | 02-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
vga: optimize computation of dirty memory region
The depth == 0 and depth == 15 have to be special cased because width * depth / 8 does not provide the correct scanline length. However, thanks to th
vga: optimize computation of dirty memory region
The depth == 0 and depth == 15 have to be special cased because width * depth / 8 does not provide the correct scanline length. However, thanks to the recent reorganization of vga_draw_graphic() the correct value of VRAM bits per pixel is available in "bits".
Use it (via the same "bwidth" computation that is used later in the function), thus restricting the slow path to the wraparound case.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
ba28e0ff | 04-Apr-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/display/virtio-gpu: Protect from DMA re-entrancy bugs
Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() so the bus and device use the same guard. Otherwise the DMA-reentrancy protection ca
hw/display/virtio-gpu: Protect from DMA re-entrancy bugs
Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() so the bus and device use the same guard. Otherwise the DMA-reentrancy protection can be bypassed:
$ cat << EOF | qemu-system-i386 -display none -nodefaults \ -machine q35,accel=qtest \ -m 512M \ -device virtio-gpu \ -qtest stdio outl 0xcf8 0x80000820 outl 0xcfc 0xe0004000 outl 0xcf8 0x80000804 outw 0xcfc 0x06 write 0xe0004030 0x4 0x024000e0 write 0xe0004028 0x1 0xff write 0xe0004020 0x4 0x00009300 write 0xe000401c 0x1 0x01 write 0x101 0x1 0x04 write 0x103 0x1 0x1c write 0x9301c8 0x1 0x18 write 0x105 0x1 0x1c write 0x107 0x1 0x1c write 0x109 0x1 0x1c write 0x10b 0x1 0x00 write 0x10d 0x1 0x00 write 0x10f 0x1 0x00 write 0x111 0x1 0x00 write 0x113 0x1 0x00 write 0x115 0x1 0x00 write 0x117 0x1 0x00 write 0x119 0x1 0x00 write 0x11b 0x1 0x00 write 0x11d 0x1 0x00 write 0x11f 0x1 0x00 write 0x121 0x1 0x00 write 0x123 0x1 0x00 write 0x125 0x1 0x00 write 0x127 0x1 0x00 write 0x129 0x1 0x00 write 0x12b 0x1 0x00 write 0x12d 0x1 0x00 write 0x12f 0x1 0x00 write 0x131 0x1 0x00 write 0x133 0x1 0x00 write 0x135 0x1 0x00 write 0x137 0x1 0x00 write 0x139 0x1 0x00 write 0xe0007003 0x1 0x00 EOF ... ================================================================= ==276099==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000011178 at pc 0x562cc3b736c7 bp 0x7ffed49dee60 sp 0x7ffed49dee58 READ of size 8 at 0x60d000011178 thread T0 #0 0x562cc3b736c6 in virtio_gpu_ctrl_response hw/display/virtio-gpu.c:180:42 #1 0x562cc3b7c40b in virtio_gpu_ctrl_response_nodata hw/display/virtio-gpu.c:192:5 #2 0x562cc3b7c40b in virtio_gpu_simple_process_cmd hw/display/virtio-gpu.c:1015:13 #3 0x562cc3b82873 in virtio_gpu_process_cmdq hw/display/virtio-gpu.c:1050:9 #4 0x562cc4a85514 in aio_bh_call util/async.c:169:5 #5 0x562cc4a85c52 in aio_bh_poll util/async.c:216:13 #6 0x562cc4a1a79b in aio_dispatch util/aio-posix.c:423:5 #7 0x562cc4a8a2da in aio_ctx_dispatch util/async.c:358:5 #8 0x7f36840547a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) #9 0x562cc4a8b753 in glib_pollfds_poll util/main-loop.c:290:9 #10 0x562cc4a8b753 in os_host_main_loop_wait util/main-loop.c:313:5 #11 0x562cc4a8b753 in main_loop_wait util/main-loop.c:592:11 #12 0x562cc3938186 in qemu_main_loop system/runstate.c:782:9 #13 0x562cc43b7af5 in qemu_default_main system/main.c:37:14 #14 0x7f3683a6c189 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #15 0x7f3683a6c244 in __libc_start_main csu/../csu/libc-start.c:381:3 #16 0x562cc2a58ac0 in _start (qemu-system-i386+0x231bac0)
0x60d000011178 is located 56 bytes inside of 136-byte region [0x60d000011140,0x60d0000111c8) freed by thread T0 here: #0 0x562cc2adb662 in __interceptor_free (qemu-system-i386+0x239e662) #1 0x562cc3b86b21 in virtio_gpu_reset hw/display/virtio-gpu.c:1524:9 #2 0x562cc416e20e in virtio_reset hw/virtio/virtio.c:2145:9 #3 0x562cc37c5644 in virtio_pci_reset hw/virtio/virtio-pci.c:2249:5 #4 0x562cc4233758 in memory_region_write_accessor system/memory.c:497:5 #5 0x562cc4232eea in access_with_adjusted_size system/memory.c:573:18
previously allocated by thread T0 here: #0 0x562cc2adb90e in malloc (qemu-system-i386+0x239e90e) #1 0x7f368405a678 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5a678) #2 0x562cc4163ffc in virtqueue_split_pop hw/virtio/virtio.c:1612:12 #3 0x562cc4163ffc in virtqueue_pop hw/virtio/virtio.c:1783:16 #4 0x562cc3b91a95 in virtio_gpu_handle_ctrl hw/display/virtio-gpu.c:1112:15 #5 0x562cc4a85514 in aio_bh_call util/async.c:169:5 #6 0x562cc4a85c52 in aio_bh_poll util/async.c:216:13 #7 0x562cc4a1a79b in aio_dispatch util/aio-posix.c:423:5
SUMMARY: AddressSanitizer: heap-use-after-free hw/display/virtio-gpu.c:180:42 in virtio_gpu_ctrl_response
With this change, the same reproducer triggers:
qemu-system-i386: warning: Blocked re-entrant IO on MemoryRegion: virtio-pci-common-virtio-gpu at addr: 0x6
Fixes: CVE-2024-3446 Cc: qemu-stable@nongnu.org Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Yongkang Jia <kangel@zju.edu.cn> Reported-by: Xiao Lei <nop.leixiao@gmail.com> Reported-by: Yiming Tao <taoym@zju.edu.cn> Buglink: https://bugs.launchpad.net/qemu/+bug/1888606 Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-3-philmd@linaro.org>
show more ...
|
1d1ee7e0 | 02-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
vga: do not treat horiz pel panning value of 8 as "enabled"
Horizontal pel panning bit 3 is only used in text mode. In graphics mode, it can be treated as if it was zero, thus not extending the dir
vga: do not treat horiz pel panning value of 8 as "enabled"
Horizontal pel panning bit 3 is only used in text mode. In graphics mode, it can be treated as if it was zero, thus not extending the dirty memory region.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
3b6d2b19 | 02-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
vga: adjust dirty memory region if pel panning is active
When pel panning is active, one more byte is read from each of the VGA memory planes. This has to be accounted in the computation of region_
vga: adjust dirty memory region if pel panning is active
When pel panning is active, one more byte is read from each of the VGA memory planes. This has to be accounted in the computation of region_end, otherwise vga_draw_graphic() fails an assertion:
qemu-system-i386: ../system/physmem.c:946: cpu_physical_memory_snapshot_get_dirty: Assertion `start + length <= snap->end' failed.
Reported-by: Helge Konetzka <hk@zapateado.de> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2244 Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
3826a372 | 02-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
vga: move computation of dirty memory region later
Move the computation of region_start and region_end after the value of "bits" is known. This makes it possible to distinguish modes that support h
vga: move computation of dirty memory region later
Move the computation of region_start and region_end after the value of "bits" is known. This makes it possible to distinguish modes that support horizontal pel panning from modes that do not.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
dfcf74fa | 15-Jan-2024 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
virtio-gpu: fix scanout migration post-load
The current post-loading code for scanout has a FIXME: it doesn't take the resource region/rect into account. But there is more, when adding blob migratio
virtio-gpu: fix scanout migration post-load
The current post-loading code for scanout has a FIXME: it doesn't take the resource region/rect into account. But there is more, when adding blob migration support in commit f66767f75c9, I didn't realize that blob resources could be used for scanouts. This situationn leads to a crash during post-load, as they don't have an associated res->image.
virtio_gpu_do_set_scanout() handle all cases, but requires the associated virtio_gpu_framebuffer, which is currently not saved during migration.
Add a v2 of "virtio-gpu-one-scanout" with the framebuffer fields, so we can restore blob scanouts, as well as fixing the existing FIXME.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Sebastian Ott <sebott@redhat.com>
show more ...
|
ee1004bb | 29-Jan-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
bulk: Access existing variables initialized to &S->F when available
When a variable is initialized to &struct->field, use it in place. Rationale: while this makes the code more concise, this also he
bulk: Access existing variables initialized to &S->F when available
When a variable is initialized to &struct->field, use it in place. Rationale: while this makes the code more concise, this also helps static analyzers.
Mechanical change using the following Coccinelle spatch script:
@@ type S, F; identifier s, m, v; @@ S *s; ... F *v = &s->m; <+... - &s->m + v ...+>
Inspired-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240129164514.73104-2-philmd@linaro.org> Acked-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> [thuth: Dropped hunks that need a rebase, and fixed sizeof() in pmu_realize()] Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
6d73fff3 | 22-Sep-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/display/exynos4210_fimd: Pass frame buffer memory region as link
Add the Exynos4210fimdState::'framebuffer-memory' property. Have the board set it. We don't need to call sysbus_address_space() an
hw/display/exynos4210_fimd: Pass frame buffer memory region as link
Add the Exynos4210fimdState::'framebuffer-memory' property. Have the board set it. We don't need to call sysbus_address_space() anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20240226173805.289-5-philmd@linaro.org>
show more ...
|
588a09da | 30-Jan-2024 |
Manos Pitsidianakis <manos.pitsidianakis@linaro.org> |
virtio-gpu-rutabaga.c: override resource_destroy method
When the Rutabaga GPU device frees resources, it calls rutabaga_resource_unref for that resource_id. However, when the generic VirtIOGPU funct
virtio-gpu-rutabaga.c: override resource_destroy method
When the Rutabaga GPU device frees resources, it calls rutabaga_resource_unref for that resource_id. However, when the generic VirtIOGPU functions destroys resources, it only removes the virtio_gpu_simple_resource from the device's VirtIOGPU->reslist list. The rutabaga resource associated with that resource_id is then leaked.
This commit overrides the resource_destroy class method introduced in the previous commit to fix this.
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <e3778e44c98a35839de2f4938e5355449fa3aa14.1706626470.git.manos.pitsidianakis@linaro.org> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
330399bd | 30-Jan-2024 |
Manos Pitsidianakis <manos.pitsidianakis@linaro.org> |
virtio-gpu.c: add resource_destroy class method
When destroying/unrefing resources, devices such as virtio-gpu-rutabaga need to do their own bookkeeping (free rutabaga resources that are associated
virtio-gpu.c: add resource_destroy class method
When destroying/unrefing resources, devices such as virtio-gpu-rutabaga need to do their own bookkeeping (free rutabaga resources that are associated with the virtio_gpu_simple_resource).
This commit adds a class method so that virtio-gpu-rutabaga can override it in the next commit.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <b0a86630c4d601f3a269fd7e08cfefc13bd4e219.1706626470.git.manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
8b162082 | 30-Jan-2024 |
Manos Pitsidianakis <manos.pitsidianakis@linaro.org> |
hw/display/virtio-gpu.c: use reset_bh class method
While the VirtioGPU type has a reset_bh field to specify a reset callback, it's never used. virtio_gpu_reset() calls the general virtio_gpu_reset_b
hw/display/virtio-gpu.c: use reset_bh class method
While the VirtioGPU type has a reset_bh field to specify a reset callback, it's never used. virtio_gpu_reset() calls the general virtio_gpu_reset_bh() function for all devices that inherit from VirtioGPU.
While no devices override reset_bh at the moment, a device reset might require special logic for implementations in the future.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <87fb4fa72ce5b341a6f957513a00dcb79fd5997f.1706626470.git.manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
43526260 | 29-Dec-2014 |
Paolo Bonzini <pbonzini@redhat.com> |
vga: sort-of implement word and double-word access modes
Jazz Jackrabbit has a very unusual VGA setup, where it uses odd/even mode with 256-color graphics. Probably, it wants to use fast VRAM-to-VR
vga: sort-of implement word and double-word access modes
Jazz Jackrabbit has a very unusual VGA setup, where it uses odd/even mode with 256-color graphics. Probably, it wants to use fast VRAM-to-VRAM copies without having to store 4 copies of the sprites as needed in mode X, one for each mod-4 alignment; odd/even mode simplifies the code a lot if it's okay to place on a 160-pixels horizontal grid.
At the same time, because it wants to use double buffering (a la "mode X") it uses byte mode, not word mode as is the case in text modes. In order to implement the combination of odd/even mode (plane number comes from bit 0 of the address) and byte mode (use all bytes of VRAM, whereas word mode only uses bytes 0, 2, 4,... on each of the four planes), we need to separate the effect on the plane number from the effect on the address.
Implementing the modes properly is a mess in QEMU, because it would change the layout of VRAM and break migration. As an approximation, shift right when the CPU accesses memory instead of shifting left when the CRT controller reads it. A hack is needed in order to write font data properly (see comment in the code), but it works well enough for the game.
Because doubleword and chain4 modes are now independent, chain4 does not assert anymore that the address is in range. Instead it just returns all ones and discards writes, like other modes.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
3f834350 | 30-Dec-2014 |
Paolo Bonzini <pbonzini@redhat.com> |
vga: use latches in odd/even mode too
Jazz Jackrabbit uses odd/even mode with 256-color graphics. This is probably so that it can do very fast blitting with a decent resolution (two pixels, compare
vga: use latches in odd/even mode too
Jazz Jackrabbit uses odd/even mode with 256-color graphics. This is probably so that it can do very fast blitting with a decent resolution (two pixels, compared to four pixels for "regular" mode X).
Accesses still use all planes (reads go to the latches and the game uses read mode 1 so that the CPU always gets 0xFF; writes use the plane mask register because the game sets bit 2 of the sequencer's memory mode register). For this to work, QEMU needs to use the code for latched memory accesses in odd/even mode. The only difference between odd/even mode and "regular" planar mode is how the plane is computed in read mode 0, and how the planes are masked if the aforementioned bit 2 is reset.
It is almost enough to fix the game. You also need to honor byte/word mode selection, which is done in the next patch.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|