From: Honglei Huang <Honglei1.Huang@amd.com>
Add a new resource for blob resource, called userptr, used for let
host access guest user space memory, to acquire buffer based userptr
feature in virtio GPU.
- The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init,
in this series patches only HSAKMT context can use the userptr
feature. HSAKMT is a GPU compute library in HSA stack, like
the role libdrm in mesa stack.
- New flag VIRTIO_GPU_BLOB_FLAG_USE_USERPTR used in blob create
to indicate the blob create ioctl is used for create a userptr
blob resource.
Signed-off-by: Honglei Huang <Honglei1.Huang@amd.com>
---
include/uapi/linux/virtio_gpu.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index bf2c9cabd207..4da36a1e62c4 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux/virtio_gpu.h
@@ -65,6 +65,11 @@
*/
#define VIRTIO_GPU_F_CONTEXT_INIT 4
+/*
+ * VIRTGPU_BLOB_FLAG_USE_USERPTR
+ */
+#define VIRTIO_GPU_F_RESOURCE_USERPTR 5
+
enum virtio_gpu_ctrl_type {
VIRTIO_GPU_UNDEFINED = 0,
@@ -312,6 +317,7 @@ struct virtio_gpu_cmd_submit {
/* 3 is reserved for gfxstream */
#define VIRTIO_GPU_CAPSET_VENUS 4
#define VIRTIO_GPU_CAPSET_DRM 6
+#define VIRTIO_GPU_CAPSET_HSAKMT 8
/* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
struct virtio_gpu_get_capset_info {
@@ -404,6 +410,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 */
__le32 blob_mem;
__le32 blob_flags;
--
2.34.1On 2/28/25 12:36 AM, Honglei Huang wrote: > From: Honglei Huang <Honglei1.Huang@amd.com> > > Add a new resource for blob resource, called userptr, used for let > host access guest user space memory, to acquire buffer based userptr > feature in virtio GPU. > > - The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init, > in this series patches only HSAKMT context can use the userptr > feature. HSAKMT is a GPU compute library in HSA stack, like > the role libdrm in mesa stack. Userptr should not be limited to HSMKMT contexts. Userptr can accelerate shm buffers by avoiding a copy from guest to host, and it can be implemented using grant tables on Xen. -- Sincerely, Demi Marie Obenour (she/her/hers)
On 2025/3/1 5:21, Demi Marie Obenour wrote: > On 2/28/25 12:36 AM, Honglei Huang wrote: >> From: Honglei Huang <Honglei1.Huang@amd.com> >> >> Add a new resource for blob resource, called userptr, used for let >> host access guest user space memory, to acquire buffer based userptr >> feature in virtio GPU. >> >> - The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init, >> in this series patches only HSAKMT context can use the userptr >> feature. HSAKMT is a GPU compute library in HSA stack, like >> the role libdrm in mesa stack. > > Userptr should not be limited to HSMKMT contexts. Userptr can > accelerate shm buffers by avoiding a copy from guest to host, and > it can be implemented using grant tables on Xen. Yes, I totally agree userptr can accelerate shm buffers, but I currently don't know if there are any other projects working on similar features, or if maintainers have any opinions or better ways to implement them, so I temporarily limit this feature to HSAKMT context only. I am waiting for everyone's opinions, please provide your thoughts. Regards, Honglei
On 3/6/25 13:51, Huang, Honglei1 wrote: > > On 2025/3/1 5:21, Demi Marie Obenour wrote: >> On 2/28/25 12:36 AM, Honglei Huang wrote: >>> From: Honglei Huang <Honglei1.Huang@amd.com> >>> >>> Add a new resource for blob resource, called userptr, used for let >>> host access guest user space memory, to acquire buffer based userptr >>> feature in virtio GPU. >>> >>> - The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init, >>> in this series patches only HSAKMT context can use the userptr >>> feature. HSAKMT is a GPU compute library in HSA stack, like >>> the role libdrm in mesa stack. >> >> Userptr should not be limited to HSMKMT contexts. Userptr can >> accelerate shm buffers by avoiding a copy from guest to host, and >> it can be implemented using grant tables on Xen. > > Yes, I totally agree userptr can accelerate shm buffers, but I currently > don't know if there are any other projects working on similar features, > or if maintainers have any opinions or better ways to implement them, so > I temporarily limit this feature to HSAKMT context only. > > I am waiting for everyone's opinions, please provide your thoughts. USERPTR should be relevant for anything Vulkan-related, like Venus and native contexts. I expect that this new feature will work universally good for all context types. In order to merge USERPTR support upstream, we at least will need to prototype the guest USERPTR in one of native context driver to know that it works. You'll need to post the whole set of host/guest USERPTR patches including QEMU and etc, not just the kernel patches. -- Best regards, Dmitry
On 3/26/25 10:46 AM, Dmitry Osipenko wrote: > On 3/6/25 13:51, Huang, Honglei1 wrote: >> >> On 2025/3/1 5:21, Demi Marie Obenour wrote: >>> On 2/28/25 12:36 AM, Honglei Huang wrote: >>>> From: Honglei Huang <Honglei1.Huang@amd.com> >>>> >>>> Add a new resource for blob resource, called userptr, used for let >>>> host access guest user space memory, to acquire buffer based userptr >>>> feature in virtio GPU. >>>> >>>> - The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init, >>>> in this series patches only HSAKMT context can use the userptr >>>> feature. HSAKMT is a GPU compute library in HSA stack, like >>>> the role libdrm in mesa stack. >>> >>> Userptr should not be limited to HSMKMT contexts. Userptr can >>> accelerate shm buffers by avoiding a copy from guest to host, and >>> it can be implemented using grant tables on Xen. >> >> Yes, I totally agree userptr can accelerate shm buffers, but I currently >> don't know if there are any other projects working on similar features, >> or if maintainers have any opinions or better ways to implement them, so >> I temporarily limit this feature to HSAKMT context only. >> >> I am waiting for everyone's opinions, please provide your thoughts. > > USERPTR should be relevant for anything Vulkan-related, like Venus and > native contexts. I expect that this new feature will work universally > good for all context types. > > In order to merge USERPTR support upstream, we at least will need to > prototype the guest USERPTR in one of native context driver to know that > it works. You'll need to post the whole set of host/guest USERPTR > patches including QEMU and etc, not just the kernel patches. Does the user-mode VMM need to be QEMU or would patches to another open-source VMM, such as crosvm, be sufficient? -- Sincerely, Demi Marie Obenour (she/her/hers)
On 3/29/25 22:50, Demi Marie Obenour wrote: > On 3/26/25 10:46 AM, Dmitry Osipenko wrote: >> On 3/6/25 13:51, Huang, Honglei1 wrote: >>> >>> On 2025/3/1 5:21, Demi Marie Obenour wrote: >>>> On 2/28/25 12:36 AM, Honglei Huang wrote: >>>>> From: Honglei Huang <Honglei1.Huang@amd.com> >>>>> >>>>> Add a new resource for blob resource, called userptr, used for let >>>>> host access guest user space memory, to acquire buffer based userptr >>>>> feature in virtio GPU. >>>>> >>>>> - The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init, >>>>> in this series patches only HSAKMT context can use the userptr >>>>> feature. HSAKMT is a GPU compute library in HSA stack, like >>>>> the role libdrm in mesa stack. >>>> >>>> Userptr should not be limited to HSMKMT contexts. Userptr can >>>> accelerate shm buffers by avoiding a copy from guest to host, and >>>> it can be implemented using grant tables on Xen. >>> >>> Yes, I totally agree userptr can accelerate shm buffers, but I currently >>> don't know if there are any other projects working on similar features, >>> or if maintainers have any opinions or better ways to implement them, so >>> I temporarily limit this feature to HSAKMT context only. >>> >>> I am waiting for everyone's opinions, please provide your thoughts. >> >> USERPTR should be relevant for anything Vulkan-related, like Venus and >> native contexts. I expect that this new feature will work universally >> good for all context types. >> >> In order to merge USERPTR support upstream, we at least will need to >> prototype the guest USERPTR in one of native context driver to know that >> it works. You'll need to post the whole set of host/guest USERPTR >> patches including QEMU and etc, not just the kernel patches. > > Does the user-mode VMM need to be QEMU or would patches to > another open-source VMM, such as crosvm, be sufficient? General-purpose features should be made supported by QEMU when possible. Testing feedback for other VMMs will be very valuable too. -- Best regards, Dmitry
On 2025/3/26 22:46, Dmitry Osipenko wrote: > On 3/6/25 13:51, Huang, Honglei1 wrote: >> >> On 2025/3/1 5:21, Demi Marie Obenour wrote: >>> On 2/28/25 12:36 AM, Honglei Huang wrote: >>>> From: Honglei Huang <Honglei1.Huang@amd.com> >>>> >>>> Add a new resource for blob resource, called userptr, used for let >>>> host access guest user space memory, to acquire buffer based userptr >>>> feature in virtio GPU. >>>> >>>> - The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init, >>>> in this series patches only HSAKMT context can use the userptr >>>> feature. HSAKMT is a GPU compute library in HSA stack, like >>>> the role libdrm in mesa stack. >>> >>> Userptr should not be limited to HSMKMT contexts. Userptr can >>> accelerate shm buffers by avoiding a copy from guest to host, and >>> it can be implemented using grant tables on Xen. >> >> Yes, I totally agree userptr can accelerate shm buffers, but I currently >> don't know if there are any other projects working on similar features, >> or if maintainers have any opinions or better ways to implement them, so >> I temporarily limit this feature to HSAKMT context only. >> >> I am waiting for everyone's opinions, please provide your thoughts. > > USERPTR should be relevant for anything Vulkan-related, like Venus and > native contexts. I expect that this new feature will work universally > good for all context types. > > In order to merge USERPTR support upstream, we at least will need to > prototype the guest USERPTR in one of native context driver to know that > it works. You'll need to post the whole set of host/guest USERPTR > patches including QEMU and etc, not just the kernel patches. Ok totally understood, I will upload other components as soon as possiable, cause we only have limited resource for this matter, please understand the speed is relatively slow. And for Vulkan use case, yes it is very important, I will make some prototype implementation for it, and will test it locally. The implementation for USERPTR must comply with Vulakan's standard. Really thanks for your comments. Reagrds, Honglei >
On 3/27/25 06:00, Huang, Honglei1 wrote: > > > On 2025/3/26 22:46, Dmitry Osipenko wrote: >> On 3/6/25 13:51, Huang, Honglei1 wrote: >>> >>> On 2025/3/1 5:21, Demi Marie Obenour wrote: >>>> On 2/28/25 12:36 AM, Honglei Huang wrote: >>>>> From: Honglei Huang <Honglei1.Huang@amd.com> >>>>> >>>>> Add a new resource for blob resource, called userptr, used for let >>>>> host access guest user space memory, to acquire buffer based userptr >>>>> feature in virtio GPU. >>>>> >>>>> - The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init, >>>>> in this series patches only HSAKMT context can use the userptr >>>>> feature. HSAKMT is a GPU compute library in HSA stack, like >>>>> the role libdrm in mesa stack. >>>> >>>> Userptr should not be limited to HSMKMT contexts. Userptr can >>>> accelerate shm buffers by avoiding a copy from guest to host, and >>>> it can be implemented using grant tables on Xen. >>> >>> Yes, I totally agree userptr can accelerate shm buffers, but I currently >>> don't know if there are any other projects working on similar features, >>> or if maintainers have any opinions or better ways to implement them, so >>> I temporarily limit this feature to HSAKMT context only. >>> >>> I am waiting for everyone's opinions, please provide your thoughts. >> >> USERPTR should be relevant for anything Vulkan-related, like Venus and >> native contexts. I expect that this new feature will work universally >> good for all context types. >> >> In order to merge USERPTR support upstream, we at least will need to >> prototype the guest USERPTR in one of native context driver to know that >> it works. You'll need to post the whole set of host/guest USERPTR >> patches including QEMU and etc, not just the kernel patches. > > Ok totally understood, I will upload other components as soon as > possiable, cause we only have limited resource for this matter, please > understand the speed is relatively slow. > And for Vulkan use case, yes it is very important, I will make some > prototype implementation for it, and will test it locally. The > implementation for USERPTR must comply with Vulakan's standard. > Really thanks for your comments. We aren't in rush, thanks for working on this feature. -- Best regards, Dmitry
© 2016 - 2025 Red Hat, Inc.