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 13:21:02 +0800 [thread overview]
Message-ID: <c33300b0-b4db-44b0-be07-4e4382a0c0fb@amd.com> (raw)
In-Reply-To: <ca2e398e-8158-4845-9798-6f444a73b103@rsg.ci.i.u-tokyo.ac.jp>
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.
Regards,
Honglei
>>
>>>
>>>> - Support guest_blob_mapped parameter for virgl renderer
>>>> - Fix value check issue in virtio-gpu
>>>>
>>>> This enables more flexible memory management between guest and host
>>>> for GPU virtualization scenarios.
>>>>
>>>> Signed-off-by: Honglei Huang <honghuan@amd.com>
>>>> ---
>>>> hw/display/virtio-gpu-virgl.c | 2 +-
>>>> hw/display/virtio-gpu.c | 7 -------
>>>> include/standard-headers/linux/virtio_gpu.h | 1 +
>>>> 3 files changed, 2 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-
>>>> virgl.c
>>>> index 07f6355ad6..c927275c79 100644
>>>> --- a/hw/display/virtio-gpu-virgl.c
>>>> +++ b/hw/display/virtio-gpu-virgl.c
>>>> @@ -705,7 +705,7 @@ static void
>>>> virgl_cmd_resource_create_blob(VirtIOGPU *g,
>>>> ret = virtio_gpu_create_mapping_iov(g, cblob.nr_entries,
>>>> sizeof(cblob),
>>>> cmd, &res->base.addrs,
>>>> &res->base.iov, &res-
>>>> >base.iov_cnt);
>>>> - if (!ret) {
>>>> + if (ret != 0) {
>>>> cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
>>>> return;
>>>> }
>>>> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
>>>> index 43e88a4daf..956dc811fa 100644
>>>> --- a/hw/display/virtio-gpu.c
>>>> +++ b/hw/display/virtio-gpu.c
>>>> @@ -808,13 +808,6 @@ int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
>>>> size_t esize, s;
>>>> int e, v;
>>>> - if (nr_entries > 16384) {
>>>> - qemu_log_mask(LOG_GUEST_ERROR,
>>>> - "%s: nr_entries is too big (%d > 16384)\n",
>>>> - __func__, nr_entries);
>>>> - return -1;
>>>> - }
>>>> -
>>>> esize = sizeof(*ents) * nr_entries;
>>>> ents = g_malloc(esize);
>>>> s = iov_to_buf(cmd->elem.out_sg, cmd->elem.out_num,
>>>> diff --git a/include/standard-headers/linux/virtio_gpu.h b/include/
>>>> standard-headers/linux/virtio_gpu.h
>>>> index 00cd3f04af..b85e781a2d 100644
>>>> --- a/include/standard-headers/linux/virtio_gpu.h
>>>> +++ b/include/standard-headers/linux/virtio_gpu.h
>>>> @@ -405,6 +405,7 @@ struct virtio_gpu_resource_create_blob {
>>>> #define VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE 0x0001
>>>> #define VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE 0x0002
>>>> #define VIRTIO_GPU_BLOB_FLAG_USE_CROSS_DEVICE 0x0004
>>>> +#define VIRTIO_GPU_BLOB_FLAG_USE_USERPTR 0x0008
>>>> /* zero is invalid blob mem */
>>>> uint32_t blob_mem;
>>>> uint32_t blob_flags;
>>>
>>
>
next prev parent reply other threads:[~2025-11-21 5:21 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 [this message]
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
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=c33300b0-b4db-44b0-be07-4e4382a0c0fb@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.