Virtio-gpu resources have independent guest backing and host
representations. Blob resources may be created without guest backing or
with zero size, but the current udmabuf path still attempts an empty
ioctl or mmap operation. Mapping failures can also leave an incompletely
initialized resource.
The generic resource lookup further conflates these states. Commands
using it have different requirements: a transfer needs a backed 2D
resource, SET_SCANOUT needs a 2D image, SET_SCANOUT_BLOB needs a backed
blob, and DETACH_BACKING only needs the resource to exist. UPDATE_CURSOR
can likewise attempt to copy pixels from an unbacked blob.
Skip empty udmabuf and mmap operations, propagate mapping failures, and
validate cursor and command resources against the state each command
requires. Creation, attachment, and migration now reject incomplete
mappings instead of publishing unusable resources.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
---
Changes in v2:
- Added patches to validate cursor and per-command resource state.
- Added Reviewed-by tags from Marc-André Lureau.
- Fixed continuation indentation in patch 1.
- Added Fixes tags to all patches.
- Reworded the commit message in patch 2.
- Link to v1: https://lore.kernel.org/qemu-devel/20260807-dmabuf-v1-0-d24b1331dc8a@rsg.ci.i.u-tokyo.ac.jp
---
Akihiko Odaki (5):
hw/display/virtio-gpu: Avoid creating empty udmabuf
hw/display/virtio-gpu: Avoid mmap() for empty blob
hw/display/virtio-gpu: Propagate udmabuf errors
hw/display/virtio-gpu: Check cursor data presence
hw/display/virtio-gpu: Validate resource per command
include/hw/virtio/virtio-gpu.h | 2 +-
hw/display/virtio-gpu-udmabuf-stubs.c | 3 +-
hw/display/virtio-gpu-udmabuf.c | 10 +-
hw/display/virtio-gpu.c | 178 +++++++++++++++++++++-------------
4 files changed, 117 insertions(+), 76 deletions(-)
---
base-commit: 3e3ccab106f879b1512f8e0d51a827dd4de30e22
change-id: 20260806-dmabuf-8945c9b42004
Best regards,
--
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>