The motivation is to isolate each context to a process for better security. A context parses commands from untrusted clients and executes them using the host GPU driver. By isolating it to a process, it cannot be used to attack the hypervisor or another context.
The first 7 commits add
VIRGL_RENDERER_BLOB_FD_TYPE_MMAP to the public API. It internally refers to a memfd or a shm. vkr is updated to create such an fd when requested.
With the render server, the
iov of a resource cannot be easily shared to another process. On the other hand, a
VIRGL_RENDERER_BLOB_FD_TYPE_MMAP fd can. The fd also gives vkr a logically contiguous mapping, allowing vkr to eliminate iov support in the future.
The last 4 commits add
VIRGL_RENDERER_MULTI_PROCESS to enable the render server. When it is set,
virgl_renderer_init starts and connects to a render server. Each call to
virgl_renderer_context_create requests the render server to fork a context process. All context method calls are forwarded to and executed in the context process.
The support is limited to vkr only. While it is possible to support vrend, there is no plan to currently.
This is still an RFC because more testing is needed. There are also tasks that can be done as a part of this MR or as follow-up MRs, which are
update the render server to use
vkr_renderer.hdirectly and skip
update meson such that venus only enabled in the render server but not libvirglrenderer
use SIGCHLD to trigger context process reaping