All of lore.kernel.org
 help / color / mirror / Atom feed
* [virtio-comment] [RFC PATCH v4 1/2] virtio-gpu: add resource create blob
@ 2020-05-18 18:46 Gurchetan Singh
  2020-05-18 18:46 ` [virtio-comment] [RFC PATCH v4 2/2] virtio-gpu: add support for mapping/unmapping blob resources Gurchetan Singh
  2020-05-28  8:34 ` [virtio-comment] Re: [RFC PATCH v4 1/2] virtio-gpu: add resource create blob Gerd Hoffmann
  0 siblings, 2 replies; 4+ messages in thread
From: Gurchetan Singh @ 2020-05-18 18:46 UTC (permalink / raw)
  To: virtio-comment; +Cc: kraxel, olvaffe, marcheu

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.

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

diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index e70532f..97f7865 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,98 @@ \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.
+
+\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.761.g0e0b3e54be-goog


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 v4 2/2] virtio-gpu: add support for mapping/unmapping blob resources
  2020-05-18 18:46 [virtio-comment] [RFC PATCH v4 1/2] virtio-gpu: add resource create blob Gurchetan Singh
@ 2020-05-18 18:46 ` Gurchetan Singh
  2020-05-28  8:34 ` [virtio-comment] Re: [RFC PATCH v4 1/2] virtio-gpu: add resource create blob Gerd Hoffmann
  1 sibling, 0 replies; 4+ messages in thread
From: Gurchetan Singh @ 2020-05-18 18:46 UTC (permalink / raw)
  To: virtio-comment; +Cc: kraxel, olvaffe, marcheu

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 5727 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 97f7865..8f0c63c 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
@@ -201,6 +219,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,
@@ -213,6 +233,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,
@@ -618,6 +639,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.26.2.761.g0e0b3e54be-goog


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 v4 1/2] virtio-gpu: add resource create blob
  2020-05-18 18:46 [virtio-comment] [RFC PATCH v4 1/2] virtio-gpu: add resource create blob Gurchetan Singh
  2020-05-18 18:46 ` [virtio-comment] [RFC PATCH v4 2/2] virtio-gpu: add support for mapping/unmapping blob resources Gurchetan Singh
@ 2020-05-28  8:34 ` Gerd Hoffmann
  2020-06-05 21:42   ` Gurchetan Singh
  1 sibling, 1 reply; 4+ messages in thread
From: Gerd Hoffmann @ 2020-05-28  8:34 UTC (permalink / raw)
  To: Gurchetan Singh; +Cc: virtio-comment, olvaffe, marcheu

On Mon, May 18, 2020 at 11:46:28AM -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 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.
> 
> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>

Both patches look good to me.

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

See .github/PULL_REQUEST_TEMPLATE.md (in the virtio-spec repo) for the
merge process.

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/


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

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

On Thu, May 28, 2020 at 1:34 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Mon, May 18, 2020 at 11:46:28AM -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 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.
> >
> > Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
>
> Both patches look good to me.
>
> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
>
> See .github/PULL_REQUEST_TEMPLATE.md (in the virtio-spec repo) for the
> merge process.

Thanks, will do after UUID patches land in virtio-spec / drm-misc-next!

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


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

end of thread, other threads:[~2020-06-05 21:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-18 18:46 [virtio-comment] [RFC PATCH v4 1/2] virtio-gpu: add resource create blob Gurchetan Singh
2020-05-18 18:46 ` [virtio-comment] [RFC PATCH v4 2/2] virtio-gpu: add support for mapping/unmapping blob resources Gurchetan Singh
2020-05-28  8:34 ` [virtio-comment] Re: [RFC PATCH v4 1/2] virtio-gpu: add resource create blob Gerd Hoffmann
2020-06-05 21:42   ` 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.