From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: virtio-comment@lists.oasis-open.org, kraxel@redhat.com,
olvaffe@gmail.com, marcheu@chromium.org
Subject: Re: [virtio-comment] [PATCH 1/2] virtio-gpu: add resource create blob
Date: Mon, 4 May 2020 10:38:21 -0400 [thread overview]
Message-ID: <20200504103806-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200422005531.15085-2-gurchetansingh@chromium.org>
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/
next prev parent reply other threads:[~2020-05-04 14:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 0:55 [virtio-comment] [RFC PATCH 0/2] Blob resources + host visible memory Gurchetan Singh
2020-04-22 0:55 ` [virtio-comment] [PATCH 1/2] virtio-gpu: add resource create blob Gurchetan Singh
2020-04-28 10:29 ` [virtio-comment] " Gerd Hoffmann
2020-04-29 0:44 ` Gurchetan Singh
2020-04-29 9:28 ` Gerd Hoffmann
2020-04-30 0:56 ` Chia-I Wu
2020-05-05 23:26 ` Gurchetan Singh
2020-05-06 7:14 ` Gerd Hoffmann
2020-05-07 23:35 ` Gurchetan Singh
2020-05-04 14:38 ` Michael S. Tsirkin [this message]
2020-04-22 0:55 ` [virtio-comment] [PATCH 2/2] virtio-gpu: add support for mapping/unmapping blob resources Gurchetan Singh
2020-04-28 10:33 ` [virtio-comment] " Gerd Hoffmann
-- strict thread matches above, loose matches on Subject: below --
2020-08-14 1:54 [virtio-comment] [PATCH 0/2] Blob resources v5 Gurchetan Singh
2020-08-14 1:54 ` [virtio-comment] [PATCH 1/2] virtio-gpu: add resource create blob Gurchetan Singh
2020-09-02 20:58 [virtio-comment] [PATCH 0/2] Blob resources v6 Gurchetan Singh
2020-09-02 20:58 ` [virtio-comment] [PATCH 1/2] virtio-gpu: add resource create blob Gurchetan Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200504103806-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=gurchetansingh@chromium.org \
--cc=kraxel@redhat.com \
--cc=marcheu@chromium.org \
--cc=olvaffe@gmail.com \
--cc=virtio-comment@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox