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

[Gerd Hoffmann <kraxel@redhat.com>]

On Mo, 2016-05-09 at 15:43 +0100, Stefan Hajnoczi wrote:
> 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.

No, it can be used for completion notification.

> I guess a non-fenced command only completes when the operation has
> finished, too (so that a meaningful success/error value can be
> produced)?

When stuff is processed asynchronously the command can complete before
the operation actually completed.  Current qemu implementation does that
only in 3d mode, when offloading stuff to the hardware (and verifies
stuff beforehand, so if you try to kick 3d rendering with an invalid
context id qemu will throw an error).

I'll try to make that more clear in the text.

> Are there any interactions between the two queues?

None, except the one already described in the cursor section (must
create cursors as 64x64 resources using controlq before using them via
cursorq).

> I guess the
> resource_id namespace includes both queues.

Yes.

> The 64x64 cursor would be
> initialized on the controlq.

Yes.

> The actual VIRTIO_GPU_CMD_UPDATE_CURSOR
> and VIRTIO_GPU_CMD_MOVE_CURSOR can be sent via either queue.

No, cursor queue only.  They are described in the "Device Operation:
cursorq" section because of that.

> The
> cursorq does not accept any commands other than
> VIRTIO_GPU_CMD_UPDATE_CURSOR and VIRTIO_GPU_CMD_MOVE_CURSOR?

Yes.

cheers,
  Gerd