Re: [PATCH RESEND] drm/virtio: expose GEM memory statistics through fdinfo

[Dmitry Osipenko]

On 10/8/26 19:41, shechenglong wrote:
> On Thu, 8 Oct 2026 00:44:34 +0300, Dmitry Osipenko wrote:
>> Usefulness of this change is dubious. VirtIO-GPU has different types of
>> RAM, I'd expect them all represented properly instead of only shmem.
> 
> Hi Dmitry,
> 
> Thanks for the review.
> 
> Agreed that a generic memory collector does not map well onto
> virtio-gpu, given its different memory types. For v2, I plan to
> replace it with virtio-gpu-specific accounting and to document the
> semantics of each reported value explicitly:
> 
> - Guest shmem objects: reported under the "memory" region as
>   drm-total/drm-shared, based on the guest GEM object size. These
>   reflect the requested buffer size; drm-resident, if reported, would
>   be derived from the actual state of the guest backing pages.
> 
> - Host-only blobs (VIRTGPU_BLOB_MEM_HOST3D): reported under a separate
>   region, tentatively "host3d", using the requested blob size. These
>   values would be documented as logical sizes and not as actual host
>   RAM or VRAM consumption.
> 
> - Mixed blobs (VIRTGPU_BLOB_MEM_HOST3D_GUEST): the guest shadow
>   backing is accounted under "memory", while the logical blob size is
>   exposed through a separate, documented supplementary key. This
>   distinguishes mixed resources from guest-only ones without
>   presenting the supplementary value as additional measured host
>   memory.
> 
> - Imported dma-bufs: handled explicitly, without assuming that they
>   are backed by local shmem.
> 
> Usage of the host-visible memory region would be reported separately
> from the backing statistics and would not be used to infer host
> residency.
> 
> The actual host allocation size and residency, including legacy virgl
> resources and the host part of mixed blobs, are not available through
> the existing guest/host interface. Reporting them would require
> additional host/renderer support, so I propose leaving that out of
> this series unless you consider it a prerequisite.
> 
> Does this scope match your expectations for v2? Are there other
> memory types or accounting semantics you would like covered?
Sounds okay

-- 
Best regards,
Dmitry