summaryrefslogtreecommitdiff
path: root/virtio-gpu.tex
diff options
context:
space:
mode:
Diffstat (limited to 'virtio-gpu.tex')
-rw-r--r--virtio-gpu.tex48
1 files changed, 48 insertions, 0 deletions
diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index 34cf493..22546cc 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -34,6 +34,7 @@ control queue.
\begin{description}
\item[VIRTIO_GPU_F_VIRGL (0)] virgl 3D mode is supported.
+\item[VIRTIO_GPU_F_HOST_ALLOC (1)] buffer allocation by the host is supported.
\end{description}
\subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -90,6 +91,11 @@ height and format along with an identifier. The guest must then attach
backing store to the resources in order for DMA transfers to
work. This is like a GART in a real GPU.
+Additionally, when the VIRTIO_GPU_F_HOST_ALLOC feature is present, the guest
+can request the host to allocate backing store for resources on its behalf, in
+which case the allocated resources can be accessed by both the host and the
+guest without any need for DMA transfers.
+
\subsubsection{Device Operation: Create a framebuffer and configure scanout}
\begin{itemize*}
@@ -120,6 +126,18 @@ using VIRTIO_GPU_CMD_SET_SCANOUT and VIRTIO_GPU_CMD_RESOURCE_FLUSH,
and update the invisible framebuffer using
VIRTIO_GPU_CMD_TRANSFER_SEND_2D.
+\subsubsection{Device Operation: Create a framebuffer from host-allocated memory}
+
+\begin{itemize*}
+\item Create a host resource using VIRTIO_GPU_CMD_RESOURCE_CREATE_2D. This
+ step is identical to the guest-allocated backing store case.
+\item Request the host to allocate the backing storage for the resource just
+ created, using VIRTIO_GPU_CMD_RESOURCE_ALLOC_BACKING. The host will map the
+ memory to the guest and will return the memory address.
+\item Use VIRTIO_GPU_CMD_SET_SCANOUT, VIRTIO_GPU_CMD_TRANSFER_SEND_2D and
+ VIRTIO_GPU_CMD_RESOURCE_FLUSH as for guest-allocated memory.
+\end{itemize*}
+
\subsubsection{Device Operation: Multihead setup}
In case two or more displays are present there are different ways to
@@ -171,6 +189,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D,
VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING,
VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING,
+ VIRTIO_GPU_CMD_RESOURCE_ALLOC_BACKING,
/* cursor commands */
VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
@@ -179,6 +198,7 @@ enum virtio_gpu_ctrl_type {
/* success responses */
VIRTIO_GPU_RESP_OK_NODATA = 0x1100,
VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
+ VIRTIO_GPU_RESP_OK_ALLOC_BACKING,
/* error responses */
VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
@@ -417,6 +437,34 @@ struct virtio_gpu_resource_detach_backing {
This detaches any backing pages from a resource, to be used in case of
guest swapping or object destruction.
+\item[VIRTIO_GPU_CMD_RESOURCE_ALLOC_BACKING] Request the host to allocate
+ backing pages for a resource. Request data is \field{struct
+ virtio_gpu_resource_alloc_backing}. Response type is
+ VIRTIO_GPU_RESP_OK_ALLOC_BACKING, response data is \field{struct
+ virtio_gpu_resp_resource_alloc_backing}.
+
+\begin{lstlisting}
+struct virtio_gpu_resource_alloc_backing {
+ struct virtio_gpu_ctrl_hdr hdr;
+ le32 resource_id;
+ le32 padding;
+};
+
+struct virtio_gpu_resp_resource_alloc_backing {
+ struct virtio_gpu_ctrl_hdr hdr;
+ le64 addr;
+};
+\end{lstlisting}
+
+This allocates backing store memory for a resource on the host, and maps the
+memory physically contiguous to the guest. The host returns the guest memory
+address in the \field{addr} field. If memory can't be allocated, the response
+is VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY with no data.
+
+When the backing store is detached from the resource with
+VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING, the memory is freed and unmapped from
+the guest.
+
\end{description}
\subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: cursorq}