All of lore.kernel.org
 help / color / mirror / Atom feed
* [virtio-comment] [RFC PATCH v3 1/2] virtio-gpu: add resource create blob
@ 2020-05-13 23:13 Gurchetan Singh
  2020-05-13 23:13 ` [virtio-comment] [RFC PATCH v3 2/2] virtio-gpu: add support for mapping/unmapping blob resources Gurchetan Singh
  2020-05-15 10:42 ` [virtio-comment] Re: [RFC PATCH v3 1/2] virtio-gpu: add resource create blob Gerd Hoffmann
  0 siblings, 2 replies; 4+ messages in thread
From: Gurchetan Singh @ 2020-05-13 23:13 UTC (permalink / raw)
  To: virtio-comment; +Cc: kraxel, olvaffe, marcheu, 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

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
---
 virtio-gpu.tex | 125 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 125 insertions(+)

diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index e70532f..179e57c 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,9 @@ \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_TRANSFER_BLOB,
+        VIRTIO_GPU_CMD_SET_SCANOUT_BLOB,
 
         /* 3d commands (OpenGL) */
         VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -498,6 +502,127 @@ \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{nents} guest
+system pages are assigned to the resource.  For default blob resources
+(i.e, when \field{blob_mem} is VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST), these
+guest pages are used as a shadow buffer for the host memory.
+
+\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.  VIRTIO_GPU_CMD_TRANSFER_BLOB (described below)
+may also be used.
+
+\item[VIRTIO_GPU_CMD_TRANSFER_BLOB] synchronizes a blob resource. Request
+  data is \field{struct virtio_gpu_resource_transfer_blob}, followed by
+  \field{struct virtio_gpu_blob_range} 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_TRANSFER_BLOB_TO_HOST   0x0001
+#define VIRTIO_GPU_TRANSFER_BLOB_FROM_HOST 0x0002
+
+struct virtio_gpu_blob_range {
+       le64 offset;
+       le64 size;
+};
+
+struct virtio_gpu_resource_transfer_blob {
+       struct virtio_gpu_ctrl_hdr hdr;
+       le32 resource_id;
+       le32 flags;
+       le32 nr_ranges;
+       le32 pad;
+};
+\end{lstlisting}
+
+The default blob resources, transfer operations transfer operations
+copy the contents of the guest pages to or from the host.
+For host-only blob resources, transfer operations MAY synchronize caches.
+
+\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/


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [virtio-comment] [RFC PATCH v3 2/2] virtio-gpu: add support for mapping/unmapping blob resources
  2020-05-13 23:13 [virtio-comment] [RFC PATCH v3 1/2] virtio-gpu: add resource create blob Gurchetan Singh
@ 2020-05-13 23:13 ` Gurchetan Singh
  2020-05-15 10:42 ` [virtio-comment] Re: [RFC PATCH v3 1/2] virtio-gpu: add resource create blob Gerd Hoffmann
  1 sibling, 0 replies; 4+ messages in thread
From: Gurchetan Singh @ 2020-05-13 23:13 UTC (permalink / raw)
  To: virtio-comment; +Cc: kraxel, olvaffe, marcheu, Gurchetan Singh

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 5706 bytes --]

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.

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 179e57c..ef03b95 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
@@ -202,6 +220,8 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
         VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D,
         VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D,
         VIRTIO_GPU_CMD_SUBMIT_3D,
+        VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB,
+        VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB,
 
         /* cursor commands */
         VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
@@ -214,6 +234,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,
@@ -648,6 +669,48 @@ \subsubsection{Device Operation: controlq (3d)}\label{sec:Device Types / GPU Dev
 \item[VIRTIO_GPU_CMD_SUBMIT_3D]
   Submit rendering commands (mesa gallium command stream).
 
+\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}
+struct virtio_gpu_resource_map_blob {
+        struct virtio_gpu_ctrl_hdr hdr;
+        le32 resource_id;
+        le32 padding;
+        le64 offset;
+};
+
+#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.
+
+\begin{lstlisting}
+struct virtio_gpu_resource_unmap_blob {
+        struct virtio_gpu_ctrl_hdr hdr;
+        le32 resource_id;
+        le32 padding;
+};
+\end{lstlisting}
+
 \end{description}
 
 \subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: cursorq}
-- 
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/


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [virtio-comment] Re: [RFC PATCH v3 1/2] virtio-gpu: add resource create blob
  2020-05-13 23:13 [virtio-comment] [RFC PATCH v3 1/2] virtio-gpu: add resource create blob Gurchetan Singh
  2020-05-13 23:13 ` [virtio-comment] [RFC PATCH v3 2/2] virtio-gpu: add support for mapping/unmapping blob resources Gurchetan Singh
@ 2020-05-15 10:42 ` Gerd Hoffmann
  2020-05-15 22:12   ` Gurchetan Singh
  1 sibling, 1 reply; 4+ messages in thread
From: Gerd Hoffmann @ 2020-05-15 10:42 UTC (permalink / raw)
  To: Gurchetan Singh; +Cc: virtio-comment, olvaffe, marcheu

  Hi,

> +\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.

Would it be useful to explicitly announce which VIRTIO_GPU_BLOB_MEM*
variants are supported instead of having implicit rules?  Using a
config space field for example?

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/


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [virtio-comment] Re: [RFC PATCH v3 1/2] virtio-gpu: add resource create blob
  2020-05-15 10:42 ` [virtio-comment] Re: [RFC PATCH v3 1/2] virtio-gpu: add resource create blob Gerd Hoffmann
@ 2020-05-15 22:12   ` Gurchetan Singh
  0 siblings, 0 replies; 4+ messages in thread
From: Gurchetan Singh @ 2020-05-15 22:12 UTC (permalink / raw)
  To: Gerd Hoffmann; +Cc: virtio-comment, Chia-I Wu, Stéphane Marchesin

On Fri, May 15, 2020 at 3:42 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > +\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.
>
> Would it be useful to explicitly announce which VIRTIO_GPU_BLOB_MEM*
> variants are supported instead of having implicit rules?  Using a
> config space field for example?

In 2D mode, I don't think anybody is going to advertise support
VIRTIO_GPU_BLOB_MEM_HOST3D / VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST.  I'm
thinking we can just have various checks in the kernel and write in
the spec, like the current model.

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/virtio/virtgpu_ioctl.c#L238

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-05-15 22:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-13 23:13 [virtio-comment] [RFC PATCH v3 1/2] virtio-gpu: add resource create blob Gurchetan Singh
2020-05-13 23:13 ` [virtio-comment] [RFC PATCH v3 2/2] virtio-gpu: add support for mapping/unmapping blob resources Gurchetan Singh
2020-05-15 10:42 ` [virtio-comment] Re: [RFC PATCH v3 1/2] virtio-gpu: add resource create blob Gerd Hoffmann
2020-05-15 22:12   ` Gurchetan Singh

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.