kernel/linux.git/drivers/gpu/drm/virtio/virtgpu_drv.c, branch v6.19.11

drm: include drm_print.h where needed

2025-10-31T08:34:52+00:00

There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Signed-off-by: Jani Nikula Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com

drm/virtio: implement virtio_gpu_shutdown

2025-08-01T13:11:07+00:00

Calling drm_dev_unplug() is the drm way to say the device is gone and can not be accessed any more. Cc: Michael S. Tsirkin Signed-off-by: Gerd Hoffmann Reviewed-by: Eric Auger Tested-by: Eric Auger Message-Id: <20250507082821.2710706-1-kraxel@redhat.com> Signed-off-by: Michael S. Tsirkin

virtgpu: don't reset on shutdown

2025-04-18T14:05:49+00:00

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 <0f> 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] [ 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] [ 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 Tested-by: Eric Auger Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()") Cc: Eric Auger Cc: Jocelyn Falempe Signed-off-by: Michael S. Tsirkin Message-Id: <8490dbeb6f79ed039e6c11d121002618972538a3.1744293540.git.mst@redhat.com>

drm/virtio: Don't return error if virtio-gpu PCI dev is not found

2025-01-19T12:24:27+00:00

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 Cc: Gerd Hoffmann Cc: Gurchetan Singh Cc: Chia-I Wu Signed-off-by: Vivek Kasireddy Link: https://patchwork.freedesktop.org/patch/msgid/20250114075759.2616551-1-vivek.kasireddy@intel.com Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20250114075759.2616551-1-vivek.kasireddy@intel.com

drm/virtio: Lock the VGA resources during initialization

2025-01-09T13:52:49+00:00

If another driver for a VGA compatible GPU (that is passthrough'd) locks the VGA resources (by calling vga_get()), then virtio_gpu driver would encounter the following errors and fail to load during probe and initialization: Invalid read at addr 0x7200005014, size 1, region '(null)', reason: rejected Invalid write at addr 0x7200005014, size 1, region '(null)', reason: rejected virtio_gpu virtio0: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1 virtio_gpu virtio0: probe with driver virtio_gpu failed with error -22 This issue is only seen if virtio-gpu and the other GPU are on different PCI buses, which can happen if the user includes an additional PCIe port and associates the VGA compatible GPU with it while launching Qemu: qemu-system-x86_64... -device virtio-vga,max_outputs=1,xres=1920,yres=1080,blob=true -device pcie-root-port,id=pcie.1,bus=pcie.0,addr=1c.0,slot=1,chassis=1,multifunction=on -device vfio-pci,host=03:00.0,bus=pcie.1,addr=00.0 ... In the above example, the device 03:00.0 is an Intel DG2 card and this issue is seen when both i915 driver and virtio_gpu driver are loading (or initializing) concurrently or when i915 is loaded first. Note that during initalization, i915 driver does the following in intel_vga_reset_io_mem(): vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); outb(inb(VGA_MIS_R), VGA_MIS_W); vga_put(pdev, VGA_RSRC_LEGACY_IO); Although, virtio-gpu might own the VGA resources initially, the above call (in i915) to vga_get_uninterruptible() would result in these resources being taken away, which means that virtio-gpu would not be able to decode VGA anymore. This happens in __vga_tryget() when it calls pci_set_vga_state(conflict->pdev, false, pci_bits, flags); where pci_bits = PCI_COMMAND_MEMORY | PCI_COMMAND_IO flags = PCI_VGA_STATE_CHANGE_DECODES | PCI_VGA_STATE_CHANGE_BRIDGE Therefore, to solve this issue, virtio-gpu driver needs to call vga_get() whenever it needs to reclaim and access VGA resources, which is during initial probe and setup. After that, a call to vga_put() would release the lock to allow other VGA compatible devices to access these shared VGA resources. Cc: Gerd Hoffmann Cc: Gurchetan Singh Cc: Chia-I Wu Reported-by: Dmitry Osipenko Signed-off-by: Vivek Kasireddy Link: https://patchwork.freedesktop.org/patch/msgid/20241211064343.550153-1-vivek.kasireddy@intel.com Tested-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko

drm: remove driver date from struct drm_driver and all drivers

2024-12-05T10:35:42+00:00

We stopped using the driver initialized date in commit 7fb8af6798e8 ("drm: deprecate driver date") and (eventually) started returning "0" for drm_version ioctl instead. Finish the job, and remove the unused date member from struct drm_driver, its initialization from drivers, along with the common DRIVER_DATE macros. v2: Also update drivers/accel (kernel test robot) Reviewed-by: Javier Martinez Canillas Acked-by: Alex Deucher Acked-by: Simon Ser Acked-by: Jeffrey Hugo Acked-by: Lucas De Marchi Acked-by: Dmitry Baryshkov # msm Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/virtio: Use generic dumb_map_offset implementation

2024-11-18T11:08:37+00:00

Currently, virtio uses its own dumb_map_offset implementation, virtio_gpu_mode_dumb_mmap. It works similarly to generic implementation, drm_gem_dumb_map_offset, and using the generic implementation is preferable (and making drivers to do so is a task stated on the DRM subsystem's TODO list). Thus, make driver use the generic implementation. This includes VIRTGPU_MAP ioctl so it cannot be used to circumvent rules imposed by drm_gem_dumb_map_offset (imported objects cannot be mapped). Signed-off-by: Peter Shkenev Signed-off-by: Dmitry Osipenko [dmitry.osipenko@collabora.com: cosmetic code improvements] Link: https://patchwork.freedesktop.org/patch/msgid/20241107141133.13624-1-mustela@erminea.space

drm/client: Move public client header to clients/ subdirectory

2024-11-15T08:42:13+00:00

Move the public header file drm_client_setup.h to the clients/ subdirectory and update all drivers. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Link: https://patchwork.freedesktop.org/patch/msgid/20241108154600.126162-3-tzimmermann@suse.de

drm/virtgpu: Use video aperture helpers

2024-10-14T13:28:48+00:00

DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by: Thomas Zimmermann Cc: David Airlie Cc: Gerd Hoffmann Cc: Gurchetan Singh Cc: Chia-I Wu Acked-by: Javier Martinez Canillas Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20240930130921.689876-26-tzimmermann@suse.de

drm/virtgpu: Run DRM default client setup

2024-09-26T07:31:28+00:00

Call drm_client_setup() to run the kernel's default client setup for DRM. Set fbdev_probe in struct drm_driver, so that the client setup can start the common fbdev client. The virtgpu driver specifies a preferred color mode of 32. As this is the default if no format has been given, leave it out entirely. v5: - select DRM_CLIENT_SELECTION Signed-off-by: Thomas Zimmermann Cc: David Airlie Cc: Gerd Hoffmann Cc: Gurchetan Singh Cc: Chia-I Wu Acked-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-62-tzimmermann@suse.de