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 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;
>>>
>>
> 



  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 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).