is
>>> freed as we took a reference on it in virtgpu_gem_prime_import().
>>>
>>> Fixes: 415cb45895f4 ("drm/virtio: Use dma_buf from GEM object
>>> instance")
>>> Cc: Dmitry Osipenko
>>> Cc: Thomas Zimmermann
>>> Signed-off
On 5/5/25 22:38, Kim, Dongwon wrote:
>> I tried to apply your kernel patches and then suspend/resume guest kernel, it
>> doesn't work:
>>
>> virtio_gpu_transfer_to_host_2d: no backing storage 2
>> [ 22.909454] [drm:virtio_gpu_dequeue_ctrl_func] ERROR response
>> 0x1200 (command 0x105)
>> virtio_g
On 4/19/25 02:29, dongwon@intel.com wrote:
> From: Dongwon Kim
>
> This patch series introduces a freeze and restore mechanism for
> the virtio-gpu driver:
>
> First patch adds `virtgpu_freeze` and `virtgpu_restore` functions.
> These functions handle the deletion of virtio queues before sus
On 5/5/25 18:58, Dmitry Osipenko wrote:
> On 5/5/25 11:59, Manos Pitsidianakis wrote:
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
>> b/drivers/gpu/drm/virtio/virtgpu_kms.c
>> index
>> 7b3c4d314f8eee692e2842a7056d6dc64936fc2f..a8b751179332b9ec2fbba1392a6ee0e63
be valid until the object is
> freed as we took a reference on it in virtgpu_gem_prime_import().
>
> Fixes: 415cb45895f4 ("drm/virtio: Use dma_buf from GEM object instance")
> Cc: Dmitry Osipenko
> Cc: Thomas Zimmermann
> Signed-off-by: Vivek Kasireddy
> ---
>
On 4/19/25 02:29, dongwon@intel.com wrote:
> From: Dongwon Kim
>
> This patch series introduces a freeze and restore mechanism for
> the virtio-gpu driver:
>
> First patch adds `virtgpu_freeze` and `virtgpu_restore` functions.
> These functions handle the deletion of virtio queues before sus
On 5/5/25 11:59, Manos Pitsidianakis wrote:
> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
> b/drivers/gpu/drm/virtio/virtgpu_kms.c
> index
> 7b3c4d314f8eee692e2842a7056d6dc64936fc2f..a8b751179332b9ec2fbba1392a6ee0e638a5192e
> 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> +++ b/driv
On 4/12/25 16:20, Ryosuke Yasuoka wrote:
> Pass array of pages of the scanout buffer [1] to shmem BO, allowing
> drm_panic to work even if the BO is not vmapped.
>
> [1] https://lore.kernel.org/all/20250407140138.162383-3-jfale...@redhat.com/
>
> Signed-off-by: Jocelyn Falempe
> Signed-off-by: R
On 4/14/25 16:11, Thomas Zimmermann wrote:
> Avoid the use of struct drm_gem_object.import_attach to get the
> object's dma-buf or test for an imported buffer. The import_attach
> field in struct drm_gem_object is an artifact of the import process,
> but should not be used otherwise.
>
> The helpe
On 4/16/25 10:05, Thomas Zimmermann wrote:
> Hi
>
> Am 12.04.25 um 15:20 schrieb Ryosuke Yasuoka:
>> Pass array of pages of the scanout buffer [1] to shmem BO, allowing
>> drm_panic to work even if the BO is not vmapped.
>>
>> [1] https://lore.kernel.org/all/20250407140138.162383-3-
>> jfale...@re
> + return -ENODEV;
> + /* map scanout buffer later */
> + sb->pages = shmem->pages;
> + }
>
> sb->format = plane->state->fb->format;
> sb->height = plane->state->fb->height;
>
> base-commit: e7bb7d44c3b97aea1f0e354c6499900154ac67f2
Works well!
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 4/10/25 19:32, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Plumb the format info from .fb_create() all the way to
> drm_helper_mode_fill_fb_struct() to avoid the redundant
> lookup.
>
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: Dmitry Osipenko
> Cc: Gu
gt; dma_resv_lock(dmabuf->resv, NULL);
> virtgpu_dma_buf_unmap(bo);
> dma_resv_unlock(dmabuf->resv);
>
> - dma_buf_detach(dmabuf, attach);
> + dma_buf_detach(dmabuf, obj->import_attach);
> dma_buf_put(dmabuf);
> }
>
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 8
> drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
therwise looks good.
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 4/4/25 16:23, Thomas Zimmermann wrote:
> Gem-vram helpers do not support PRIME dma-buf sharing. No nothing
> will ever call pin/unpin on its buffer objects. Do not set these
> callbacks in struct drm_gem_object_funcs.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
On 4/4/25 16:23, Thomas Zimmermann wrote:
> There are no external callers of the gem-vram pin helpers. Hence
> unexport them.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 4/4/25 16:23, Thomas Zimmermann wrote:
> +int drm_client_buffer_vmap(struct drm_client_buffer *buffer,
> +struct iosys_map *map_copy)
> {
> struct drm_gem_object *gem = buffer->gem;
> struct iosys_map *map = &buffer->map;
> int ret;
>
> drm_gem_
On 3/24/25 16:05, Christian König wrote:
> Am 22.03.25 um 22:25 schrieb Dmitry Osipenko:
>> Make drm/gem API function names consistent by having locked function
>> use the _locked postfix in the name, while the unlocked variants don't
>> use the _unlocked postfix. Rename
/dri-devel/20240105184624.508603-1-dmitry.osipe...@collabora.com/
Changelog:
v20:- Rebased on recent drm-misc. Added r-bs that were given to v19.
Dmitry Osipenko (10):
drm/gem: Change locked/unlocked postfix of drm_gem_v/unmap() function
names
drm/gem: Add _locked postfix to functions that
On 3/30/25 14:57, Dmitry Osipenko wrote:
>> +userptr = virtio_gpu_userptr_from_addr_range(
>> +vfpriv, params->userptr, params->userptr + params->size - 1UL);
> Is it possible that userptr address will be same for two different
> processes?
See now the
On 4/3/25 10:03, Thomas Zimmermann wrote:
> Hi
>
> Am 03.04.25 um 02:37 schrieb Lucas De Marchi:
>> On Sun, Mar 23, 2025 at 12:25:58AM +0300, Dmitry Osipenko wrote:
>>> Hi,
>>>
>>> This a continuation of a year-old series that adds generic DRM-shmem
>&
Add locked and remove unlocked postfixes from drm-shmem function names,
making names consistent with the drm/gem core code.
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 60
On 4/2/25 15:47, Thomas Zimmermann wrote:
> Hi
>
> Am 22.03.25 um 22:26 schrieb Dmitry Osipenko:
>> The vmapped pages shall be pinned in memory and previously get/
>> put_pages()
>> were implicitly hard-pinning/unpinning the pages. This will no longer be
>>
On 4/3/25 17:26, Dmitry Osipenko wrote:
> We switched to use refcount_t for vmaps and missed to change the vunmap
> code to properly unset the vmap pointer, which is now cleared while vmap's
> refcount > 0. Clear the cached vmap pointer only when refcounting drops to
>
On 4/2/25 20:55, Dmitry Osipenko wrote:
> On 4/2/25 20:46, Sergio Lopez wrote:
>> diff --git a/include/uapi/linux/virtio_gpu.h
>> b/include/uapi/linux/virtio_gpu.h
>> index
>> bf2c9cabd20793e3851e749baadf210341445501..adc264df4e458e9c754936c3015c069e5ee6b899
>&
On 4/3/25 06:28, Huang, Honglei1 wrote:
>
> Hi Dmitry:
>
> Really sorry for missed this comment. Yes it can be done in UMD,
> actually the interval tree is used with the MMU notifier normally,
> it is for preventing create same MMU notifier for overlapped areas.
> Cause this version patch set doe
se refcount_t for vmap_use_count")
Reported-by: Lucas De Marchi
Closes:
https://lore.kernel.org/dri-devel/20250403105053.788b0...@collabora.com/T/#m3dca6d81bedc8d6146a56b82694624fbc6fa4c96
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed,
On 4/2/25 20:46, Sergio Lopez wrote:
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index
> c33c057365f85a2ace536f91655c903036827312..405203b3c3847a8b318a7118aa34356c839d249e
> 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drive
On 4/2/25 20:46, Sergio Lopez wrote:
> diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
> index
> bf2c9cabd20793e3851e749baadf210341445501..adc264df4e458e9c754936c3015c069e5ee6b899
> 100644
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu
On 4/2/25 04:53, Huang, Honglei1 wrote:
>
> On 2025/3/30 19:57, Dmitry Osipenko wrote:
>> If the purpose of this feature is to dedup usrptr BOs of a the single
>> process/application, can this can be done in userspace?
I assume it can be done in userspace, don't see why i
reedesktop.org/virgl/virglrenderer/-/merge_requests/805
>>
>> v2: Add DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_TIMELINE
>> v3: Add unstaged uabi header hunk
>> v4: Also handle IMPORT_SYNC_FILE case
>> v5: Address comments from Dmitry
>> v6: checkpatch.pl nits
>>
>> Signed-off-by:
On 4/1/25 22:53, Rob Clark wrote:
> On Tue, Apr 1, 2025 at 5:39 AM Dmitry Osipenko
> wrote:
>>
>> The vfpriv->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
On 4/1/25 17:34, Gurchetan Singh wrote:
> On Tue, Apr 1, 2025 at 7:25 AM Gerd Hoffmann wrote:
>
>> On Tue, Apr 01, 2025 at 04:01:51PM +0300, Dmitry Osipenko wrote:
>>> I was helping to co-maintain VirtIO-GPU driver in drm-misc with
>>> permission from Gerd Hoffm
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: # v6.14+
Acked-by: Vivek Kasireddy
Signed-off-by: Dmitry Osipenko
---
v2: Change order of prep_obj/f
086b9f27f0ab ("drm/virtio: Don't create a context with default param if
context_init is supported")
Cc: # v6.14+
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu
v3: Add unstaged uabi header hunk
> v4: Also handle IMPORT_SYNC_FILE case
> v5: Address comments from Dmitry
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_syncobj.c | 45 +++
> include/uapi/drm/drm.h| 4
> 2 files
I was helping to co-maintain VirtIO-GPU driver in drm-misc with
permission from Gerd Hoffmann for past 2 years and would like to
receive new patches directly into my inbox. Add myself as co-maintainer.
Signed-off-by: Dmitry Osipenko
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff
If the purpose of this feature is to dedup usrptr BOs of a the single
process/application, can this can be done in userspace?
On 3/21/25 11:00, Honglei Huang wrote:
> int virtio_gpu_userptr_create(struct virtio_gpu_device *vgdev,
> struct drm_file *file,
>
On 3/29/25 22:50, Demi Marie Obenour wrote:
> On 3/26/25 10:46 AM, Dmitry Osipenko wrote:
>> On 3/6/25 13:51, Huang, Honglei1 wrote:
>>>
>>> On 2025/3/1 5:21, Demi Marie Obenour wrote:
>>>> On 2/28/25 12:36 AM, Honglei Huang wrote:
>>>>> From:
On 3/27/25 18:25, Aaron Ruby wrote:
>
> Since the context-type additions to the virtio-gpu spec, these have been
> defined locally in guest user-space, and virtio-gpu backend library code.
>
> Now, these capsets have been stabilized, and should be defined in
> a common space, in both the virtio_g
On 3/27/25 06:00, Huang, Honglei1 wrote:
>
>
> On 2025/3/26 22:46, Dmitry Osipenko wrote:
>> On 3/6/25 13:51, Huang, Honglei1 wrote:
>>>
>>> On 2025/3/1 5:21, Demi Marie Obenour wrote:
>>>> On 2/28/25 12:36 AM, Honglei Huang wrote:
>>>>
On 3/27/25 10:14, Kasireddy, Vivek wrote:
>> Another question, why do we need this fencing for imported dmabuf?
>> Fencing isn't done host/guest blobs in this code, while dmabuf is
>> essentially a guest blob. Could you please clarify why this fence is
>> needed? Maybe we shouldn't allocate fence i
illon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 28 ++
drivers/gpu/drm/tests/drm_gem_shmem_test.c | 6 ++---
include/drm/drm_gem_shmem_helper.h | 2 +-
3 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/gp
On 3/28/25 00:36, Rob Clark wrote:
...
> static int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
> - int fd, int handle)
> + int fd, int handle, u64 point)
> {
> struct dma_fence *fence
On 3/27/25 15:19, Jacek Lawrynowicz wrote:
> Hi,
>
> On 3/27/2025 12:37 PM, Dmitry Osipenko wrote:
>> On 3/27/25 14:30, Jani Nikula wrote:
>>> On Thu, 27 Mar 2025, Boris Brezillon wrote:
>>>> Commit 051b6646d36d ("drm/shmem-helper: Use refcount_t for
&
hind.
>>
>> Fixes: 051b6646d36d ("drm/shmem-helper: Use refcount_t for pages_use_count")
>> Signed-off-by: Boris Brezillon
>> Cc: Dmitry Osipenko
>> Cc: Jacek Lawrynowicz
>> Cc: Maciej Falkowski
>> Cc: Oded Gabbay
>> Cc: dri-devel@lis
On 3/27/25 13:45, Boris Brezillon wrote:
> On Wed, 26 Mar 2025 23:08:55 +0300
> Dmitry Osipenko wrote:
>
>> On 3/25/25 17:17, Thomas Zimmermann wrote:
>>> I've looked through this before, so
>>>
>>> Acked-by: Thomas Zimmermann
>>>
eft behind.
>
> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions")
> Signed-off-by: Boris Brezillon
> Cc: Dmitry Osipenko
> Cc: Jacek Lawrynowicz
> Cc: Maciej Falkowski
> Cc: Oded Gabbay
> Cc: dri-devel@lists.freedesktop.org
> ---
locked postfix of
> drm_gem_v/unmap() function names")
> Signed-off-by: Boris Brezillon
> Cc: Dmitry Osipenko
> Cc: Min Ma
> Cc: Lizhi Hou
> Cc: Oded Gabbay
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/accel/amdxdna/amdxdna_gem.c | 4 ++--
> 1 file c
/shmem-helper: Use refcount_t for pages_use_count")
> Signed-off-by: Boris Brezillon
> Cc: Dmitry Osipenko
> Cc: Jacek Lawrynowicz
> Cc: Maciej Falkowski
> Cc: Oded Gabbay
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/accel/ivpu/ivpu_gem.c | 2 +-
> 1 file changed, 1
On 3/25/25 18:42, Aaron Ruby wrote:
> From 73e0b6fb04d90b70de1f40e8e2ffc8fe497fa204 Mon Sep 17 00:00:00 2001
> From: Aaron Ruby
> Date: Mon, 24 Mar 2025 16:18:43 -0400
> Subject: [PATCH] drm/virtio: Add capset definitions
>
> Since the context-type additions to the virtio-gpu spec, these have bee
(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 f
On 3/25/25 17:17, Thomas Zimmermann wrote:
> I've looked through this before, so
>
> Acked-by: Thomas Zimmermann
>
> for the series.
Applied to misc-next, thanks!
--
Best regards,
Dmitry
On 3/26/25 05:14, Adrián Larumbe wrote:
> +static struct sg_table *
> +drm_gem_shmem_sparse_get_sgt_range(struct drm_gem_shmem_object *shmem,
> +unsigned int n_pages, pgoff_t page_offset,
> +gfp_t gfp)
> +{
> + struct drm_gem_objec
On 3/6/25 13:51, Huang, Honglei1 wrote:
>
> On 2025/3/1 5:21, Demi Marie Obenour wrote:
>> On 2/28/25 12:36 AM, Honglei Huang wrote:
>>> From: Honglei Huang
>>>
>>> Add a new resource for blob resource, called userptr, used for let
>>> host access guest user space memory, to acquire buffer based
On 3/26/25 08:14, Kasireddy, Vivek wrote:
...
>> static int virtio_gpu_plane_prepare_fb(struct drm_plane *plane,
>> struct drm_plane_state *new_state)
>> {
>> @@ -376,23 +386,16 @@ static int virtio_gpu_plane_prepare_fb(struct
>> drm_plane *plane,
>>
ipard
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_client.c | 10 +-
drivers/gpu/drm/drm_gem.c| 20 ++--
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +++---
drivers/gp
Unpin imported dmabuf on fence allocation failure in prepare_fb().
Fixes: 4a696a2ee646 ("drm/virtio: Add prepare and cleanup routines for imported
dmabuf obj")
Cc: # v6.14+
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 25 ++---
1 fi
086b9f27f0ab ("drm/virtio: Don't create a context with default param if
context_init is supported")
Cc: # v6.14+
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu
mport prime buffers from other devices as
> guest blobs")
> Cc: Gerd Hoffmann
> Cc: Dmitry Osipenko
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/gpu/drm/virtio/virtgpu_prime.c | 1 +
> 1 file changed, 1 insertion(+)
&g
Use atomic refcount_t helper for pages_use_count to optimize pin/unpin
functions by skipping reservation locking while GEM's pin refcount > 1.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers
swapped
out). The pages_pin_count > 1 will hard-pin pages in memory.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 16 +++-
include/drm/drm_gem_shmem_helper.h |
Maxime Ripard
Suggested-by: Thomas Zimmermann
Reviewed-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
inde
t-pinned),
while the new pages_pin_count will do the hard-pinning. Switch the
vmap/vunmap() to use pin/unpin() functions in a preparation of addition
of the memory shrinker support to drm-shmem.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers
Make all drm-shmem exported symbols GPL to make them consistent with
the rest of drm-shmem symbols.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 16
1 file changed, 8 insertions(+), 8
The vmap/vunmap/evict GEM callbacks are always invoked with a held GEM's
reservation lock. Document this locking rule for clarity.
Reviewed-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
include/drm/drm_gem.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --
Add _locked postfix to drm_gem functions that have unlocked counterpart
functions to make GEM functions naming more consistent and intuitive in
regards to the locking requirements.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
On 3/4/25 14:43, Thomas Zimmermann wrote:
> Hi
>
> Am 04.03.25 um 11:59 schrieb Dmitry Osipenko:
>> On 3/4/25 13:29, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 05.01.24 um 19:46 schrieb Dmitry Osipenko:
>>>> Introduce common drm-shmem shrinke
On 3/4/25 13:29, Thomas Zimmermann wrote:
> Hi
>
> Am 05.01.24 um 19:46 schrieb Dmitry Osipenko:
>> Introduce common drm-shmem shrinker for DRM drivers.
>
> What's the status of this patch?
It was de-prioritized on my list a year ago as I had to move to a higher
prior
args->height;
> - args->size = ALIGN(args->size, PAGE_SIZE);
> -
> params.format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB);
> params.width = args->width;
> params.height = args->height;
> @@ -92,7 +92,6 @@ int virtio_gpu_mode_dumb_create(struct d
e VIRTGPU_PARAM_SUPPORTED_CAPSET_IDs 7 /* Bitmask of supported
> capability set ids */
> #define VIRTGPU_PARAM_EXPLICIT_DEBUG_NAME 8 /* Ability to set debug name
> from userspace */
> +#define VIRTGPU_PARAM_HOST_SHM_PAGE_SIZE 9 /* Host SHM page size, with
> format PAGE_SIZE >> 12 */
>
> struct drm_virtgpu_getparam {
> __u64 param;
>
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 2/20/25 13:24, Sergio Lopez Pascual wrote:
> Dmitry Osipenko writes:
>
>> On 2/14/25 18:16, Sergio Lopez wrote:
>>> Use the newly introduced SHM_PAGE_SHIFT register to read the page shift
>>> for the shared memory region, derive the page size from it and stor
On 2/14/25 18:16, Sergio Lopez wrote:
> Use the newly introduced SHM_PAGE_SHIFT register to read the page shift
> for the shared memory region, derive the page size from it and store the
> resulting value into virtio_shm_region.
>
> Signed-off-by: Sergio Lopez
> ---
> drivers/virtio/virtio_mmio.
io_pci_cap {
> __u8 cfg_type; /* Identifies the structure. */
> __u8 bar; /* Where to find it. */
> __u8 id;/* Multiple capabilities of the same type */
> - __u8 padding[2];/* Pad to full dword. */
> + __u8 page_shift;/* Page shift for
> VIRTIO_PCI_CAP_SHARED_MEMORY_CFG. */
> + __u8 padding[1];/* Pad to full dword. */
> __le32 offset; /* Offset within bar. */
> __le32 length; /* Length of the structure, in bytes. */
> };
>
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
42
> +#define VIRTIO_TRANSPORT_F_END 43
>
> #ifndef VIRTIO_CONFIG_NO_LEGACY
> /* Do we get callbacks when the ring is completely used, even if we've
> @@ -120,4 +120,9 @@
> */
> #define VIRTIO_F_ADMIN_VQ41
>
> +/*
> + *
On 2/14/25 18:16, Sergio Lopez wrote:
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index
> 5d78c2d572abfcfe2b84cdd82df622320fe97d5d..1f594b626d7a7734e8ec58766737a118c26bad94
> 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -56
pping.
> - * @dir: direction of cached mapping.
> * @peer2peer: true if the importer can handle peer resources without pages.
> * @priv: exporter specific attachment data.
> * @importer_ops: importer operations for this attachment, if provided
> @@ -514,8 +503,6 @@ struct dma_buf_attachment {
> struct dma_buf *dmabuf;
> struct device *dev;
> struct list_head node;
> - struct sg_table *sgt;
> - enum dma_data_direction dir;
> bool peer2peer;
> const struct dma_buf_attach_ops *importer_ops;
> void *importer_priv;
Recalling being very confused by this cached sgt many years ago when
faced it for the first time :)
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 2/11/25 19:31, Christian König wrote:
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index e7ad819962e3..e230af0d123f 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -169,8 +169,8 @@ struct dma_fence_ops {
>* implementation know tha
ack to fill in free-form debug info specific to this fence, like
> - * the sequence number.
> - *
> - * This callback is optional.
> - */
> - void (*fence_value_str)(struct dma_fence *fence, char *str, int size);
> -
> - /**
> - * @timeline_value_str:
> -
as long as IGT passes.
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 2/17/25 20:11, Dmitry Osipenko wrote:
> On 2/11/25 19:31, Christian König wrote:
>> The fence_value_str and timeline_value_str callbacks were just an
>> unnecessary abstraction in the SW sync implementation.
>>
>> The only caller of those callbacks already knew that t
On 2/14/25 20:45, Rob Clark wrote:
> On Sun, Jan 26, 2025 at 12:43 PM Dmitry Osipenko
> wrote:
>>
>> If userspace never maps GEM object, then BO wastes hostmem space
>> because VirtIO-GPU driver maps VRAM BO at the BO's creating time.
>>
>&
On 2/14/25 18:16, Sergio Lopez wrote:
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index
> c33c057365f85a2ace536f91655c903036827312..4b49635b4fe1d4256f219823341cef8e5fa8f029
> 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/driv
On 2/6/25 13:42, Ryosuke Yasuoka wrote:
> 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
> Signed-off-by: Ryosuke Yasuoka
> ---
Applied to misc-nex
On 2/6/25 18:17, Sasha Finkelstein wrote:
> On Wed, 29 Jan 2025 at 15:40, Dmitry Osipenko
> wrote:
>> Otherwise, the proper solution would be to pass info about host's page
>> size to guest using extended virtio protocol.
>
> It is not fully clear to me, as to
On 12/2/24 20:19, Jocelyn Falempe wrote:
>>>
>>> I've now noticed that drm_gem_shmem_vmap() expects BO reservation lock
>>> to be held and we can't take lock it at a panic time.
>>>
>>> https://elixir.bootlin.com/linux/v6.12.1/source/drivers/gpu/drm/
>>> drm_gem_shmem_helper.c#L330
>>>
>>> This res
On 1/30/25 12:05, Ryosuke Yasuoka wrote:
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index f42ca9d8ed10..44511f316851 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -126,6 +126,12 @@ struct vi
Hi,
On 1/30/25 12:05, Ryosuke Yasuoka wrote:
...
> +static int virtio_drm_get_scanout_buffer(struct drm_plane *plane,
> + struct drm_scanout_buffer *sb)
> +{
> + struct virtio_gpu_object *bo;
> +
> + if (!plane->state || !plane->state->fb || !plane->sta
On 1/26/25 00:08, Sasha Finkelstein via B4 Relay wrote:
> --- a/drivers/gpu/drm/virtio/virtgpu_vram.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vram.c
> @@ -150,8 +150,8 @@ static int virtio_gpu_vram_map(struct virtio_gpu_object
> *bo)
> return -EINVAL;
>
> spin_lock(&vgdev->hos
n the flag is set by userspace.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_gem.c | 9
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 +
drivers/gpu/drm/virtio/virtgpu_vram.c | 30 +-
include/uap
On 1/25/25 01:58, Sasha Finkelstein wrote:
> On Fri, 24 Jan 2025 at 23:52, Dmitry Osipenko
> wrote:
>>> - ret = drm_mm_insert_node(&vgdev->host_visible_mm, &vram->vram_node,
>>> - bo->base.base.size);
>>
On 1/25/25 01:01, Sasha Finkelstein via B4 Relay wrote:
> From: Sasha Finkelstein
>
> This allows running different page sizes between host and guest on
> platforms that support mixed page sizes.
>
> Signed-off-by: Sasha Finkelstein
> ---
> drivers/gpu/drm/virtio/virtgpu_vram.c | 10 --
On 1/19/25 23:23, Dmitry Osipenko wrote:
> On 1/19/25 23:02, Dmitry Osipenko wrote:
>> On 1/19/25 19:18, Sasha Finkelstein wrote:
>>> On Sun, 19 Jan 2025 at 12:50, Dmitry Osipenko
>>> wrote:
>>>>> ret = io_remap_pfn_range(vma, vma->vm_sta
On 1/19/25 23:02, Dmitry Osipenko wrote:
> On 1/19/25 19:18, Sasha Finkelstein wrote:
>> On Sun, 19 Jan 2025 at 12:50, Dmitry Osipenko
>> wrote:
>>>> ret = io_remap_pfn_range(vma, vma->vm_start,
>>>> -
On 1/19/25 19:18, Sasha Finkelstein wrote:
> On Sun, 19 Jan 2025 at 12:50, Dmitry Osipenko
> wrote:
>>> ret = io_remap_pfn_range(vma, vma->vm_start,
>>> - vram->vram_node.start >> PAGE_SHIFT,
>>> +
nitialization.
>
> Fixes: 5dd8b536bb ("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
> ---
> drivers/gpu/drm/virtio/virtgp
Hi,
On 1/10/25 00:45, Sasha Finkelstein via B4 Relay wrote:
> From: Sasha Finkelstein
>
> Those are useful to implement coherent cross-vm mmap.
>
> Signed-off-by: Sasha Finkelstein
> ---
> drivers/gpu/drm/virtio/virtgpu_vram.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
>
On 12/11/24 09:43, Vivek Kasireddy wrote:
> +static int __init virtio_gpu_driver_init(void)
> +{
> + struct pci_dev *pdev;
> + int ret;
> +
> + pdev = pci_get_device(PCI_VENDOR_ID_REDHAT_QUMRANET,
> + PCI_DEVICE_ID_VIRTIO_GPU,
> + NULL
On 12/2/24 08:39, Dmitry Osipenko wrote:
> 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->attached and bo->sgt are unset under held reservation lock.
>
1 - 100 of 1973 matches
Mail list logo
