qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [virtio-dev] [PATCH] Add virtio gpu device specification.
Date: Mon, 9 May 2016 15:43:16 +0100
User-agent: Mutt/1.6.0 (2016-04-01)

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 <address@hidden>
> ---
>  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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]