[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [PATCH 2/2] Add GPU device type.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> --- content.tex | 1 + virtio-gpu.tex | 276 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 277 insertions(+) create mode 100644 virtio-gpu.tex diff --git a/content.tex b/content.tex index 196950d..f7e3e83 100644 --- a/content.tex +++ b/content.tex @@ -4887,6 +4887,7 @@ descriptor for the \field{sense_len}, \field{residual}, \field{status_qualifier}, \field{status}, \field{response} and \field{sense} fields. +\input{virtio-gpu.tex} \input{virtio-input.tex} \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits} diff --git a/virtio-gpu.tex b/virtio-gpu.tex new file mode 100644 index 0000000..c9b4d62 --- /dev/null +++ b/virtio-gpu.tex @@ -0,0 +1,276 @@ +\section{GPU Device}\label{sec:Device Types / GPU Device} + +virtio-gpu is a virtio based graphics adapter. Supported features: + +\begin{enumerate} +\item ARGB Hardware cursors +\item multiple outputs +\end{enumerate} + +\subsection{Device ID}\label{sec:Device Types / GPU Device / Device ID} + +16 + +\subsection{Virtqueues}\label{sec:Device Types / GPU Device / Virtqueues} + +\begin{description} +\item[0] controlq +\item[1] cursorq +\item[2] eventq +\end{description} + +\subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits} + +None yet. Upcoming 3D support will add one or more. + +\subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout} + +None. + +\subsection{Device Initialization}\label{sec:Device Types / GPU Device / Device Initialization} + +TODO. + +\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 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 +backing store to the resources in order for DMA transfers to +work. This is like a GART in a real GPU. + +A typical guest user would create a 2D resource using +VIRTGPU_CMD_RESOURCE_CREATE_2D, attach backing store using +VIRTGPU_CMD_RESOURCE_ATTACH_BACKING, then attach the resource to a +scanout using VIRTGPU_CMD_SET_SCANOUT, then use +VIRTGPU_CMD_TRANSFER_SEND_2D to send updates to the resource, and +finally VIRTGPU_CMD_RESOURCE_FLUSH to flush the scanout buffers to +screen. + +\subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: controlq} + +\begin{lstlisting} +struct virtgpu_command { + le32 type; + le32 flags; + le64 fence_id; + union virtgpu_cmds { + struct virtgpu_cmd_get_cap get_cap; + struct virtgpu_resource_create_2d resource_create_2d; + struct virtgpu_resource_unref resource_unref; + struct virtgpu_resource_flush resource_flush; + struct virtgpu_set_scanout set_scanout; + struct virtgpu_transfer_to_host_2d transfer_to_host_2d; + struct virtgpu_resource_attach_backing resource_attach_backing; + struct virtgpu_resource_inval_backing resource_inval_backing; + } u; +}; + +struct virtgpu_response { + le32 type; + le32 flags; + union virtgpu_resps { + struct virtgpu_display_info display_info; + union virtgpu_caps caps; + } u; +}; +\end{lstlisting} + +\begin{description} + +\item[VIRTGPU_CMD_GET_DISPLAY_INFO] +Retrieve the current output configuration. + +\begin{lstlisting} +#define VIRTGPU_MAX_SCANOUTS 16 +struct virtgpu_display_info { + le32 num_scanouts; + struct { + le32 enabled; + le32 width; + le32 height; + le32 x; + le32 y; + le32 flags; + } pmodes[VIRTGPU_MAX_SCANOUTS]; +}; +\end{lstlisting} + +This sends a response in the same queue slot. The response contains +the max number of scanouts the host can support, along with a list of +per-scanout information. The info contains whether the scanout is +enabled, what its preferred x, y, width and height are and some future +flags. + +\item[VIRTGPU_CMD_GET_CAPS] +FIXME: seems there are changes (new struct virtgpu_cmd_get_cap)here +for 3D ... + +\item[VIRTGPU_CMD_RESOURCE_CREATE_2D] +Create a 2D resource on the host. + +\begin{lstlisting} +struct virtgpu_resource_create_2d { + le32 resource_id; + le32 format; + le32 width; + le32 height; +}; +\end{lstlisting} + +This creates a 2D resource on the host with the specified width, +height and format. Only a small subset of formats are support. The +resource ids are generated by the guest. + +\item[VIRTGPU_CMD_RESOURCE_UNREF] +Destroy a resource. + +\begin{lstlisting} +struct virtgpu_resource_unref { + le32 resource_id; +}; +\end{lstlisting} + +This informs the host that a resource is no longer required by the +guest. + +\item[VIRTGPU_CMD_SET_SCANOUT] +Set the scanout parameters for a single output. + +\begin{lstlisting} +struct virtgpu_set_scanout { + le32 scanout_id; + le32 resource_id; + le32 width; + le32 height; + le32 x; + le32 y; +}; +\end{lstlisting} + +This sets the scanout parameters for a single scanout. The resource_id +is the resource to be scanned out from, along with a rectangle +specified by x, y, width and height. + +\item[VIRTGPU_CMD_RESOURCE_FLUSH] +Flush a scanout resource + +\begin{lstlisting} +struct virtgpu_resource_flush { + le32 resource_id; + le32 width; + le32 height; + le32 x; + le32 y; +}; +\end{lstlisting} + +This flushes a resource to screen, it takes a rectangle and a resource +id, and flushes any scanouts the resource is being used on. + +\item[VIRTGPU_CMD_TRANSFER_TO_HOST_2D] +Transfer from guest memory to host resource. + +\begin{lstlisting} +struct virtgpu_transfer_to_host_2d { + le32 resource_id; + le32 offset; + le32 width; + le32 height; + le32 x; + le32 y; +}; +\end{lstlisting} + +This takes a resource id along with an destination offset into the +resource, and a box to transfer from the host backing for the +resource. + +\item[VIRTGPU_CMD_RESOURCE_ATTACH_BACKING] +Assign backing pages to a resource. + +\begin{lstlisting} +struct virtgpu_resource_attach_backing { + le32 resource_id; + le32 nr_entries; +}; +\end{lstlisting} + +This assign an array of guest pages as the backing store for a +resource. These pages are then used for the transfer operations for +that resource from that point on. + +\item[VIRTGPU_CMD_RESOURCE_INVAL_BACKING] +Detach backing pages from a resource. + +\begin{lstlisting} +struct virtgpu_resource_inval_backing { + le32 resource_id; +}; +\end{lstlisting} + +This detaches any backing pages from a resource, to be used in case of +guest swapping or object destruction. + +\end{description} + +\subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: cursorq} + +\begin{lstlisting} +struct virtgpu_hw_cursor_page { + le32 cursor_x, cursor_y; + le32 cursor_hot_x, cursor_hot_y; + le32 cursor_id; + le32 generation_count; +}; +\end{lstlisting} + +The cursor queue accepts on structure per vq entry. The cursor is just +a standard 2D resource that is 64x64 sized. Transfers are used to +upload the cursor contents. + +For cursor movement, only \field{cursor_x} and \field{cursor_y} need to be +updated. + +For a cursor update where the guest has transferred a new cursor into +the resource, \field{cursor_hot_x}, \field{cursor_hot_y} and +\field{cursor_id} should be updated and \field{generation_count} +should be increased by one, so the host knows to refresh its copy of +the cursor data from the resource. + +\subsubsection{Device Operation: eventq}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: eventq} + +\begin{lstlisting} +struct virtgpu_event { + le32 type; + le32 err_code; + union virtgpu_events { + struct virtgpu_display_info display_info; + } u; +}; +\end{lstlisting} + +\begin{description} + +\item[VIRTGPU_EVENT_ERROR] +3D only ? + +\item[VIRTGPU_EVENT_DISPLAY_CHANGE] +Contains the same info as the response to VIRTGPU_CMD_GET_DISPLAY_INFO. + +\subsection{VGA Compatibility}\label{sec:Device Types / GPU Device / VGA Compatibility} + +Applies to Virtio Over PCI only. The GPU device can come with and +without VGA compatibility. The PCI class should be DISPLAY_VGA if VGA +compatibility is present and DISPLAY_OTHER otherwise. + +VGA compatibility: PCI region 2 has a linear framebuffer, standard vga +and bochs dispi interface registers are present. Enabling virtio +switches the device from vga compat into native virtio mode. + +\end{description} -- 1.8.3.1
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]