[virtio-dev] [PATCH v1 10/12] drm/virtio: implement context init: handle VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK

For the Sommelier guest Wayland proxy, it's desirable for the DRM fd to be pollable in response to an host compositor event. This can also be used by the 3D driver to poll events on a CPU timeline. This enables the DRM fd associated with a particular 3D context to be polled independent of KMS even

[virtio-dev] [PATCH v1 11/12] drm/virtio: implement context init: add virtio_gpu_fence_event

Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event to the DRM file descriptor when a fence on a specific ring is signaled. One difference is the event is not exposed via the UAPI -- this is because host responses are on a shared memory buffer of type BLOB_MEM_GUEST [this is the commo

[virtio-dev] [PATCH v1 12/12] drm/virtio: implement context init: advertise feature to userspace

This advertises the context init feature to userspace, along with a mask of supported capabilities. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c

[virtio-dev] [PATCH v1 07/12] drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx} to virtio_gpu_fence_alloc

These were defined in the previous commit. We'll need these parameters when allocating a dma_fence. The use case for this is multiple synchronizations timelines. The maximum number of timelines per 3D instance will be 32. Usually, only 2 are needed -- one for CPU commands, and another for GPU com

[virtio-dev] [PATCH v1 04/12] drm/virtio: implement context init: probe for feature

From: Anthoine Bourgeois Let's probe for VIRTIO_GPU_F_CONTEXT_INIT. Create a new DRM_INFO(..) line since the current one is getting too long. Signed-off-by: Anthoine Bourgeois Acked-by: Lingfeng Yang --- drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.c

[virtio-dev] [PATCH v1 08/12] drm/virtio: implement context init: stop using drv->context when creating fence

The plumbing is all here to do this. Since we always use the default fence context when allocating a fence, this makes no functional difference. We can't process just the largest fence id anymore, since it's it's associated with different timelines. It's fine for fence_id 260 to signal before 25

[virtio-dev] [PATCH v1 09/12] drm/virtio: implement context init: allocate an array of fence contexts

We don't want fences from different 3D contexts (virgl, gfxstream, venus) to be on the same timeline. With explicit context creation, we can specify the number of ring each context wants. Execbuffer can specify which ring to use. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang --- driv

[virtio-dev] [PATCH v1 06/12] drm/virtio: implement context init: track {ring_idx, emit_fence_info} in virtio_gpu_fence

Each fence should be associated with a [fence ID, fence_context, seqno]. The seqno number is just the fence id. To get the fence context, we add the ring_idx to the 3D context's base_fence_ctx. The ring_idx is between 0 and 31, inclusive. Each 3D context will have it's own base_fence_ctx. The r

[virtio-dev] [PATCH v1 05/12] drm/virtio: implement context init: support init ioctl

From: Anthoine Bourgeois This implements the context initialization ioctl. A list of params is passed in by userspace, and kernel driver validates them. The only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID. If the context has already been initialized, -EEXIST is returned. This

[virtio-dev] [PATCH v1 03/12] drm/virtio: implement context init: track valid capabilities in a mask

The valid capability IDs are between 1 to 63, and defined in the virtio gpu spec. This is used for error checking the subsequent patches. We're currently only using 2 capability IDs, so this should be plenty for the immediate future. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang ---

[virtio-dev] [PATCH v1 02/12] drm/virtgpu api: create context init feature

This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VI

[virtio-dev] [PATCH v1 01/12] virtio-gpu api: multiple context types with explicit initialization

This feature allows for each virtio-gpu 3D context to be created with a "context_init" variable. This variable can specify: - the type of protocol used by the context via the capset id. This is useful for differentiating virgl, gfxstream, and venus protocols by host userspace. - other th

[virtio-dev] [PATCH v1 00/12] Context types

Version 1 of context types: https://lists.oasis-open.org/archives/virtio-dev/202108/msg00141.html Changes since RFC: * le32 info --> {u8 ring_idx + u8 padding[3]). * Max rings is now 64. Anthoine Bourgeois (2): drm/virtio: implement context init: probe for feature drm/virtio: implement

[virtio-dev] Re: [PATCH v4] Add virtio parameter server device specification

Hi folks, I had some issues when trying to implement the sample driver for this device proposal. When the device wants to send some values to the driver, the size of the values may vary a lot, and the size may not be determined when the driver allocates buffers for them. The device knows more abou

[virtio-dev] Re: [PATCH v3] virtio-pmem: PMEM device spec

> > > > +Requests have the following format: > > > > + > > > > +\begin{lstlisting} > > > > +struct virtio_pmem_req { > > > > +le32 type; > > > > +}; > > > > +\end{lstlisting} > > > > + > > > > +\field{type} is the request command type. > > > > > > Where are the type constants defined? I was