search for: virtgpu_ctrl_hdr

...RSOR = 0x0300, + VIRTGPU_CMD_MOVE_CURSOR, + + /* success responses */ + VIRTGPU_RESP_OK_NODATA = 0x1100, + VIRTGPU_RESP_OK_DISPLAY_INFO, + + /* error responses */ + VIRTGPU_RESP_ERR_UNSPEC = 0x1200, +}; + +#define VIRTGPU_FLAG_FENCE (1 << 0) + +struct virtgpu_ctrl_hdr { + uint32_t type; + uint32_t flags; + uint64_t fence_id; + uint32_t ctx_id; + uint32_t padding; +}; + +/* data passed in the cursor vq */ + +struct virtgpu_cursor_pos { + uint32_t scanout_id; + uint32_t x, y; +}; + +/* VIRTGPU_CMD_UPDATE_CURSOR, VIR...

...gt; for later extensions if every member of the enum is also associated with >> a preprocessor macro. > > I don't think this will ever be shipped as library header for external > users ... Fair enough. I wasn't sure, so it didn't hurt to ask. > >>> +struct virtgpu_ctrl_hdr { >>> + uint32_t type; >>> + uint32_t flags; >>> + uint64_t fence_id; >>> + uint32_t ctx_id; >>> + uint32_t padding; >>> +}; >>> + >> >> Is the padding to ensure that this is aligned regard...

...gt; for later extensions if every member of the enum is also associated with >> a preprocessor macro. > > I don't think this will ever be shipped as library header for external > users ... Fair enough. I wasn't sure, so it didn't hurt to ask. > >>> +struct virtgpu_ctrl_hdr { >>> + uint32_t type; >>> + uint32_t flags; >>> + uint64_t fence_id; >>> + uint32_t ctx_id; >>> + uint32_t padding; >>> +}; >>> + >> >> Is the padding to ensure that this is aligned regard...

Hi folks, Lets kick off the virtio-gpu review process, starting with the virtio protocol. This is a tiny patch series for qemu. Patch #1 carries the header file describing the virtual hardware: config space, command structs being sent over the rings, defines etc. Patch #2 adds a text file describing virtio-gpu to docs/specs/. It covers 2D support only for now. For anybody who wants to dig a

Hi folks, Lets kick off the virtio-gpu review process, starting with the virtio protocol. This is a tiny patch series for qemu. Patch #1 carries the header file describing the virtual hardware: config space, command structs being sent over the rings, defines etc. Patch #2 adds a text file describing virtio-gpu to docs/specs/. It covers 2D support only for now. For anybody who wants to dig a

...NFO = 0x0100, Please consider also adding: #define VIRTGPU_CMD_GET_DISPLAY_INFO VIRTGPU_CMD_GET_DISPLAY_INFO and friends. It makes it MUCH nicer for application software to probe for later extensions if every member of the enum is also associated with a preprocessor macro. > + > +struct virtgpu_ctrl_hdr { > + uint32_t type; > + uint32_t flags; > + uint64_t fence_id; > + uint32_t ctx_id; > + uint32_t padding; > +}; > + Is the padding to ensure that this is aligned regardless of 32-bit or 64-bit hosts? Is it worth adding a compile-time assert...

...NFO = 0x0100, Please consider also adding: #define VIRTGPU_CMD_GET_DISPLAY_INFO VIRTGPU_CMD_GET_DISPLAY_INFO and friends. It makes it MUCH nicer for application software to probe for later extensions if every member of the enum is also associated with a preprocessor macro. > + > +struct virtgpu_ctrl_hdr { > + uint32_t type; > + uint32_t flags; > + uint64_t fence_id; > + uint32_t ctx_id; > + uint32_t padding; > +}; > + Is the padding to ensure that this is aligned regardless of 32-bit or 64-bit hosts? Is it worth adding a compile-time assert...

>> Can the host refuse due to lack of resources? > > Yes. virtgpu_ctrl_hdr.type in the response will be set to > VIRTGPU_RESP_ERR_* then. Current implementation does that only on > malloc() failure, there is no accounting (yet) to limit the amout of > memory the guest is allowed to allocate. We do probably need to work out some sort of accounting system, it can...

>> Can the host refuse due to lack of resources? > > Yes. virtgpu_ctrl_hdr.type in the response will be set to > VIRTGPU_RESP_ERR_* then. Current implementation does that only on > malloc() failure, there is no accounting (yet) to limit the amout of > memory the guest is allowed to allocate. We do probably need to work out some sort of accounting system, it can...

...: + + (1) control vq - guest->host queue for sending commands and getting + responses when required. + (2) cursor vq - guest->host queue for sending cursor position and + resource updates + +Both queues have the same format. Each request and each response have +a fixed header (struct virtgpu_ctrl_hdr), followed by command specific +data fieds. The separate cursor queue is the "fast track" for +cursor-related commands, so they go though without being possibly +delayed by other commands in the control queue. + + +drive virtio-gpu in 2D mode +--------------------------- + +The virtio-gp...

On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: > diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt > new file mode 100644 > index 0000000..9455383 > --- /dev/null > +++ b/docs/specs/virtio-gpu.txt > @@ -0,0 +1,165 @@ > +virtio-gpu specification > +======================== This document refers to the implementation for structs and does not

On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: > diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt > new file mode 100644 > index 0000000..9455383 > --- /dev/null > +++ b/docs/specs/virtio-gpu.txt > @@ -0,0 +1,165 @@ > +virtio-gpu specification > +======================== This document refers to the implementation for structs and does not

...AY_INFO > > and friends. It makes it MUCH nicer for application software to probe > for later extensions if every member of the enum is also associated with > a preprocessor macro. I don't think this will ever be shipped as library header for external users ... > > +struct virtgpu_ctrl_hdr { > > + uint32_t type; > > + uint32_t flags; > > + uint64_t fence_id; > > + uint32_t ctx_id; > > + uint32_t padding; > > +}; > > + > > Is the padding to ensure that this is aligned regardless of 32-bit or > 64-bi...

...n the host. > > + > > + 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. > > Can the host refuse due to lack of resources? Yes. virtgpu_ctrl_hdr.type in the response will be set to VIRTGPU_RESP_ERR_* then. Current implementation does that only on malloc() failure, there is no accounting (yet) to limit the amout of memory the guest is allowed to allocate. /me notes to write a section on error handling. > > +VIRTGPU_CMD_SET_SCANOUT:...

...makes it MUCH nicer for application software to probe > > for later extensions if every member of the enum is also associated with > > a preprocessor macro. > > I don't think this will ever be shipped as library header for external > users ... > > > > +struct virtgpu_ctrl_hdr { > > > + uint32_t type; > > > + uint32_t flags; > > > + uint64_t fence_id; > > > + uint32_t ctx_id; > > > + uint32_t padding; > > > +}; > > > + > > > > Is the padding to ensure that this...

...makes it MUCH nicer for application software to probe > > for later extensions if every member of the enum is also associated with > > a preprocessor macro. > > I don't think this will ever be shipped as library header for external > users ... > > > > +struct virtgpu_ctrl_hdr { > > > + uint32_t type; > > > + uint32_t flags; > > > + uint64_t fence_id; > > > + uint32_t ctx_id; > > > + uint32_t padding; > > > +}; > > > + > > > > Is the padding to ensure that this...

...> +then, mimicing write-to-clear behavior. s/mimicing/mimicking/ (stupid English rule that any verb ending in 'ic' becomes 'ick' when adding 'ed' or 'ing') > +Both queues have the same format. Each request and each response have > +a fixed header (struct virtgpu_ctrl_hdr), followed by command specific > +data fieds. The separate cursor queue is the "fast track" for s/fieds/fields/ > +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 requireme...

...> +then, mimicing write-to-clear behavior. s/mimicing/mimicking/ (stupid English rule that any verb ending in 'ic' becomes 'ick' when adding 'ed' or 'ing') > +Both queues have the same format. Each request and each response have > +a fixed header (struct virtgpu_ctrl_hdr), followed by command specific > +data fieds. The separate cursor queue is the "fast track" for s/fieds/fields/ > +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 requireme...