qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Honglei Huang <honghuan@amd.com>
To: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: mst@redhat.com, cohuck@redhat.com, pbonzini@redhat.com,
	qemu-devel@nongnu.org, Ray.Huang@amd.com,
	dmitry.osipenko@collabora.com, alex.bennee@linaro.org
Subject: Re: [v2 1/3] virtio-gpu: Add support for VIRTIO_GPU_BLOB_FLAG_USE_USERPTR flag
Date: Fri, 21 Nov 2025 14:50:37 +0800	[thread overview]
Message-ID: <f95196fe-27c8-4eef-8b64-b1ede138425d@amd.com> (raw)
In-Reply-To: <9b48903e-09eb-453a-aa8f-903fca99cb7d@rsg.ci.i.u-tokyo.ac.jp>



On 2025/11/21 14:12, Akihiko Odaki wrote:
> 
> 
> On 2025/11/21 14:43, Honglei Huang wrote:
>>
>>
>> On 2025/11/21 13:28, Akihiko Odaki wrote:
>>> On 2025/11/21 14:21, Honglei Huang wrote:
>>>>
>>>>
>>>> On 2025/11/21 11:39, Akihiko Odaki wrote:
>>>>> On 2025/11/21 12:14, Honglei Huang wrote:
>>>>>>
>>>>>>
>>>>>> On 2025/11/21 10:56, Akihiko Odaki wrote:
>>>>>>> On 2025/11/21 11:47, Honglei Huang wrote:
>>>>>>>> Add support for the USE_USERPTR blob flag in virtio-gpu to enable
>>>>>>>> user pointer mapping for blob resources. This allows guest 
>>>>>>>> applications
>>>>>>>> to use user-allocated memory for GPU resources more efficiently.
>>>>>>>>
>>>>>>>> Changes include:
>>>>>>>> - Add VIRTIO_GPU_BLOB_FLAG_USE_USERPTR flag definition
>>>>>>>> - Enhance blob resource creation to handle userptr flag properly
>>>>>>>> - Remove arbitrary nr_entries limit (16384) in mapping creation
>>>>>>>> - Add conditional handling for userptr vs regular blob mapping
>>>>>>>
>>>>>>> I don't see the added conditional handling.
>>>>>>
>>>>>> Sorry, the additional handing is replaced by the fixing of value 
>>>>>> check.
>>>>>> I will correct this commit message in the next version.
>>>>>
>>>>> Not just the commit message, but it also questions the utility of 
>>>>> VIRTIO_GPU_BLOB_FLAG_USE_USERPTR and VIRTIO_GPU_F_RESOURCE_USERPTR. 
>>>>> Neither of them adds a new functionality. They should be dropped if 
>>>>> they are also replaced with the fix.
>>>>>
>>>>
>>>> Yes totally agreed, it is my mistaken, I shouldn't mix the code for 
>>>> fixing and the code for adding new features in one submission.
>>>>
>>>> Actually this patch set are for another components upstream test, 
>>>> for the sake of convenience, I have added both the fix and feature 
>>>> here,
>>>> that is a bad idea.
>>>>
>>>> Will split the fix part into previous thread.
>>>>
>>>> And for the check value fix thread, will send v4 as the final version.
>>>
>>> Splitting fixes and features is a good idea, but that's not what I 
>>> meant.
>>>
>>> What I pointed out is that, it seems that one of the "features" you 
>>> are adding, namely VIRTIO_GPU_F_RESOURCE_USERPTR does nothing at at 
>>> all. So I'm wondering if you forgot to add a real implementation or 
>>> the feature is just no longer necessary.
>>
>> Understood, actually the resource of flag 
>> VIRTIO_GPU_F_RESOURCE_USERPTR just reuses the feature of 
>> VIRTIO_GPU_BLOB_MEM_GUEST: using the virtio_gpu_create_mapping_iov 
>> function to map the iov from guest.
>>
>> In qemu, the handing of VIRTIO_GPU_F_RESOURCE_USERPTR and 
>> VIRTIO_GPU_BLOB_MEM_GUEST basically same.
>>
>> The VIRTIO_GPU_F_RESOURCE_USERPTR is from guest userspace, but the
>> VIRTIO_GPU_BLOB_MEM_GUEST comes from guest kernel.
>> So in VIRTIO kernel and virglrenderer they are different, see VIRTIO 
>> kerenl: [1], and virglrenderer: [2].
>>
>> May I need to change the organizational form of this patch set?
>>
>> [1]: https://lore.kernel.org/lkml/20251112074548.3718563-1- 
>> honglei1.huang@amd.com/
>> [2]: https://gitlab.freedesktop.org/virgl/virglrenderer/-/ 
>> merge_requests/1568/ 
>> diffs#14086999aaf57fc68a3d7d639ab280c3a2672430:~:text=if%20(args%2D%3Eblob_flags%20%26%20VIRGL_RENDERER_BLOB_FLAG_USE_USERPTR)%20%7B
> Why does virglrenderer need to distinguish userspace and kernel?

It seems like the blob resource in virglrenderer doesn't support the 
guest resource/iov resource, virglrenderer doesn't let guest kernel 
resource go into get_blob callback.

But some feature I am working on really want to let guest userptr 
resource get in get_blob callback.

So I use this flag to extend the feature of virglrenderer blob callback.

The different is:
guest kernel resource -> won't go to blob callback.
guest userptr resource -> go to blob callback.







  reply	other threads:[~2025-11-21  6:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21  2:47 [v2 0/3] virtio-gpu: Add user pointer and HSAKMT support enhancements Honglei Huang
2025-11-21  2:47 ` [v2 1/3] virtio-gpu: Add support for VIRTIO_GPU_BLOB_FLAG_USE_USERPTR flag Honglei Huang
2025-11-21  2:56   ` Akihiko Odaki
2025-11-21  3:14     ` Honglei Huang
2025-11-21  3:39       ` Akihiko Odaki
2025-11-21  5:21         ` Honglei Huang
2025-11-21  5:28           ` Akihiko Odaki
2025-11-21  5:43             ` Honglei Huang
2025-11-21  6:12               ` Akihiko Odaki
2025-11-21  6:50                 ` Honglei Huang [this message]
2025-11-21  7:36                   ` Akihiko Odaki
2025-11-21  7:46                     ` Honglei Huang
2025-11-21  2:47 ` [v2 2/3] virtio-gpu: add configurable HSAKMT capset support Honglei Huang
2025-11-21  2:47 ` [v2 3/3] virtio-gpu: Add VIRTIO_GPU_F_RESOURCE_USERPTR feature support Honglei Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f95196fe-27c8-4eef-8b64-b1ede138425d@amd.com \
    --to=honghuan@amd.com \
    --cc=Ray.Huang@amd.com \
    --cc=alex.bennee@linaro.org \
    --cc=cohuck@redhat.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=mst@redhat.com \
    --cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).