Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio gpu device specification.

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

On Wed, May 04, 2016 at 03:05:34PM +0200, Gerd Hoffmann wrote:
> Resuming the effort to get the gpu device specs merged.
> 
> Support for 2d mode (3d/virgl mode is not covered by this patch) has
> been added to the linux kernel version 4.2 and to qemu version 2.4.
> 
> git branch:
>   https://www.kraxel.org/cgit/virtio-spec/commit/?h=virtio-gpu
> 
> Rendered versions are available here:
>   https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-gpu.pdf
>   https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-gpu.html#x1-2800007
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  content.tex    |   2 +
>  virtio-gpu.tex | 467 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 469 insertions(+)
>  create mode 100644 virtio-gpu.tex

Please add a command execution model section that explains the command
lifecycle and interactions between commands.  From reading through the
spec once I've gathered the fence flag can be used to force execution.
I guess a non-fenced command only completes when the operation has
finished, too (so that a meaningful success/error value can be
produced)?

Are there any interactions between the two queues?  I guess the
resource_id namespace includes both queues.  The 64x64 cursor would be
initialized on the controlq.  The actual VIRTIO_GPU_CMD_UPDATE_CURSOR
and VIRTIO_GPU_CMD_MOVE_CURSOR can be sent via either queue.  The
cursorq does not accept any commands other than
VIRTIO_GPU_CMD_UPDATE_CURSOR and VIRTIO_GPU_CMD_MOVE_CURSOR?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]