On Mon, Aug 5, 2024 at 2:14 AM Sergio Lopez Pascual <slp@xxxxxxxxxx> wrote:
Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> 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.
gfxstream solves this problem by putting the relevant information in the capabilities obtained from the host:
If you want to be paranoid, you can also validate the ResourceCreateBlob::size is properly host-page aligned when that request reaches the host.
So you can probably solve this problem using current interfaces. Whether it's cleaner for all context types to use the capabilities, or have all VMMs to expose VIRTIO_GPU_F_HOST_PAGE_SIZE, would be the cost/benefit tradeoff.
Thanks,
Sergio.
