[virtio-comment] [RFC PATCH 0/2] Blob resources + host visible memory

[virtio-comment] [RFC PATCH 0/2] Blob resources + host visible memory

[Gurchetan Singh]

Dear all,

I'm excited to share with you an exciting development in the field
of virtualized graphics: blob resources. Blob resources represent
the evolution of virtio-gpu from the OpenGL resource model to the
VK resource model. Details are in the spec.

Proof of concept kernel[1] and virglrenderer[2] implementations exist,
so it's a good time to formalize the spec, so we can parallelize the
efforts.

Enumerations follow the current virtio-gpu trend and start at 1, where
0 is an invalid value.

Blob resources were developed in collaboration by Gerd Hoffman,
Chia-I-Wu and Gurchetan Singh.

Open questions:
   - TRANSFER_BLOB along with reusing previously hypercalls for
     convenience?
   - Anything else people want?

Possible required changes:
   - Refactoring Pixman dependency in QEMU for blob resources in
     2D hosts?

Possible future work:
   - Emulated coherent `blob_mem` type for QEMU/vhost-user
   - A `blob_mem` type for guest-only resources imported in
     cache-coherent FOSS GPU/display drivers using udmabuf-like
     mechanisms.
   - Display integration involving the blob model.

These spec patches are based on David Steven's UUID patches (hopefully
those will land soon?).

[1] https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commits/resource-blob
[2] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/374

Gurchetan Singh (2):
  virtio-gpu: add resource create blob
  virtio-gpu: add support for mapping/unmapping blob resources

 virtio-gpu.tex | 172 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 168 insertions(+), 4 deletions(-)

-- 
2.24.1


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] [PATCH 1/2] virtio-gpu: add resource create blob

[Gurchetan Singh]

Blob resources are size-based containers for host, guest, or
host+guest allocations.  These resources are designed with
mulit-process 3D support in mind, but also usable in virtio-gpu 2d
with system memory allocation (also known as dumb allocation, but
since that's reserved in a DRM/KMS world, went with system).

Many hypercalls are reused, since a image view into the blob resource
is possible.

Blob resources are both forward and backward looking.

Co-authored-by: Gerd Hoffman <kraxel@redhat.com>
Co-authored-by: Chia-I-Wu <olvaffe@gmail.com>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
---
 virtio-gpu.tex | 101 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 101 insertions(+)

diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index e70532f..6f374bd 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -36,6 +36,7 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
 \item[VIRTIO_GPU_F_VIRGL (0)] virgl 3D mode is supported.
 \item[VIRTIO_GPU_F_EDID  (1)] EDID is supported.
 \item[VIRTIO_GPU_F_RESOURCE_UUID (2)] assigning resources UUIDs for export to other virtio devices is supported.
+\item[VIRTIO_GPU_F_RESOURCE_BLOB (3)] creating size-based blob resources is supported.
 \end{description}
 
 \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -188,6 +189,7 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
         VIRTIO_GPU_CMD_GET_CAPSET,
         VIRTIO_GPU_CMD_GET_EDID,
         VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
+        VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
 
         /* 3d commands (OpenGL) */
         VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -498,6 +500,105 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
 other devices are not visible in the attached backing until they are transferred
 into the backing.
 
+\item[VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB] Creates a virtio-gpu blob
+  resource. Request data is \field{struct
+  virtio_gpu_resource_create_blob}, followed by \field{struct
+  virtio_gpu_mem_entry} entries. Response type is
+  VIRTIO_GPU_RESP_OK_NODATA. Support is optional and negotiated
+  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag.
+
+\begin{lstlisting}
+#define VIRTIO_GPU_BLOB_MEM_GUEST             0x0001
+#define VIRTIO_GPU_BLOB_MEM_HOST3D            0x0002
+#define VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST      0x0003
+#define VIRTIO_GPU_BLOB_MEM_HOSTSYS           0x0004
+#define VIRTIO_GPU_BLOB_MEM_HOSTSYS_GUEST     0x0005
+
+#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
+
+struct virtio_gpu_resource_create_blob {
+       struct virtio_gpu_ctrl_hdr hdr;
+       le32 resource_id;
+       le32 blob_mem;
+       le32 blob_flags;
+       le32 nr_entries;
+       le64 blob_id;
+       le64 size;
+};
+
+\end{lstlisting}
+
+A blob resource is a container for:
+
+  \begin{itemize*}
+  \item a guest memory allocation (referred to as a
+  "guest-only blob resource").
+  \item a host memory allocation (referred to as a
+  "host-only blob resource").
+  \item a guest memory and host memory allocation (referred
+  to as a "default blob resource").
+  \end{itemize*}
+
+The memory properties of the blob resource MUST be described by
+\field{blob_mem}, which MUST be non-zero.
+
+For default and guest-only blob resources, \field{nents} guest
+system pages are assigned to the resource.  For default blob
+resources, these guest pages are used for transfer operations.
+
+Host allocations depend on whether VIRTIO_GPU_F_VIRGL is supported.
+If VIRTIO_GPU_F_VIRGL is not supported, then:
+
+  \begin{itemize*}
+  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOSTSYS for host-only
+  blob resources
+  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOSTSYS_GUEST for
+  default blob resources
+  \end{itemize*}
+
+For the above above cases, host system memory is allocated by the device.
+
+If VIRTIO_GPU_F_VIRGL is supported, then:
+
+  \begin{itemize*}
+  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOST3D for host-only
+  blob resources
+  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST for
+  default resources
+  \end{itemize*}
+
+For the above cases, the virtio-gpu resource MUST be created from the
+rendering context local object identified by the \field{blob_id}. The
+actual allocation is done via VIRTIO_GPU_CMD_SUBMIT_3D.
+
+VIRTIO_GPU_BLOB_MEM_GUEST is valid regardless whether VIRTIO_GPU_F_VIRGL
+is supported or not.
+
+The driver MUST inform the device if the blob resource is used for
+memory access, sharing between driver instances and/or sharing with
+other devices. This is done via the \field{blob_flags} field.
+
+If VIRTIO_GPU_F_VIRGL is set, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
+and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
+resource. There is no restriction on the image/buffer view the driver
+has on the blob resource.
+
+VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D, VIRTIO_GPU_CMD_SET_SCANOUT and
+VIRTIO_GPU_CMD_RESOURCE_FLUSH MAY be used with blob resources as well,
+subject to the following restrictions:
+
+  \begin{itemize*}
+  \item the driver MUST have a 4-byte per pixel 2D image view of the
+        blob resource.
+  \item the device MUST have a 4-byte per pixel 2D image view of the
+        blob resource, or create one if does not exist.
+  \end{itemize*}
+
+For host-only blob resources, transfer operations MAY synchronize
+caches.
+
 \end{description}
 
 \subsubsection{Device Operation: controlq (3d)}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq (3d)}
-- 
2.24.1


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] [PATCH 2/2] virtio-gpu: add support for mapping/unmapping blob resources

[Gurchetan Singh]

This defines a virtgpu shared memory region, with the possibilty
of more in the future.  This is required to implement VK/GL coherent
memory semantics, among other things.

Does anyone know when VIRTIO_PCI_CAP_SHARED_MEMORY_CFG is expected
to land in the Linux kernel?

Co-authored-by: Gerd Hoffman <kraxel@redhat.com>
Co-authored-by: Chia-I-Wu <olvaffe@gmail.com>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
---
 virtio-gpu.tex | 71 +++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 67 insertions(+), 4 deletions(-)

diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index 6f374bd..a19536d 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -88,13 +88,31 @@ \subsubsection{Events}
 information is available or all displays are disabled the driver MAY
 choose to use a fallback, such as 1024x768 at display 0.
 
+The driver SHOULD query all shared memory regions supported by the device.
+If the device supports shared memory, the \field{shmid} of a region MUST
+(see \ref{sec:Basic Facilities of a Virtio Device /
+Shared Memory Regions}~\nameref{sec:Basic Facilities of a Virtio Device /
+Shared Memory Regions}) be one of the following:
+
+\begin{lstlisting}
+enum virtio_gpu_shm_id {
+        VIRTIO_GPU_SHM_ID_UNDEFINED = 0,
+        VIRTIO_GPU_SHM_ID_HOST_VISIBLE = 1,
+};
+\end{lstlisting}
+
+The shared memory region with VIRTIO_GPU_SHM_ID_HOST_VISIBLE is referred as
+the "host visible memory region".  The device MUST support the
+VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB and VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB
+if the host visible memory region is available.
+
 \subsection{Device Operation}\label{sec:Device Types / GPU Device / Device Operation}
 
 The virtio-gpu is based around the concept of resources private to the
-host, the guest must DMA transfer into these resources. This is a
-design requirement in order to interface with future 3D rendering. In
-the unaccelerated 2D mode there is no support for DMA transfers from
-resources, just to them.
+host.  The guest must DMA transfer into these resources, unless shared memory
+regions are supported. This is a design requirement in order to interface with
+future 3D rendering. In the unaccelerated 2D mode there is no support for DMA
+transfers from resources, just to them.
 
 Resources are initially simple 2D resources, consisting of a width,
 height and format along with an identifier. The guest must then attach
@@ -190,6 +208,8 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
         VIRTIO_GPU_CMD_GET_EDID,
         VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
         VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
+        VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB,
+        VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB,
 
         /* 3d commands (OpenGL) */
         VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -212,6 +232,7 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
         VIRTIO_GPU_RESP_OK_CAPSET,
         VIRTIO_GPU_RESP_OK_EDID,
         VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
+        VIRTIO_GPU_RESP_OK_MAP_INFO,
 
         /* error responses */
         VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
@@ -599,6 +620,48 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
 For host-only blob resources, transfer operations MAY synchronize
 caches.
 
+\item[VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB] maps a host-only
+  blob resource into an offset in the host visible memory region. Request
+  data is \field{struct virtio_gpu_resource_map_blob}.  Response type
+  is VIRTIO_GPU_RESP_OK_MAP_INFO. Support is optional and negotiated
+  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag and checking for
+  the presence of the host visible memory region.
+
+\begin{lstlisting}
+/* VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB */
+struct virtio_gpu_resource_map_blob {
+        struct virtio_gpu_ctrl_hdr hdr;
+        le32 resource_id;
+        le32 padding;
+        le64 offset;
+};
+
+/* VIRTIO_GPU_RESP_OK_MAP_INFO */
+#define VIRTIO_GPU_MAP_CACHE_MASK      0x0f
+#define VIRTIO_GPU_MAP_CACHE_NONE      0x00
+#define VIRTIO_GPU_MAP_CACHE_CACHED    0x01
+#define VIRTIO_GPU_MAP_CACHE_UNCACHED  0x02
+#define VIRTIO_GPU_MAP_CACHE_WC        0x03
+struct virtio_gpu_resp_map_info {
+        struct virtio_gpu_ctrl_hdr hdr;
+        u32 map_info;
+        u32 padding;
+};
+\end{lstlisting}
+
+\item[VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB] unmaps a
+  host-only blob resource from the host visible memory region. Request data
+  is \field{struct virtio_gpu_resource_unmap_blob}.  Response type is
+  VIRTIO_GPU_RESP_OK_NODATA.  Support is optional and negotiated
+  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag and checking for
+  the presence of the host visible memory region.
+
+struct virtio_gpu_resource_unmap_blob {
+        struct virtio_gpu_ctrl_hdr hdr;
+        le32 resource_id;
+        le32 padding;
+};
+
 \end{description}
 
 \subsubsection{Device Operation: controlq (3d)}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq (3d)}
-- 
2.24.1


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] Re: [PATCH 1/2] virtio-gpu: add resource create blob

[Gerd Hoffmann]

On Tue, Apr 21, 2020 at 05:55:30PM -0700, Gurchetan Singh wrote:
> Blob resources are size-based containers for host, guest, or
> host+guest allocations.  These resources are designed with
> mulit-process 3D support in mind, but also usable in virtio-gpu 2d
> with system memory allocation (also known as dumb allocation, but
> since that's reserved in a DRM/KMS world, went with system).

Thanks for picking this up.

> +Host allocations depend on whether VIRTIO_GPU_F_VIRGL is supported.
> +If VIRTIO_GPU_F_VIRGL is not supported, then:
> +
> +  \begin{itemize*}
> +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOSTSYS for host-only
> +  blob resources
> +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOSTSYS_GUEST for
> +  default blob resources
> +  \end{itemize*}
> +
> +For the above above cases, host system memory is allocated by the device.
> +
> +If VIRTIO_GPU_F_VIRGL is supported, then:
> +
> +  \begin{itemize*}
> +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOST3D for host-only
> +  blob resources
> +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST for
> +  default resources
> +  \end{itemize*}

Do we need separate items (HOSTSYS/HOST3D) for these?  Shouldn't this be
a host implementation detail the guest doesn't need to worry about?

Also: Why HOST3D + HOST3D_GUEST?  Isn't that covered by the use flags
(MAPPABLE) already?

> +If VIRTIO_GPU_F_VIRGL is set, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
> +and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
> +resource. There is no restriction on the image/buffer view the driver
> +has on the blob resource.

I don't think VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D is going to work if
the resource has no format attached.  I had a TRANSFER_BLOB command
because of that.

> +VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D, VIRTIO_GPU_CMD_SET_SCANOUT and
> +VIRTIO_GPU_CMD_RESOURCE_FLUSH MAY be used with blob resources as well,
> +subject to the following restrictions:

Same problem with VIRTIO_GPU_CMD_SET_SCANOUT, it expects the resource
has a format attached which isn't the case for blob resources ...

cheers,
  Gerd


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] Re: [PATCH 2/2] virtio-gpu: add support for mapping/unmapping blob resources

[Gerd Hoffmann]

On Tue, Apr 21, 2020 at 05:55:31PM -0700, Gurchetan Singh wrote:
> This defines a virtgpu shared memory region, with the possibilty
> of more in the future.  This is required to implement VK/GL coherent
> memory semantics, among other things.
> 
> Does anyone know when VIRTIO_PCI_CAP_SHARED_MEMORY_CFG is expected
> to land in the Linux kernel?

virtfs needs this when DAX support lands, so it should not be that far
away ...

Patch looks fine to me.

take care,
  Gerd

> Co-authored-by: Gerd Hoffman <kraxel@redhat.com>
> Co-authored-by: Chia-I-Wu <olvaffe@gmail.com>
> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
> ---
>  virtio-gpu.tex | 71 +++++++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 67 insertions(+), 4 deletions(-)
> 
> diff --git a/virtio-gpu.tex b/virtio-gpu.tex
> index 6f374bd..a19536d 100644
> --- a/virtio-gpu.tex
> +++ b/virtio-gpu.tex
> @@ -88,13 +88,31 @@ \subsubsection{Events}
>  information is available or all displays are disabled the driver MAY
>  choose to use a fallback, such as 1024x768 at display 0.
>  
> +The driver SHOULD query all shared memory regions supported by the device.
> +If the device supports shared memory, the \field{shmid} of a region MUST
> +(see \ref{sec:Basic Facilities of a Virtio Device /
> +Shared Memory Regions}~\nameref{sec:Basic Facilities of a Virtio Device /
> +Shared Memory Regions}) be one of the following:
> +
> +\begin{lstlisting}
> +enum virtio_gpu_shm_id {
> +        VIRTIO_GPU_SHM_ID_UNDEFINED = 0,
> +        VIRTIO_GPU_SHM_ID_HOST_VISIBLE = 1,
> +};
> +\end{lstlisting}
> +
> +The shared memory region with VIRTIO_GPU_SHM_ID_HOST_VISIBLE is referred as
> +the "host visible memory region".  The device MUST support the
> +VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB and VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB
> +if the host visible memory region is available.
> +
>  \subsection{Device Operation}\label{sec:Device Types / GPU Device / Device Operation}
>  
>  The virtio-gpu is based around the concept of resources private to the
> -host, the guest must DMA transfer into these resources. This is a
> -design requirement in order to interface with future 3D rendering. In
> -the unaccelerated 2D mode there is no support for DMA transfers from
> -resources, just to them.
> +host.  The guest must DMA transfer into these resources, unless shared memory
> +regions are supported. This is a design requirement in order to interface with
> +future 3D rendering. In the unaccelerated 2D mode there is no support for DMA
> +transfers from resources, just to them.
>  
>  Resources are initially simple 2D resources, consisting of a width,
>  height and format along with an identifier. The guest must then attach
> @@ -190,6 +208,8 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
>          VIRTIO_GPU_CMD_GET_EDID,
>          VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
>          VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
> +        VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB,
> +        VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB,
>  
>          /* 3d commands (OpenGL) */
>          VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
> @@ -212,6 +232,7 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
>          VIRTIO_GPU_RESP_OK_CAPSET,
>          VIRTIO_GPU_RESP_OK_EDID,
>          VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
> +        VIRTIO_GPU_RESP_OK_MAP_INFO,
>  
>          /* error responses */
>          VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
> @@ -599,6 +620,48 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
>  For host-only blob resources, transfer operations MAY synchronize
>  caches.
>  
> +\item[VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB] maps a host-only
> +  blob resource into an offset in the host visible memory region. Request
> +  data is \field{struct virtio_gpu_resource_map_blob}.  Response type
> +  is VIRTIO_GPU_RESP_OK_MAP_INFO. Support is optional and negotiated
> +  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag and checking for
> +  the presence of the host visible memory region.
> +
> +\begin{lstlisting}
> +/* VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB */
> +struct virtio_gpu_resource_map_blob {
> +        struct virtio_gpu_ctrl_hdr hdr;
> +        le32 resource_id;
> +        le32 padding;
> +        le64 offset;
> +};
> +
> +/* VIRTIO_GPU_RESP_OK_MAP_INFO */
> +#define VIRTIO_GPU_MAP_CACHE_MASK      0x0f
> +#define VIRTIO_GPU_MAP_CACHE_NONE      0x00
> +#define VIRTIO_GPU_MAP_CACHE_CACHED    0x01
> +#define VIRTIO_GPU_MAP_CACHE_UNCACHED  0x02
> +#define VIRTIO_GPU_MAP_CACHE_WC        0x03
> +struct virtio_gpu_resp_map_info {
> +        struct virtio_gpu_ctrl_hdr hdr;
> +        u32 map_info;
> +        u32 padding;
> +};
> +\end{lstlisting}
> +
> +\item[VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB] unmaps a
> +  host-only blob resource from the host visible memory region. Request data
> +  is \field{struct virtio_gpu_resource_unmap_blob}.  Response type is
> +  VIRTIO_GPU_RESP_OK_NODATA.  Support is optional and negotiated
> +  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag and checking for
> +  the presence of the host visible memory region.
> +
> +struct virtio_gpu_resource_unmap_blob {
> +        struct virtio_gpu_ctrl_hdr hdr;
> +        le32 resource_id;
> +        le32 padding;
> +};
> +
>  \end{description}
>  
>  \subsubsection{Device Operation: controlq (3d)}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq (3d)}
> -- 
> 2.24.1
> 


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] Re: [PATCH 1/2] virtio-gpu: add resource create blob

[Gurchetan Singh]

[-- Attachment #1: Type: text/plain, Size: 5106 bytes --]

On Tue, Apr 28, 2020 at 3:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Tue, Apr 21, 2020 at 05:55:30PM -0700, Gurchetan Singh wrote:
> > Blob resources are size-based containers for host, guest, or
> > host+guest allocations.  These resources are designed with
> > mulit-process 3D support in mind, but also usable in virtio-gpu 2d
> > with system memory allocation (also known as dumb allocation, but
> > since that's reserved in a DRM/KMS world, went with system).
>
> Thanks for picking this up.
>

No problem, thanks for getting the ball rolling!


> > +Host allocations depend on whether VIRTIO_GPU_F_VIRGL is supported.
> > +If VIRTIO_GPU_F_VIRGL is not supported, then:
> > +
> > +  \begin{itemize*}
> > +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOSTSYS for
> host-only
> > +  blob resources
> > +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOSTSYS_GUEST for
> > +  default blob resources
> > +  \end{itemize*}
> > +
> > +For the above above cases, host system memory is allocated by the
> device.
> > +
> > +If VIRTIO_GPU_F_VIRGL is supported, then:
> > +
> > +  \begin{itemize*}
> > +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOST3D for
> host-only
> > +  blob resources
> > +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST for
> > +  default resources
> > +  \end{itemize*}
>
> Do we need separate items (HOSTSYS/HOST3D) for these?  Shouldn't this be
> a host implementation detail the guest doesn't need to worry about?
>

Yes, separate items are not needed and could indeed be an host
implementation detail.  Right now, the drm uapi has VIRTGPU_BLOB_MEM_HOST /
VIRTIO_GPU_BLOB_MEM_HOST_GUEST and the kernel separates to HOST{SYS,3D} and
does various checks.

https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commit/0ccb47d5150a2978d179d0c44ef3285541c8964c


The reasoning is since there's no RESOURCE_CREATE_BLOB2D
or RESOURCE_CREATE_BLOB3D, the separation captures that difference in an
explicit API level.  That way, the blob id is only allowed with HOST3D.

But naming/enums is definitely mutable and open to suggestions if this
reasoning doesn't seem right.

Also: Why HOST3D + HOST3D_GUEST?  Isn't that covered by the use flags
> (MAPPABLE) already?
>

A HOST3D blob has no guest memory associated with it, and can only be
mapped through the shm region.  Even then, a linear (mappable) view of a
host3d blob may not be possible/desirable -- like shareable device local
memory, or maybe even a protected content blob.

HOST3D_GUEST is always mappable, while HOST3D isn't.


> > +If VIRTIO_GPU_F_VIRGL is set, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
> > +and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
> > +resource. There is no restriction on the image/buffer view the driver
> > +has on the blob resource.
>
> I don't think VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D is going to work if
> the resource has no format attached.  I had a TRANSFER_BLOB command
> because of that.
>

I was thinking about GL/VK interop here.

Say VK allocates the blob resource, but a GL texture is subsequently
created from the blob resource using GL/VK interop extensions and a format
is attached.  For this reason, VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D is
allowed on blob resources.

Similarly, virtgpu_kms always attaches XR24 and AB24 to resources[1], so
VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D can be reused if size = 4 * width for
dumb/sys blob resources (which I think will always be the case?).

TRANSFER_BLOB is definitely useful for things that can't fit neatly into
the previous hypercalls (YUV formats in virtgpu_kms?), and could be useful
for optimizing emulated coherent memory (if we ever add it).  The current
prototype doesn't really use TRANSFER_BLOB though, but if you have use
cases in mind, it is definitely easy to add.

[1]
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/virtio/virtgpu_plane.c#L33


> > +VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D, VIRTIO_GPU_CMD_SET_SCANOUT and
> > +VIRTIO_GPU_CMD_RESOURCE_FLUSH MAY be used with blob resources as well,
> > +subject to the following restrictions:
>
> Same problem with VIRTIO_GPU_CMD_SET_SCANOUT, it expects the resource
> has a format attached which isn't the case for blob resources ...


Ack.  I definitely see the logic behind VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
but current display integration (dpy_gl_scanout_texture(..) in QEMU)
assumes the presence of a GL texture (which can be created from a blob
resource).  So we'll need to change the display integration to be Wayland
based, and pass (offsets[4], strides[4], virtualized modifier?, a few other
things) via VIRTIO_GPU_CMD_SET_SCANOUT_BLOB.  But I think that'll only work
if only in a Zink + VK1.1-only world where GL never allocates.

That's a lot of changes, the current spec does what's needed for zero-copy
VK/GL, and attempts to be forward looking for future changes.  We may need
additional feature bits for more advanced display integration.


>
> cheers,
>   Gerd
>
>

[-- Attachment #2: Type: text/html, Size: 6912 bytes --]

[virtio-comment] Re: [PATCH 1/2] virtio-gpu: add resource create blob

[Gerd Hoffmann]

  Hi,

> > Do we need separate items (HOSTSYS/HOST3D) for these?  Shouldn't this be
> > a host implementation detail the guest doesn't need to worry about?
> 
> Yes, separate items are not needed and could indeed be an host
> implementation detail.  Right now, the drm uapi has VIRTGPU_BLOB_MEM_HOST /
> VIRTIO_GPU_BLOB_MEM_HOST_GUEST and the kernel separates to HOST{SYS,3D} and
> does various checks.
> 
> https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commit/0ccb47d5150a2978d179d0c44ef3285541c8964c
> 
> 
> The reasoning is since there's no RESOURCE_CREATE_BLOB2D
> or RESOURCE_CREATE_BLOB3D, the separation captures that difference in an
> explicit API level.  That way, the blob id is only allowed with HOST3D.

I think we can also simply define "blob id is only allowed virgl=on", no
need for a separate command.

> A HOST3D blob has no guest memory associated with it, and can only be
> mapped through the shm region.  Even then, a linear (mappable) view of a
> host3d blob may not be possible/desirable -- like shareable device local
> memory, or maybe even a protected content blob.
> 
> HOST3D_GUEST is always mappable, while HOST3D isn't.

Ok.  So _GUEST postfix means there is a guest shadow and we TRANSFER
data instead of mapping the host resource directly.  Ok, makes sense,
needs a better description in the spec though.

> > > +If VIRTIO_GPU_F_VIRGL is set, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
> > > +and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
> > > +resource. There is no restriction on the image/buffer view the driver
> > > +has on the blob resource.
> >
> > I don't think VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D is going to work if
> > the resource has no format attached.  I had a TRANSFER_BLOB command
> > because of that.
> >
> 
> I was thinking about GL/VK interop here.
> 
> Say VK allocates the blob resource, but a GL texture is subsequently
> created from the blob resource using GL/VK interop extensions and a format
> is attached.  For this reason, VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D is
> allowed on blob resources.

Makes sense to allow the old transfer commands for the cases where the
resource has a format attached.

> Similarly, virtgpu_kms always attaches XR24 and AB24 to resources[1], so
> VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D can be reused if size = 4 * width for
> dumb/sys blob resources (which I think will always be the case?).

If the kernel uses BLOB resources for dumb BOs (so we can have a shared
mapping for them and avoid copying fbdev data) they will not have a
format attached.

Imported dma-bufs (inside the guest) don't have a format attached
either.  With BLOB resources we can support this, but we'll likewise get
a resource without format attached.

So we need ways to work with those resources ...

> Ack.  I definitely see the logic behind VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
> but current display integration (dpy_gl_scanout_texture(..) in QEMU)
> assumes the presence of a GL texture (which can be created from a blob
> resource).

I have a qemu VIRTIO_GPU_CMD_SET_SCANOUT_BLOB implementation for
virgl=off only, covering dumb bo / fbdev as outlined above.

With virgl=on this should be doable too, you only have to create the
texture from the blob resource at SET_SCANOUT_BLOB time (when you know
the format the guest wants scanout), not at resource creation time.

take care,
  Gerd


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Re: [PATCH 1/2] virtio-gpu: add resource create blob

[Chia-I Wu]

On Wed, Apr 29, 2020 at 2:28 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > > Do we need separate items (HOSTSYS/HOST3D) for these?  Shouldn't this be
> > > a host implementation detail the guest doesn't need to worry about?
> >
> > Yes, separate items are not needed and could indeed be an host
> > implementation detail.  Right now, the drm uapi has VIRTGPU_BLOB_MEM_HOST /
> > VIRTIO_GPU_BLOB_MEM_HOST_GUEST and the kernel separates to HOST{SYS,3D} and
> > does various checks.
> >
> > https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commit/0ccb47d5150a2978d179d0c44ef3285541c8964c
> >
> >
> > The reasoning is since there's no RESOURCE_CREATE_BLOB2D
> > or RESOURCE_CREATE_BLOB3D, the separation captures that difference in an
> > explicit API level.  That way, the blob id is only allowed with HOST3D.
>
> I think we can also simply define "blob id is only allowed virgl=on", no
> need for a separate command.

With a single command, can blob_id be 0 when virgl=on?  Does the host
have enough info to know where to allocate from?

It seems we want HOSTSYS such that we can create dumb bos that are not
shadowed.  How about favoring GUEST for that use case instead?  Some
VMMs cannot support mapping a HOSTSYS into the guest.  The downside
would be that VMMs only see a dumb bo as an array of
virtio_gpu_mem_entry.  VMMs that need a linear mapping would need
something like udmabuf.

VIRTIO_GPU_CMD_SET_SCANOUT_BLOB below makes sense.

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] [PATCH 1/2] virtio-gpu: add resource create blob

[Michael S. Tsirkin]

On Tue, Apr 21, 2020 at 05:55:30PM -0700, Gurchetan Singh wrote:
> Blob resources are size-based containers for host, guest, or
> host+guest allocations.  These resources are designed with
> mulit-process 3D support in mind, but also usable in virtio-gpu 2d
> with system memory allocation (also known as dumb allocation, but
> since that's reserved in a DRM/KMS world, went with system).
> 
> Many hypercalls are reused, since a image view into the blob resource
> is possible.
> 
> Blob resources are both forward and backward looking.
> 
> Co-authored-by: Gerd Hoffman <kraxel@redhat.com>
> Co-authored-by: Chia-I-Wu <olvaffe@gmail.com>

Pls just use standard Signed-off-by.


> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
> ---
>  virtio-gpu.tex | 101 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 101 insertions(+)
> 
> diff --git a/virtio-gpu.tex b/virtio-gpu.tex
> index e70532f..6f374bd 100644
> --- a/virtio-gpu.tex
> +++ b/virtio-gpu.tex
> @@ -36,6 +36,7 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
>  \item[VIRTIO_GPU_F_VIRGL (0)] virgl 3D mode is supported.
>  \item[VIRTIO_GPU_F_EDID  (1)] EDID is supported.
>  \item[VIRTIO_GPU_F_RESOURCE_UUID (2)] assigning resources UUIDs for export to other virtio devices is supported.
> +\item[VIRTIO_GPU_F_RESOURCE_BLOB (3)] creating size-based blob resources is supported.
>  \end{description}
>  
>  \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
> @@ -188,6 +189,7 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
>          VIRTIO_GPU_CMD_GET_CAPSET,
>          VIRTIO_GPU_CMD_GET_EDID,
>          VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
> +        VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
>  
>          /* 3d commands (OpenGL) */
>          VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
> @@ -498,6 +500,105 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
>  other devices are not visible in the attached backing until they are transferred
>  into the backing.
>  
> +\item[VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB] Creates a virtio-gpu blob
> +  resource. Request data is \field{struct
> +  virtio_gpu_resource_create_blob}, followed by \field{struct
> +  virtio_gpu_mem_entry} entries. Response type is
> +  VIRTIO_GPU_RESP_OK_NODATA. Support is optional and negotiated
> +  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag.
> +
> +\begin{lstlisting}
> +#define VIRTIO_GPU_BLOB_MEM_GUEST             0x0001
> +#define VIRTIO_GPU_BLOB_MEM_HOST3D            0x0002
> +#define VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST      0x0003
> +#define VIRTIO_GPU_BLOB_MEM_HOSTSYS           0x0004
> +#define VIRTIO_GPU_BLOB_MEM_HOSTSYS_GUEST     0x0005
> +
> +#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
> +
> +struct virtio_gpu_resource_create_blob {
> +       struct virtio_gpu_ctrl_hdr hdr;
> +       le32 resource_id;
> +       le32 blob_mem;
> +       le32 blob_flags;
> +       le32 nr_entries;
> +       le64 blob_id;
> +       le64 size;
> +};
> +
> +\end{lstlisting}
> +
> +A blob resource is a container for:
> +
> +  \begin{itemize*}
> +  \item a guest memory allocation (referred to as a
> +  "guest-only blob resource").
> +  \item a host memory allocation (referred to as a
> +  "host-only blob resource").
> +  \item a guest memory and host memory allocation (referred
> +  to as a "default blob resource").
> +  \end{itemize*}
> +
> +The memory properties of the blob resource MUST be described by
> +\field{blob_mem}, which MUST be non-zero.
> +
> +For default and guest-only blob resources, \field{nents} guest
> +system pages are assigned to the resource.  For default blob
> +resources, these guest pages are used for transfer operations.
> +
> +Host allocations depend on whether VIRTIO_GPU_F_VIRGL is supported.
> +If VIRTIO_GPU_F_VIRGL is not supported, then:
> +
> +  \begin{itemize*}
> +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOSTSYS for host-only
> +  blob resources
> +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOSTSYS_GUEST for
> +  default blob resources
> +  \end{itemize*}
> +
> +For the above above cases, host system memory is allocated by the device.
> +
> +If VIRTIO_GPU_F_VIRGL is supported, then:
> +
> +  \begin{itemize*}
> +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOST3D for host-only
> +  blob resources
> +  \item \field{blob_mem} MUST be VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST for
> +  default resources
> +  \end{itemize*}
> +
> +For the above cases, the virtio-gpu resource MUST be created from the
> +rendering context local object identified by the \field{blob_id}. The
> +actual allocation is done via VIRTIO_GPU_CMD_SUBMIT_3D.
> +
> +VIRTIO_GPU_BLOB_MEM_GUEST is valid regardless whether VIRTIO_GPU_F_VIRGL
> +is supported or not.
> +
> +The driver MUST inform the device if the blob resource is used for
> +memory access, sharing between driver instances and/or sharing with
> +other devices. This is done via the \field{blob_flags} field.
> +
> +If VIRTIO_GPU_F_VIRGL is set, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
> +and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
> +resource. There is no restriction on the image/buffer view the driver
> +has on the blob resource.
> +
> +VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D, VIRTIO_GPU_CMD_SET_SCANOUT and
> +VIRTIO_GPU_CMD_RESOURCE_FLUSH MAY be used with blob resources as well,
> +subject to the following restrictions:
> +
> +  \begin{itemize*}
> +  \item the driver MUST have a 4-byte per pixel 2D image view of the
> +        blob resource.
> +  \item the device MUST have a 4-byte per pixel 2D image view of the
> +        blob resource, or create one if does not exist.
> +  \end{itemize*}
> +
> +For host-only blob resources, transfer operations MAY synchronize
> +caches.
> +
>  \end{description}
>  
>  \subsubsection{Device Operation: controlq (3d)}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq (3d)}
> -- 
> 2.24.1
> 
> 
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] Re: [PATCH 1/2] virtio-gpu: add resource create blob

[Gurchetan Singh]

[-- Attachment #1: Type: text/plain, Size: 4023 bytes --]

On Wed, Apr 29, 2020 at 2:28 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
>
> > > Do we need separate items (HOSTSYS/HOST3D) for these?  Shouldn't this
> be
> > > a host implementation detail the guest doesn't need to worry about?
> >
> > Yes, separate items are not needed and could indeed be an host
> > implementation detail.  Right now, the drm uapi has
> VIRTGPU_BLOB_MEM_HOST /
> > VIRTIO_GPU_BLOB_MEM_HOST_GUEST and the kernel separates to HOST{SYS,3D}
> and
> > does various checks.
> >
> >
> https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commit/0ccb47d5150a2978d179d0c44ef3285541c8964c
> >
> >
> > The reasoning is since there's no RESOURCE_CREATE_BLOB2D
> > or RESOURCE_CREATE_BLOB3D, the separation captures that difference in an
> > explicit API level.  That way, the blob id is only allowed with HOST3D.
>
> I think we can also simply define "blob id is only allowed virgl=on", no
> need for a separate command.
>

Ack.  Chia's suggestion to possibly only allow GUEST for dumb blobs is also
reasonable (i.e, no host allocations -- RESOURCE_{MAP, UNMAP}_BLOB are 3D
only).  What do you prefer?


> > A HOST3D blob has no guest memory associated with it, and can only be
> > mapped through the shm region.  Even then, a linear (mappable) view of a
> > host3d blob may not be possible/desirable -- like shareable device local
> > memory, or maybe even a protected content blob.
> >
> > HOST3D_GUEST is always mappable, while HOST3D isn't.
>
> Ok.  So _GUEST postfix means there is a guest shadow and we TRANSFER
> data instead of mapping the host resource directly.  Ok, makes sense,
> needs a better description in the spec though.
>

Will do.


> > > > +If VIRTIO_GPU_F_VIRGL is set, both
> VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
> > > > +and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
> > > > +resource. There is no restriction on the image/buffer view the
> driver
> > > > +has on the blob resource.
> > >
> > > I don't think VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D is going to work if
> > > the resource has no format attached.  I had a TRANSFER_BLOB command
> > > because of that.
> > >
> >
> > I was thinking about GL/VK interop here.
> >
> > Say VK allocates the blob resource, but a GL texture is subsequently
> > created from the blob resource using GL/VK interop extensions and a
> format
> > is attached.  For this reason, VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D is
> > allowed on blob resources.
>
> Makes sense to allow the old transfer commands for the cases where the
> resource has a format attached.
>
> > Similarly, virtgpu_kms always attaches XR24 and AB24 to resources[1], so
> > VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D can be reused if size = 4 * width for
> > dumb/sys blob resources (which I think will always be the case?).
>
> If the kernel uses BLOB resources for dumb BOs (so we can have a shared
> mapping for them and avoid copying fbdev data) they will not have a
> format attached.
>
> Imported dma-bufs (inside the guest) don't have a format attached
> either.  With BLOB resources we can support this, but we'll likewise get
> a resource without format attached.
>
> So we need ways to work with those resources ...
>

Will add TRANSFER_BLOB in v2.


> > Ack.  I definitely see the logic behind VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
> > but current display integration (dpy_gl_scanout_texture(..) in QEMU)
> > assumes the presence of a GL texture (which can be created from a blob
> > resource).
>
> I have a qemu VIRTIO_GPU_CMD_SET_SCANOUT_BLOB implementation for
> virgl=off only, covering dumb bo / fbdev as outlined above.
>

Will add VIRTIO_GPU_CMD_SET_SCANOUT_BLOB in v2.  Do you also want
SCANOUT_FLUSH too?


> With virgl=on this should be doable too, you only have to create the
> texture from the blob resource at SET_SCANOUT_BLOB time (when you know
> the format the guest wants scanout), not at resource creation time.
>
> take care,
>   Gerd
>
>

[-- Attachment #2: Type: text/html, Size: 5518 bytes --]

[virtio-comment] Re: [PATCH 1/2] virtio-gpu: add resource create blob

[Gerd Hoffmann]

  Hi,

> > > The reasoning is since there's no RESOURCE_CREATE_BLOB2D
> > > or RESOURCE_CREATE_BLOB3D, the separation captures that difference in an
> > > explicit API level.  That way, the blob id is only allowed with HOST3D.
> >
> > I think we can also simply define "blob id is only allowed virgl=on", no
> > need for a separate command.
> >
> 
> Ack.  Chia's suggestion to possibly only allow GUEST for dumb blobs is also
> reasonable (i.e, no host allocations -- RESOURCE_{MAP, UNMAP}_BLOB are 3D
> only).

Yes, that works too.

> What do you prefer?

I don't mind much.

> > > Ack.  I definitely see the logic behind VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
> > > but current display integration (dpy_gl_scanout_texture(..) in QEMU)
> > > assumes the presence of a GL texture (which can be created from a blob
> > > resource).
> >
> > I have a qemu VIRTIO_GPU_CMD_SET_SCANOUT_BLOB implementation for
> > virgl=off only, covering dumb bo / fbdev as outlined above.
> 
> Will add VIRTIO_GPU_CMD_SET_SCANOUT_BLOB in v2.  Do you also want
> SCANOUT_FLUSH too?

I think we need that, RESOURCE_FLUSH isn't going to work for resources
without an format attached.

take care,
  Gerd


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] Re: [PATCH 1/2] virtio-gpu: add resource create blob

[Gurchetan Singh]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

On Wed, May 6, 2020 at 12:14 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
>
> > > > The reasoning is since there's no RESOURCE_CREATE_BLOB2D
> > > > or RESOURCE_CREATE_BLOB3D, the separation captures that difference
> in an
> > > > explicit API level.  That way, the blob id is only allowed with
> HOST3D.
> > >
> > > I think we can also simply define "blob id is only allowed virgl=on",
> no
> > > need for a separate command.
> > >
> >
> > Ack.  Chia's suggestion to possibly only allow GUEST for dumb blobs is
> also
> > reasonable (i.e, no host allocations -- RESOURCE_{MAP, UNMAP}_BLOB are 3D
> > only).
>
> Yes, that works too.
>
> > What do you prefer?
>
> I don't mind much.
>
> > > > Ack.  I definitely see the logic behind
> VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
> > > > but current display integration (dpy_gl_scanout_texture(..) in QEMU)
> > > > assumes the presence of a GL texture (which can be created from a
> blob
> > > > resource).
> > >
> > > I have a qemu VIRTIO_GPU_CMD_SET_SCANOUT_BLOB implementation for
> > > virgl=off only, covering dumb bo / fbdev as outlined above.
> >
> > Will add VIRTIO_GPU_CMD_SET_SCANOUT_BLOB in v2.  Do you also want
> > SCANOUT_FLUSH too?
>
> I think we need that, RESOURCE_FLUSH isn't going to work for resources
> without an format attached.
>

Okay, added.  SCANOUT_BLOB is based on QemuDmaBuf, but left out the
modifier since that can be queried from virglrenderer.  LMK if anything
else is needed...


> take care,
>   Gerd
>
>

[-- Attachment #2: Type: text/html, Size: 2240 bytes --]

[virtio-comment] [PATCH 1/2] virtio-gpu: add resource create blob

[Gurchetan Singh]

Blob resources are size-based containers for host, guest, or
host+guest allocations.  These resources are designed with
mulit-process 3D support in mind, but also usable in virtio-gpu 2d
with guest memory.

Many hypercalls are reused, since a image view into the blob resource
is possible.

Blob resources are both forward and backward looking.

v2: Add TRANSFER_BLOB, SET_SCANOUT_BLOB, SCANOUT_FLUSH
v3: Remove SCANOUT_FLUSH and add notes
v4: Remove TRANSFER_BLOB for now.
v5: clarify interactions with ATTACH_BACKING / DETACH_BACKING.
    This is to preserve the possibility of guest swap-in and guest
    swap-out, while acknowledging this feature may never be implemented
    and may not be applicable for all future planned values of
    `blob_mem` or context types.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Chia-I Wu <olvaffe@gmail.com>
---
 virtio-gpu.tex | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 98 insertions(+)

diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index e70532f..1c435cb 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -36,6 +36,7 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
 \item[VIRTIO_GPU_F_VIRGL (0)] virgl 3D mode is supported.
 \item[VIRTIO_GPU_F_EDID  (1)] EDID is supported.
 \item[VIRTIO_GPU_F_RESOURCE_UUID (2)] assigning resources UUIDs for export to other virtio devices is supported.
+\item[VIRTIO_GPU_F_RESOURCE_BLOB (3)] creating and using size-based blob resources is supported.
 \end{description}
 
 \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -188,6 +189,8 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
         VIRTIO_GPU_CMD_GET_CAPSET,
         VIRTIO_GPU_CMD_GET_EDID,
         VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
+        VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
+        VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
 
         /* 3d commands (OpenGL) */
         VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -498,6 +501,101 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
 other devices are not visible in the attached backing until they are transferred
 into the backing.
 
+\item[VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB] Creates a virtio-gpu blob
+  resource. Request data is \field{struct
+  virtio_gpu_resource_create_blob}, followed by \field{struct
+  virtio_gpu_mem_entry} entries. Response type is
+  VIRTIO_GPU_RESP_OK_NODATA. Support is optional and negotiated
+  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag.
+
+\begin{lstlisting}
+#define VIRTIO_GPU_BLOB_MEM_GUEST             0x0001
+#define VIRTIO_GPU_BLOB_MEM_HOST3D            0x0002
+#define VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST      0x0003
+
+#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
+
+struct virtio_gpu_resource_create_blob {
+       struct virtio_gpu_ctrl_hdr hdr;
+       le32 resource_id;
+       le32 blob_mem;
+       le32 blob_flags;
+       le32 nr_entries;
+       le64 blob_id;
+       le64 size;
+};
+
+\end{lstlisting}
+
+A blob resource is a container for:
+
+  \begin{itemize*}
+  \item a guest memory allocation (referred to as a
+  "guest-only blob resource").
+  \item a host memory allocation (referred to as a
+  "host-only blob resource").
+  \item a guest memory and host memory allocation (referred
+  to as a "default blob resource").
+  \end{itemize*}
+
+The memory properties of the blob resource MUST be described by
+\field{blob_mem}, which MUST be non-zero.
+
+For default and guest-only blob resources, \field{nr_entries} guest
+memory entries may be assigned to the resource.  For default blob resources
+(i.e, when \field{blob_mem} is VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST), these
+memory entries are used as a shadow buffer for the host memory. To
+facilitate drivers that support swap-in and swap-out, \field{nr_entries} may
+be zero and VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING may be subsequently used.
+VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING may be used to unassign memory entries.
+
+\field{blob_mem} can only be VIRTIO_GPU_BLOB_MEM_HOST3D and
+VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST if VIRTIO_GPU_F_VIRGL is supported.
+VIRTIO_GPU_BLOB_MEM_GUEST is valid regardless whether VIRTIO_GPU_F_VIRGL
+is supported or not.
+
+For VIRTIO_GPU_BLOB_MEM_HOST3D and VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST, the
+virtio-gpu resource MUST be created from the rendering context local object
+identified by the \field{blob_id}. The actual allocation is done via
+VIRTIO_GPU_CMD_SUBMIT_3D.
+
+The driver MUST inform the device if the blob resource is used for
+memory access, sharing between driver instances and/or sharing with
+other devices. This is done via the \field{blob_flags} field.
+
+If VIRTIO_GPU_F_VIRGL is set, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
+and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
+resource. There is no restriction on the image/buffer view the driver
+has on the blob resource.
+
+\item[VIRTIO_GPU_CMD_SET_SCANOUT_BLOB] sets scanout parameters for a
+   blob resource. Request data is
+  \field{struct virtio_gpu_set_scanout_blob}. Response type is
+  VIRTIO_GPU_RESP_OK_NODATA. Support is optional and negotiated
+  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag.
+
+\begin{lstlisting}
+struct virtio_gpu_set_scanout_blob {
+       struct virtio_gpu_ctrl_hdr hdr;
+       struct virtio_gpu_rect r;
+       le32 scanout_id;
+       le32 resource_id;
+       le32 width;
+       le32 height;
+       le32 format;
+       le32 padding;
+       le32 strides[4];
+       le32 offsets[4];
+};
+\end{lstlisting}
+
+The rectangle \field{r} represents the portion of the blob resource being
+displayed. The rest is the metadata associated with the blob resource. The
+format MUST be one of \field{enum virtio_gpu_formats}.  The format MAY be
+compressed with header and data planes.
+
 \end{description}
 
 \subsubsection{Device Operation: controlq (3d)}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq (3d)}
-- 
2.24.1


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

[virtio-comment] [PATCH 1/2] virtio-gpu: add resource create blob

[Gurchetan Singh]

Blob resources are size-based containers for host, guest, or
host+guest allocations.  These resources are designed with
mulit-process 3D support in mind, but also usable in virtio-gpu 2d
with guest memory.

Many hypercalls are reused, since a image view into the blob resource
is possible.

Blob resources are both forward and backward looking.

v2: Add TRANSFER_BLOB, SET_SCANOUT_BLOB, SCANOUT_FLUSH
v3: Remove SCANOUT_FLUSH and add notes
v4: Remove TRANSFER_BLOB for now.
v5: clarify interactions with ATTACH_BACKING / DETACH_BACKING.
    This is to preserve the possibility of guest swap-in and guest
    swap-out, while acknowledging this feature may never be implemented
    and may not be applicable for all future planned values of
    `blob_mem` or context types.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Chia-I Wu <olvaffe@gmail.com>
---
 virtio-gpu.tex | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)

diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index f98ddba..55bd6d2 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -37,6 +37,8 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
 \item[VIRTIO_GPU_F_EDID  (1)] EDID is supported.
 \item[VIRTIO_GPU_F_RESOURCE_UUID (2)] assigning resources UUIDs for export
   to other virtio devices is supported.
+\item[VIRTIO_GPU_F_RESOURCE_BLOB (3)] creating and using size-based blob
+  resources is supported.
 \end{description}
 
 \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -189,6 +191,8 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
         VIRTIO_GPU_CMD_GET_CAPSET,
         VIRTIO_GPU_CMD_GET_EDID,
         VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
+        VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
+        VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
 
         /* 3d commands (OpenGL) */
         VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -499,6 +503,101 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
 other devices are not visible in the attached backing until they are transferred
 into the backing.
 
+\item[VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB] Creates a virtio-gpu blob
+  resource. Request data is \field{struct
+  virtio_gpu_resource_create_blob}, followed by \field{struct
+  virtio_gpu_mem_entry} entries. Response type is
+  VIRTIO_GPU_RESP_OK_NODATA. Support is optional and negotiated
+  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag.
+
+\begin{lstlisting}
+#define VIRTIO_GPU_BLOB_MEM_GUEST             0x0001
+#define VIRTIO_GPU_BLOB_MEM_HOST3D            0x0002
+#define VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST      0x0003
+
+#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
+
+struct virtio_gpu_resource_create_blob {
+       struct virtio_gpu_ctrl_hdr hdr;
+       le32 resource_id;
+       le32 blob_mem;
+       le32 blob_flags;
+       le32 nr_entries;
+       le64 blob_id;
+       le64 size;
+};
+
+\end{lstlisting}
+
+A blob resource is a container for:
+
+  \begin{itemize*}
+  \item a guest memory allocation (referred to as a
+  "guest-only blob resource").
+  \item a host memory allocation (referred to as a
+  "host-only blob resource").
+  \item a guest memory and host memory allocation (referred
+  to as a "default blob resource").
+  \end{itemize*}
+
+The memory properties of the blob resource MUST be described by
+\field{blob_mem}, which MUST be non-zero.
+
+For default and guest-only blob resources, \field{nr_entries} guest
+memory entries may be assigned to the resource.  For default blob resources
+(i.e, when \field{blob_mem} is VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST), these
+memory entries are used as a shadow buffer for the host memory. To
+facilitate drivers that support swap-in and swap-out, \field{nr_entries} may
+be zero and VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING may be subsequently used.
+VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING may be used to unassign memory entries.
+
+\field{blob_mem} can only be VIRTIO_GPU_BLOB_MEM_HOST3D and
+VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST if VIRTIO_GPU_F_VIRGL is supported.
+VIRTIO_GPU_BLOB_MEM_GUEST is valid regardless whether VIRTIO_GPU_F_VIRGL
+is supported or not.
+
+For VIRTIO_GPU_BLOB_MEM_HOST3D and VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST, the
+virtio-gpu resource MUST be created from the rendering context local object
+identified by the \field{blob_id}. The actual allocation is done via
+VIRTIO_GPU_CMD_SUBMIT_3D.
+
+The driver MUST inform the device if the blob resource is used for
+memory access, sharing between driver instances and/or sharing with
+other devices. This is done via the \field{blob_flags} field.
+
+If VIRTIO_GPU_F_VIRGL is set, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
+and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
+resource. There is no restriction on the image/buffer view the driver
+has on the blob resource.
+
+\item[VIRTIO_GPU_CMD_SET_SCANOUT_BLOB] sets scanout parameters for a
+   blob resource. Request data is
+  \field{struct virtio_gpu_set_scanout_blob}. Response type is
+  VIRTIO_GPU_RESP_OK_NODATA. Support is optional and negotiated
+  using the VIRTIO_GPU_F_RESOURCE_BLOB feature flag.
+
+\begin{lstlisting}
+struct virtio_gpu_set_scanout_blob {
+       struct virtio_gpu_ctrl_hdr hdr;
+       struct virtio_gpu_rect r;
+       le32 scanout_id;
+       le32 resource_id;
+       le32 width;
+       le32 height;
+       le32 format;
+       le32 padding;
+       le32 strides[4];
+       le32 offsets[4];
+};
+\end{lstlisting}
+
+The rectangle \field{r} represents the portion of the blob resource being
+displayed. The rest is the metadata associated with the blob resource. The
+format MUST be one of \field{enum virtio_gpu_formats}.  The format MAY be
+compressed with header and data planes.
+
 \end{description}
 
 \subsubsection{Device Operation: controlq (3d)}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq (3d)}
-- 
2.26.2


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/