<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu/drm/virtio, branch v6.15</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>virtgpu: don't reset on shutdown</title>
<updated>2025-04-18T14:05:49+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2025-04-10T07:16:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=183a08715af1491d381b4e22efd61578fbe05fa5'/>
<id>183a08715af1491d381b4e22efd61578fbe05fa5</id>
<content type='text'>
It looks like GPUs are used after shutdown is invoked.
Thus, breaking virtio gpu in the shutdown callback is not a good idea -
guest hangs attempting to finish console drawing, with these warnings:

[   20.504464] WARNING: CPU: 0 PID: 568 at drivers/gpu/drm/virtio/virtgpu_vq.c:358 virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.505685] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink vfat fat intel_rapl_msr intel_rapl_common intel_uncore_frequency_common nfit libnvdimm kvm_intel kvm rapl iTCO_wdt iTCO_vendor_support virtio_gpu virtio_dma_buf pcspkr drm_shmem_helper i2c_i801 drm_kms_helper lpc_ich i2c_smbus virtio_balloon joydev drm fuse xfs libcrc32c ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata virtio_net ghash_clmulni_intel net_failover virtio_blk failover serio_raw dm_mirror dm_region_hash dm_log dm_mod
[   20.511847] CPU: 0 PID: 568 Comm: kworker/0:3 Kdump: loaded Tainted: G        W         -------  ---  5.14.0-578.6675_1757216455.el9.x86_64 #1
[   20.513157] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20241117-3.el9 11/17/2024
[   20.513918] Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
[   20.514626] RIP: 0010:virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.515332] Code: 00 00 48 85 c0 74 0c 48 8b 78 08 48 89 ee e8 51 50 00 00 65 ff 0d 42 e3 74 3f 0f 85 69 ff ff ff 0f 1f 44 00 00 e9 5f ff ff ff &lt;0f&gt; 0b e9 3f ff ff ff 48 83 3c 24 00 74 0e 49 8b 7f 40 48 85 ff 74
[   20.517272] RSP: 0018:ff34f0a8c0787ad8 EFLAGS: 00010282
[   20.517820] RAX: 00000000fffffffb RBX: 0000000000000000 RCX: 0000000000000820
[   20.518565] RDX: 0000000000000000 RSI: ff34f0a8c0787be0 RDI: ff218bef03a26300
[   20.519308] RBP: ff218bef03a26300 R08: 0000000000000001 R09: ff218bef07224360
[   20.520059] R10: 0000000000008dc0 R11: 0000000000000002 R12: ff218bef02630028
[   20.520806] R13: ff218bef0263fb48 R14: ff218bef00cb8000 R15: ff218bef07224360
[   20.521555] FS:  0000000000000000(0000) GS:ff218bef7ba00000(0000) knlGS:0000000000000000
[   20.522397] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   20.522996] CR2: 000055ac4f7871c0 CR3: 000000010b9f2002 CR4: 0000000000771ef0
[   20.523740] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   20.524477] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[   20.525223] PKRU: 55555554
[   20.525515] Call Trace:
[   20.525777]  &lt;TASK&gt;
[   20.526003]  ? show_trace_log_lvl+0x1c4/0x2df
[   20.526464]  ? show_trace_log_lvl+0x1c4/0x2df
[   20.526925]  ? virtio_gpu_queue_fenced_ctrl_buffer+0x82/0x2c0 [virtio_gpu]
[   20.527643]  ? virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.528282]  ? __warn+0x7e/0xd0
[   20.528621]  ? virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.529256]  ? report_bug+0x100/0x140
[   20.529643]  ? handle_bug+0x3c/0x70
[   20.530010]  ? exc_invalid_op+0x14/0x70
[   20.530421]  ? asm_exc_invalid_op+0x16/0x20
[   20.530862]  ? virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.531506]  ? virtio_gpu_queue_ctrl_sgs+0x174/0x290 [virtio_gpu]
[   20.532148]  virtio_gpu_queue_fenced_ctrl_buffer+0x82/0x2c0 [virtio_gpu]
[   20.532843]  virtio_gpu_primary_plane_update+0x3e2/0x460 [virtio_gpu]
[   20.533520]  drm_atomic_helper_commit_planes+0x108/0x320 [drm_kms_helper]
[   20.534233]  drm_atomic_helper_commit_tail+0x45/0x80 [drm_kms_helper]
[   20.534914]  commit_tail+0xd2/0x130 [drm_kms_helper]
[   20.535446]  drm_atomic_helper_commit+0x11b/0x140 [drm_kms_helper]
[   20.536097]  drm_atomic_commit+0xa4/0xe0 [drm]
[   20.536588]  ? __pfx___drm_printfn_info+0x10/0x10 [drm]
[   20.537162]  drm_atomic_helper_dirtyfb+0x192/0x270 [drm_kms_helper]
[   20.537823]  drm_fbdev_shmem_helper_fb_dirty+0x43/0xa0 [drm_shmem_helper]
[   20.538536]  drm_fb_helper_damage_work+0x87/0x160 [drm_kms_helper]
[   20.539188]  process_one_work+0x194/0x380
[   20.539612]  worker_thread+0x2fe/0x410
[   20.540007]  ? __pfx_worker_thread+0x10/0x10
[   20.540456]  kthread+0xdd/0x100
[   20.540791]  ? __pfx_kthread+0x10/0x10
[   20.541190]  ret_from_fork+0x29/0x50
[   20.541566]  &lt;/TASK&gt;
[   20.541802] ---[ end trace 0000000000000000 ]---

It looks like the shutdown is called in the middle of console drawing, so
we should either wait for it to finish, or let drm handle the shutdown.

This patch implements this second option:

Add an option for drivers to bypass the common break+reset handling.
As DRM is careful to flush/synchronize outstanding buffers, it looks like
GPU can just have a NOP there.

Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Tested-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()")
Cc: Eric Auger &lt;eauger@redhat.com&gt;
Cc: Jocelyn Falempe &lt;jfalempe@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Message-Id: &lt;8490dbeb6f79ed039e6c11d121002618972538a3.1744293540.git.mst@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It looks like GPUs are used after shutdown is invoked.
Thus, breaking virtio gpu in the shutdown callback is not a good idea -
guest hangs attempting to finish console drawing, with these warnings:

[   20.504464] WARNING: CPU: 0 PID: 568 at drivers/gpu/drm/virtio/virtgpu_vq.c:358 virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.505685] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink vfat fat intel_rapl_msr intel_rapl_common intel_uncore_frequency_common nfit libnvdimm kvm_intel kvm rapl iTCO_wdt iTCO_vendor_support virtio_gpu virtio_dma_buf pcspkr drm_shmem_helper i2c_i801 drm_kms_helper lpc_ich i2c_smbus virtio_balloon joydev drm fuse xfs libcrc32c ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata virtio_net ghash_clmulni_intel net_failover virtio_blk failover serio_raw dm_mirror dm_region_hash dm_log dm_mod
[   20.511847] CPU: 0 PID: 568 Comm: kworker/0:3 Kdump: loaded Tainted: G        W         -------  ---  5.14.0-578.6675_1757216455.el9.x86_64 #1
[   20.513157] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20241117-3.el9 11/17/2024
[   20.513918] Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
[   20.514626] RIP: 0010:virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.515332] Code: 00 00 48 85 c0 74 0c 48 8b 78 08 48 89 ee e8 51 50 00 00 65 ff 0d 42 e3 74 3f 0f 85 69 ff ff ff 0f 1f 44 00 00 e9 5f ff ff ff &lt;0f&gt; 0b e9 3f ff ff ff 48 83 3c 24 00 74 0e 49 8b 7f 40 48 85 ff 74
[   20.517272] RSP: 0018:ff34f0a8c0787ad8 EFLAGS: 00010282
[   20.517820] RAX: 00000000fffffffb RBX: 0000000000000000 RCX: 0000000000000820
[   20.518565] RDX: 0000000000000000 RSI: ff34f0a8c0787be0 RDI: ff218bef03a26300
[   20.519308] RBP: ff218bef03a26300 R08: 0000000000000001 R09: ff218bef07224360
[   20.520059] R10: 0000000000008dc0 R11: 0000000000000002 R12: ff218bef02630028
[   20.520806] R13: ff218bef0263fb48 R14: ff218bef00cb8000 R15: ff218bef07224360
[   20.521555] FS:  0000000000000000(0000) GS:ff218bef7ba00000(0000) knlGS:0000000000000000
[   20.522397] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   20.522996] CR2: 000055ac4f7871c0 CR3: 000000010b9f2002 CR4: 0000000000771ef0
[   20.523740] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   20.524477] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[   20.525223] PKRU: 55555554
[   20.525515] Call Trace:
[   20.525777]  &lt;TASK&gt;
[   20.526003]  ? show_trace_log_lvl+0x1c4/0x2df
[   20.526464]  ? show_trace_log_lvl+0x1c4/0x2df
[   20.526925]  ? virtio_gpu_queue_fenced_ctrl_buffer+0x82/0x2c0 [virtio_gpu]
[   20.527643]  ? virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.528282]  ? __warn+0x7e/0xd0
[   20.528621]  ? virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.529256]  ? report_bug+0x100/0x140
[   20.529643]  ? handle_bug+0x3c/0x70
[   20.530010]  ? exc_invalid_op+0x14/0x70
[   20.530421]  ? asm_exc_invalid_op+0x16/0x20
[   20.530862]  ? virtio_gpu_queue_ctrl_sgs+0x236/0x290 [virtio_gpu]
[   20.531506]  ? virtio_gpu_queue_ctrl_sgs+0x174/0x290 [virtio_gpu]
[   20.532148]  virtio_gpu_queue_fenced_ctrl_buffer+0x82/0x2c0 [virtio_gpu]
[   20.532843]  virtio_gpu_primary_plane_update+0x3e2/0x460 [virtio_gpu]
[   20.533520]  drm_atomic_helper_commit_planes+0x108/0x320 [drm_kms_helper]
[   20.534233]  drm_atomic_helper_commit_tail+0x45/0x80 [drm_kms_helper]
[   20.534914]  commit_tail+0xd2/0x130 [drm_kms_helper]
[   20.535446]  drm_atomic_helper_commit+0x11b/0x140 [drm_kms_helper]
[   20.536097]  drm_atomic_commit+0xa4/0xe0 [drm]
[   20.536588]  ? __pfx___drm_printfn_info+0x10/0x10 [drm]
[   20.537162]  drm_atomic_helper_dirtyfb+0x192/0x270 [drm_kms_helper]
[   20.537823]  drm_fbdev_shmem_helper_fb_dirty+0x43/0xa0 [drm_shmem_helper]
[   20.538536]  drm_fb_helper_damage_work+0x87/0x160 [drm_kms_helper]
[   20.539188]  process_one_work+0x194/0x380
[   20.539612]  worker_thread+0x2fe/0x410
[   20.540007]  ? __pfx_worker_thread+0x10/0x10
[   20.540456]  kthread+0xdd/0x100
[   20.540791]  ? __pfx_kthread+0x10/0x10
[   20.541190]  ret_from_fork+0x29/0x50
[   20.541566]  &lt;/TASK&gt;
[   20.541802] ---[ end trace 0000000000000000 ]---

It looks like the shutdown is called in the middle of console drawing, so
we should either wait for it to finish, or let drm handle the shutdown.

This patch implements this second option:

Add an option for drivers to bypass the common break+reset handling.
As DRM is careful to flush/synchronize outstanding buffers, it looks like
GPU can just have a NOP there.

Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Tested-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()")
Cc: Eric Auger &lt;eauger@redhat.com&gt;
Cc: Jocelyn Falempe &lt;jfalempe@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Message-Id: &lt;8490dbeb6f79ed039e6c11d121002618972538a3.1744293540.git.mst@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge drm/drm-fixes into drm-misc-fixes</title>
<updated>2025-04-08T08:15:47+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2025-04-08T08:15:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1260ed77798502de9c98020040d2995008de10cc'/>
<id>1260ed77798502de9c98020040d2995008de10cc</id>
<content type='text'>
Backmerging to get updates from v6.15-rc1.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Backmerging to get updates from v6.15-rc1.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/virtio: Fix missed dmabuf unpinning in error path of prepare_fb()</title>
<updated>2025-04-01T20:11:55+00:00</updated>
<author>
<name>Dmitry Osipenko</name>
<email>dmitry.osipenko@collabora.com</email>
</author>
<published>2025-04-01T12:38:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=395cc80051f8da267b27496a4029dd931a198855'/>
<id>395cc80051f8da267b27496a4029dd931a198855</id>
<content type='text'>
Correct error handling in prepare_fb() to fix leaking resources when
error happens.

Fixes: 4a696a2ee646 ("drm/virtio: Add prepare and cleanup routines for imported dmabuf obj")
Cc: &lt;stable@vger.kernel.org&gt; # v6.14+
Acked-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://lore.kernel.org/r/20250401123842.2232205-2-dmitry.osipenko@collabora.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Correct error handling in prepare_fb() to fix leaking resources when
error happens.

Fixes: 4a696a2ee646 ("drm/virtio: Add prepare and cleanup routines for imported dmabuf obj")
Cc: &lt;stable@vger.kernel.org&gt; # v6.14+
Acked-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://lore.kernel.org/r/20250401123842.2232205-2-dmitry.osipenko@collabora.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/virtio: Don't attach GEM to a non-created context in gem_object_open()</title>
<updated>2025-04-01T20:11:54+00:00</updated>
<author>
<name>Dmitry Osipenko</name>
<email>dmitry.osipenko@collabora.com</email>
</author>
<published>2025-04-01T12:38:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7cf6dd467e87664f5b3f4ca7be324569464edf0b'/>
<id>7cf6dd467e87664f5b3f4ca7be324569464edf0b</id>
<content type='text'>
The vfpriv-&gt;ctx_id is always initialized to a non-zero value. Check whether
context was created before attaching GEM to this context ID. This left
unnoticed previously because host silently skips attachment if context
doesn't exist, still we shouldn't do that for consistency.

Fixes: 086b9f27f0ab ("drm/virtio: Don't create a context with default param if context_init is supported")
Cc: &lt;stable@vger.kernel.org&gt; # v6.14+
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Reviewed-by: Rob Clark &lt;robdclark@gmail.com&gt;
Link: https://lore.kernel.org/r/20250401123842.2232205-1-dmitry.osipenko@collabora.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The vfpriv-&gt;ctx_id is always initialized to a non-zero value. Check whether
context was created before attaching GEM to this context ID. This left
unnoticed previously because host silently skips attachment if context
doesn't exist, still we shouldn't do that for consistency.

Fixes: 086b9f27f0ab ("drm/virtio: Don't create a context with default param if context_init is supported")
Cc: &lt;stable@vger.kernel.org&gt; # v6.14+
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Reviewed-by: Rob Clark &lt;robdclark@gmail.com&gt;
Link: https://lore.kernel.org/r/20250401123842.2232205-1-dmitry.osipenko@collabora.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/virtio: Fix flickering issue seen with imported dmabufs</title>
<updated>2025-03-26T20:59:41+00:00</updated>
<author>
<name>Vivek Kasireddy</name>
<email>vivek.kasireddy@intel.com</email>
</author>
<published>2025-03-25T20:10:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3d50e61a17b642af060566acb0eabe3c0eb3ef1f'/>
<id>3d50e61a17b642af060566acb0eabe3c0eb3ef1f</id>
<content type='text'>
We need to save the reservation object pointer associated with the
imported dmabuf in the newly created GEM object to allow
drm_gem_plane_helper_prepare_fb() to extract the exclusive fence
from it and attach it to the plane state during prepare phase.
This is needed to ensure that drm_atomic_helper_wait_for_fences()
correctly waits for the relevant fences (move, etc) associated with
the reservation object, thereby implementing proper synchronization.

Otherwise, artifacts or slight flickering can be seen when apps
are dragged across the screen when running Gnome (Wayland). This
problem is mostly seen with dGPUs in the case where the FBs are
allocated in VRAM but need to be migrated to System RAM as they
are shared with virtio-gpu.

Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs")
Cc: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Cc: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Cc: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Cc: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Signed-off-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
[dmitry.osipenko@collabora.com: Moved assignment before object_init()]
Link: https://patchwork.freedesktop.org/patch/msgid/20250325201021.1315080-1-vivek.kasireddy@intel.com

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We need to save the reservation object pointer associated with the
imported dmabuf in the newly created GEM object to allow
drm_gem_plane_helper_prepare_fb() to extract the exclusive fence
from it and attach it to the plane state during prepare phase.
This is needed to ensure that drm_atomic_helper_wait_for_fences()
correctly waits for the relevant fences (move, etc) associated with
the reservation object, thereby implementing proper synchronization.

Otherwise, artifacts or slight flickering can be seen when apps
are dragged across the screen when running Gnome (Wayland). This
problem is mostly seen with dGPUs in the case where the FBs are
allocated in VRAM but need to be migrated to System RAM as they
are shared with virtio-gpu.

Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs")
Cc: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Cc: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Cc: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Cc: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Signed-off-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
[dmitry.osipenko@collabora.com: Moved assignment before object_init()]
Link: https://patchwork.freedesktop.org/patch/msgid/20250325201021.1315080-1-vivek.kasireddy@intel.com

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/virtio: Add drm_panic support</title>
<updated>2025-02-09T17:36:51+00:00</updated>
<author>
<name>Ryosuke Yasuoka</name>
<email>ryasuoka@redhat.com</email>
</author>
<published>2025-02-06T10:42:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6f3d9d0dd335290fa364048de5b3a440f1cf259f'/>
<id>6f3d9d0dd335290fa364048de5b3a440f1cf259f</id>
<content type='text'>
Virtio gpu supports the drm_panic module, which displays a message to
the screen when a kernel panic occurs. It is supported where it has
vmapped shmem BO.

Signed-off-by: Jocelyn Falempe &lt;jfalempe@redhat.com&gt;
Signed-off-by: Ryosuke Yasuoka &lt;ryasuoka@redhat.com&gt;
Tested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20250206104300.416014-1-ryasuoka@redhat.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Virtio gpu supports the drm_panic module, which displays a message to
the screen when a kernel panic occurs. It is supported where it has
vmapped shmem BO.

Signed-off-by: Jocelyn Falempe &lt;jfalempe@redhat.com&gt;
Signed-off-by: Ryosuke Yasuoka &lt;ryasuoka@redhat.com&gt;
Tested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20250206104300.416014-1-ryasuoka@redhat.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/virtio: Support partial maps of GEM objects</title>
<updated>2025-01-24T21:16:57+00:00</updated>
<author>
<name>Sasha Finkelstein</name>
<email>fnkl.kernel@gmail.com</email>
</author>
<published>2025-01-09T21:45:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7f3b11934f9684038555fd9160e188d6893949b9'/>
<id>7f3b11934f9684038555fd9160e188d6893949b9</id>
<content type='text'>
Those are useful to implement coherent cross-vm mmap.

Signed-off-by: Sasha Finkelstein &lt;fnkl.kernel@gmail.com&gt;
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Tested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20250109-virtgpu-gem-partial-map-v1-1-a914b48776bd@gmail.com
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
[dmitry.osipenko@collabora.com: Corrected vm_size check to account vm_pgoff]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Those are useful to implement coherent cross-vm mmap.

Signed-off-by: Sasha Finkelstein &lt;fnkl.kernel@gmail.com&gt;
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Tested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20250109-virtgpu-gem-partial-map-v1-1-a914b48776bd@gmail.com
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
[dmitry.osipenko@collabora.com: Corrected vm_size check to account vm_pgoff]
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/virtio: Don't return error if virtio-gpu PCI dev is not found</title>
<updated>2025-01-19T12:24:27+00:00</updated>
<author>
<name>Vivek Kasireddy</name>
<email>vivek.kasireddy@intel.com</email>
</author>
<published>2025-01-14T07:57:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6568d423cb3000789b2b8493049883fcec09c329'/>
<id>6568d423cb3000789b2b8493049883fcec09c329</id>
<content type='text'>
While fixing a shared VGA resource ownership issue, commit 5dd8b536bbda
("drm/virtio: Lock the VGA resources during initialization") wrongly
assumed that there is always a PCI device associated with virtio-gpu
and it would return error if this device is not found during init.

This is incorrect, as virtio-gpu can be operated in MMIO mode (M68K)
where a PCI device would probably not be created for it. Therefore,
fix this issue by not erroring out if the associated PCI device is
not found during initialization.

Fixes: 5dd8b536bbda ("drm/virtio: Lock the VGA resources during initialization")
Suggested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Cc: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Cc: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Cc: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Signed-off-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20250114075759.2616551-1-vivek.kasireddy@intel.com
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20250114075759.2616551-1-vivek.kasireddy@intel.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While fixing a shared VGA resource ownership issue, commit 5dd8b536bbda
("drm/virtio: Lock the VGA resources during initialization") wrongly
assumed that there is always a PCI device associated with virtio-gpu
and it would return error if this device is not found during init.

This is incorrect, as virtio-gpu can be operated in MMIO mode (M68K)
where a PCI device would probably not be created for it. Therefore,
fix this issue by not erroring out if the associated PCI device is
not found during initialization.

Fixes: 5dd8b536bbda ("drm/virtio: Lock the VGA resources during initialization")
Suggested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Cc: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Cc: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Cc: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Signed-off-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20250114075759.2616551-1-vivek.kasireddy@intel.com
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20250114075759.2616551-1-vivek.kasireddy@intel.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/virtio: Fix UAF in virtgpu_dma_buf_free_obj()</title>
<updated>2025-01-19T12:12:28+00:00</updated>
<author>
<name>Vivek Kasireddy</name>
<email>vivek.kasireddy@intel.com</email>
</author>
<published>2024-12-12T05:54:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=db8b2c0e2abc90d1025fd7f6d4461b21b1d3248e'/>
<id>db8b2c0e2abc90d1025fd7f6d4461b21b1d3248e</id>
<content type='text'>
Fix the following issues identified by Smatch static checker:
- The call to dma_buf_put(attach-&gt;dmabuf) after dma_buf_detach()
  leads to a UAF bug as dma_buf_detach() frees the attach object.
  Fix this by extracting the dmabuf object from attach and using
  that in the call to dma_buf_put().

- The resv object is extracted from attach before checking to see
  if attach is valid (that is !NULL) or not. Although, attach would
  very likely be valid, fix this by making sure that the resv object
  is used only after ensuring that attach is valid.

Fixes: 2885e575abc7 ("drm/virtio: Add helpers to initialize and free the imported object")
Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs")
Cc: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Cc: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Cc: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Cc: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20241212055421.775759-1-vivek.kasireddy@intel.com
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Tested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
[dmitry.osipenko@collabora.com: Edited commit title]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix the following issues identified by Smatch static checker:
- The call to dma_buf_put(attach-&gt;dmabuf) after dma_buf_detach()
  leads to a UAF bug as dma_buf_detach() frees the attach object.
  Fix this by extracting the dmabuf object from attach and using
  that in the call to dma_buf_put().

- The resv object is extracted from attach before checking to see
  if attach is valid (that is !NULL) or not. Although, attach would
  very likely be valid, fix this by making sure that the resv object
  is used only after ensuring that attach is valid.

Fixes: 2885e575abc7 ("drm/virtio: Add helpers to initialize and free the imported object")
Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs")
Cc: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Cc: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Cc: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Cc: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20241212055421.775759-1-vivek.kasireddy@intel.com
Reviewed-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Tested-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
[dmitry.osipenko@collabora.com: Edited commit title]
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/virtio: Factor out common dmabuf unmapping code</title>
<updated>2025-01-09T13:53:24+00:00</updated>
<author>
<name>Dmitry Osipenko</name>
<email>dmitry.osipenko@collabora.com</email>
</author>
<published>2024-12-02T05:39:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2ef1c8c5de40316ba65051940e587157385e10c0'/>
<id>2ef1c8c5de40316ba65051940e587157385e10c0</id>
<content type='text'>
Move out dmabuf detachment and unmapping into separate function. This
removes duplicated code and there is no need to check the GEM's kref now,
since both bo-&gt;attached and bo-&gt;sgt are unset under held reservation lock.

Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Acked-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20241202053955.2451321-1-dmitry.osipenko@collabora.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move out dmabuf detachment and unmapping into separate function. This
removes duplicated code and there is no need to check the GEM's kref now,
since both bo-&gt;attached and bo-&gt;sgt are unset under held reservation lock.

Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Acked-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20241202053955.2451321-1-dmitry.osipenko@collabora.com
</pre>
</div>
</content>
</entry>
</feed>
