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? Best regards, Chenglong She
