drivers/gpu/drm/virtio/virtgpu_drv.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++ drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 13 ++++++++++--- include/uapi/drm/virtgpu_drm.h | 1 + include/uapi/linux/virtio_gpu.h | 5 +++++ 6 files changed, 24 insertions(+), 3 deletions(-)
There's an incresing number of machines supporting multiple page sizes and on these machines the host and a guest can be running, each one, with a different page size. For what pertains to virtio-gpu, this is not a problem if the page size of the guest happens to be bigger or equal than the host, but will potentially lead to failures in memory allocations and/or mappings otherwise. To improve this situation, we introduce here the HOST_PAGE_SIZE feature. This feature indicates that the host has an extended virtio_gpu_config structure that include it's own page size a new field. On the second commit, we also add a new param that can be read with VIRTGPU_GETPARAM by userspace applications running in the guest to obtain the host's page size and find out the right alignment to be used in shared memory allocations. Sergio Lopez (2): drm/virtio: introduce the HOST_PAGE_SIZE feature drm/virtio: add VIRTGPU_PARAM_HOST_PAGE_SIZE to params drivers/gpu/drm/virtio/virtgpu_drv.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++ drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 13 ++++++++++--- include/uapi/drm/virtgpu_drm.h | 1 + include/uapi/linux/virtio_gpu.h | 5 +++++ 6 files changed, 24 insertions(+), 3 deletions(-) -- 2.45.2
On 7/23/24 14:49, Sergio Lopez wrote: > There's an incresing number of machines supporting multiple page sizes > and on these machines the host and a guest can be running, each one, > with a different page size. > > For what pertains to virtio-gpu, this is not a problem if the page size > of the guest happens to be bigger or equal than the host, but will > potentially lead to failures in memory allocations and/or mappings > otherwise. Please describe concrete problem you're trying to solve. Guest memory allocation consists of guest pages, I don't see how knowledge of host page size helps anything in userspace. I suspect you want this for host blobs, but then it should be virtio_gpu_vram_create() that should use max(host_page_sz, guest_page_size), AFAICT. It's kernel who is responsible for memory management, userspace can't be trusted for doing that. -- Best regards, Dmitry
On Wed, Jul 24, 2024 at 12:00 PM Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote: > > On 7/23/24 14:49, Sergio Lopez wrote: > > There's an incresing number of machines supporting multiple page sizes > > and on these machines the host and a guest can be running, each one, > > with a different page size. > > > > For what pertains to virtio-gpu, this is not a problem if the page size > > of the guest happens to be bigger or equal than the host, but will > > potentially lead to failures in memory allocations and/or mappings > > otherwise. > > Please describe concrete problem you're trying to solve. Guest memory > allocation consists of guest pages, I don't see how knowledge of host > page size helps anything in userspace. > > I suspect you want this for host blobs, but then it should be > virtio_gpu_vram_create() that should use max(host_page_sz, > guest_page_size), AFAICT. It's kernel who is responsible for memory > management, userspace can't be trusted for doing that. fwiw virtgpu native context would require this as well, mesa would need to know the host page size to correctly align GPU VA allocations (which must be a multiple of the host page size). So a-b for adding this and exposing it to userspace. BR, -R > -- > Best regards, > Dmitry >
On 8/5/24 19:24, Rob Clark wrote: > On Wed, Jul 24, 2024 at 12:00 PM Dmitry Osipenko > <dmitry.osipenko@collabora.com> wrote: >> >> On 7/23/24 14:49, Sergio Lopez wrote: >>> There's an incresing number of machines supporting multiple page sizes >>> and on these machines the host and a guest can be running, each one, >>> with a different page size. >>> >>> For what pertains to virtio-gpu, this is not a problem if the page size >>> of the guest happens to be bigger or equal than the host, but will >>> potentially lead to failures in memory allocations and/or mappings >>> otherwise. >> >> Please describe concrete problem you're trying to solve. Guest memory >> allocation consists of guest pages, I don't see how knowledge of host >> page size helps anything in userspace. >> >> I suspect you want this for host blobs, but then it should be >> virtio_gpu_vram_create() that should use max(host_page_sz, >> guest_page_size), AFAICT. It's kernel who is responsible for memory >> management, userspace can't be trusted for doing that. > > fwiw virtgpu native context would require this as well, mesa would > need to know the host page size to correctly align GPU VA allocations > (which must be a multiple of the host page size). > > So a-b for adding this and exposing it to userspace. In general, GPU page size has no connection to the CPU page size. It happens that MSM driver uses same page size for both GPU and CPU. Likely you could configure a different GPU page size if you wanted. dGPUs would often use 64k pages. -- Best regards, Dmitry
On Thu, Aug 8, 2024 at 4:16 AM Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote: > > On 8/5/24 19:24, Rob Clark wrote: > > On Wed, Jul 24, 2024 at 12:00 PM Dmitry Osipenko > > <dmitry.osipenko@collabora.com> wrote: > >> > >> On 7/23/24 14:49, Sergio Lopez wrote: > >>> There's an incresing number of machines supporting multiple page sizes > >>> and on these machines the host and a guest can be running, each one, > >>> with a different page size. > >>> > >>> For what pertains to virtio-gpu, this is not a problem if the page size > >>> of the guest happens to be bigger or equal than the host, but will > >>> potentially lead to failures in memory allocations and/or mappings > >>> otherwise. > >> > >> Please describe concrete problem you're trying to solve. Guest memory > >> allocation consists of guest pages, I don't see how knowledge of host > >> page size helps anything in userspace. > >> > >> I suspect you want this for host blobs, but then it should be > >> virtio_gpu_vram_create() that should use max(host_page_sz, > >> guest_page_size), AFAICT. It's kernel who is responsible for memory > >> management, userspace can't be trusted for doing that. > > > > fwiw virtgpu native context would require this as well, mesa would > > need to know the host page size to correctly align GPU VA allocations > > (which must be a multiple of the host page size). > > > > So a-b for adding this and exposing it to userspace. > > In general, GPU page size has no connection to the CPU page size. It > happens that MSM driver uses same page size for both GPU and CPU. Likely > you could configure a different GPU page size if you wanted. dGPUs would > often use 64k pages. The smmu actually supports various different page sizes (4k, 64k, etc.. I think up to 2g), and will try to map larger contiguous sets of pages using larger page sizes to reduce TLB pressure. This restriction about aligning to host page size is because the kernel expects allocations and therefore (currently, pre-sparse) gpu mappings to be a multiple of the host page size. As far as whether this should be something outside of virtio-gpu, this does feel a bit specific to how GEM buffer allocations work and how host blob resources work. Maybe other subsystems like media end up with similar constraints for similar reasons, idk. But it at least feels like something applicable to all/most virtgpu context types. BR, -R
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > On 7/23/24 14:49, Sergio Lopez wrote: >> There's an incresing number of machines supporting multiple page sizes >> and on these machines the host and a guest can be running, each one, >> with a different page size. >> >> For what pertains to virtio-gpu, this is not a problem if the page size >> of the guest happens to be bigger or equal than the host, but will >> potentially lead to failures in memory allocations and/or mappings >> otherwise. > > Please describe concrete problem you're trying to solve. Guest memory > allocation consists of guest pages, I don't see how knowledge of host > page size helps anything in userspace. > > I suspect you want this for host blobs, but then it should be > virtio_gpu_vram_create() that should use max(host_page_sz, > guest_page_size), AFAICT. It's kernel who is responsible for memory > management, userspace can't be trusted for doing that. Mesa's Vulkan/Venus uses CREATE_BLOB to request the host the creation and mapping into the guest of device-backed memory and shmem regions. The CREATE_BLOB ioctl doesn't update drm_virtgpu_resource_create->size, so the guest kernel (and, as a consequence, the host kernel) can't override the user's request. I'd like Mesa's Vulkan/Venus in the guest to be able to obtain the host page size to align the size of the CREATE_BLOB requests as required. Thanks, Sergio.
© 2016 - 2024 Red Hat, Inc.