From: Akihiko Odaki <akihiko.odaki@gmail.com>
To: Gurchetan Singh <gurchetansingh@chromium.org>, qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, philmd@linaro.org, david@redhat.com,
stefanha@redhat.com, kraxel@redhat.com,
marcandre.lureau@redhat.com, dmitry.osipenko@collabora.com,
ray.huang@amd.com, alex.bennee@linaro.org
Subject: Re: [RFC PATCH 08/13] gfxstream + rutabaga prep: added need defintions, fields, and options
Date: Sat, 22 Apr 2023 23:54:14 +0900 [thread overview]
Message-ID: <7c7b18d6-3fc1-0855-08a8-d28e1d47f037@gmail.com> (raw)
In-Reply-To: <20230421011223.718-9-gurchetansingh@chromium.org>
On 2023/04/21 10:12, Gurchetan Singh wrote:
> This modifies the common virtio-gpu.h file have the fields and
> defintions needed by gfxstream/rutabaga. It also modifies VirtioGPUGL
> to have the runtime options needed by rutabaga. They are:
>
> - a colon separated list of capset names, defined in the virtio spec
> - a wayland socket path to enable guest Wayland passthrough
>
> The command to run these would be:
>
> -device virtio-vga-gl,capset_names=gfxstream:cross-domain, \
> wayland_socket_path=/run/user/1000/wayland-0,hostmem=8G \
It will be nice if it automatically determines the socket path according to:
https://wayland.freedesktop.org/docs/html/apb.html#Client-classwl__display_1af048371dfef7577bd39a3c04b78d0374
A documentation to set up cross-domain just like what you can find in
the crosvm book* will also be helpful.
https://crosvm.dev/book/devices/wayland.html
>
> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
> ---
> hw/display/virtio-gpu-gl.c | 2 ++
> include/hw/virtio/virtio-gpu.h | 8 ++++++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
> index 547e697333..15270b0c8a 100644
> --- a/hw/display/virtio-gpu-gl.c
> +++ b/hw/display/virtio-gpu-gl.c
> @@ -29,6 +29,8 @@ static void virtio_gpu_gl_device_realize(DeviceState *qdev, Error **errp)
> static Property virtio_gpu_gl_properties[] = {
> DEFINE_PROP_BIT("stats", VirtIOGPU, parent_obj.conf.flags,
> VIRTIO_GPU_FLAG_STATS_ENABLED, false),
> + DEFINE_PROP_STRING("capset_names", VirtIOGPUGL, capset_names),
> + DEFINE_PROP_STRING("wayland_socket_path", VirtIOGPUGL, wayland_socket_path),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
> index 421733d751..a35ade3608 100644
> --- a/include/hw/virtio/virtio-gpu.h
> +++ b/include/hw/virtio/virtio-gpu.h
> @@ -94,6 +94,7 @@ enum virtio_gpu_base_conf_flags {
> VIRTIO_GPU_FLAG_DMABUF_ENABLED,
> VIRTIO_GPU_FLAG_BLOB_ENABLED,
> VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED,
> + VIRTIO_GPU_FLAG_RUTABAGA_ENABLED,
> };
>
> #define virtio_gpu_virgl_enabled(_cfg) \
> @@ -106,6 +107,8 @@ enum virtio_gpu_base_conf_flags {
> (_cfg.flags & (1 << VIRTIO_GPU_FLAG_DMABUF_ENABLED))
> #define virtio_gpu_blob_enabled(_cfg) \
> (_cfg.flags & (1 << VIRTIO_GPU_FLAG_BLOB_ENABLED))
> +#define virtio_gpu_rutabaga_enabled(_cfg) \
> + (_cfg.flags & (1 << VIRTIO_GPU_FLAG_RUTABAGA_ENABLED))
> #define virtio_gpu_hostmem_enabled(_cfg) \
> (_cfg.hostmem > 0)
> #define virtio_gpu_context_init_enabled(_cfg) \
> @@ -217,6 +220,11 @@ struct VirtIOGPUGL {
>
> bool renderer_inited;
> bool renderer_reset;
> +
> + char *capset_names;
> + char *wayland_socket_path;
> + uint32_t num_capsets;
> + void *rutabaga;
I prefer to have a line:
struct rutabaga;
In virtio-gpu.h and use it here. Perhaps it may be a bit weird to have
such a declaration in a renderer-independent file, but it's practically
harmless, can prevent something rouge from being assigned to the member,
and allows to use the variable without annoying casts.
> };
>
> struct VhostUserGPU {
next prev parent reply other threads:[~2023-04-22 14:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 1:12 [RFC PATCH 00/13] gfxstream + rutabaga_gfx: a surprising delight or startling epiphany? Gurchetan Singh
2023-04-21 1:12 ` [RFC PATCH 01/13] virtio: Add shared memory capability Gurchetan Singh
2023-04-21 1:12 ` [RFC PATCH 02/13] virtio-gpu: hostmem Gurchetan Singh
2023-04-21 1:12 ` [RFC PATCH 03/13] virtio-gpu blob prep: improve decoding and add memory region Gurchetan Singh
2023-04-21 1:12 ` [RFC PATCH 04/13] virtio-gpu: CONTEXT_INIT feature Gurchetan Singh
2023-04-21 1:12 ` [RFC PATCH 05/13] gfxstream + rutabaga prep: virtio_gpu_gl -> virtio_gpu_virgl Gurchetan Singh
2023-04-21 9:40 ` Philippe Mathieu-Daudé
2023-04-21 1:12 ` [RFC PATCH 06/13] gfxstream + rutabaga prep: make GL device more library agnostic Gurchetan Singh
2023-04-21 1:12 ` [RFC PATCH 07/13] gfxstream + rutabaga prep: define callbacks in realize function Gurchetan Singh
2023-04-21 9:53 ` Philippe Mathieu-Daudé
2023-04-21 1:12 ` [RFC PATCH 08/13] gfxstream + rutabaga prep: added need defintions, fields, and options Gurchetan Singh
2023-04-22 14:54 ` Akihiko Odaki [this message]
2023-04-21 1:12 ` [RFC PATCH 09/13] gfxstream + rutabaga: add required meson changes Gurchetan Singh
2023-04-21 1:12 ` [RFC PATCH 10/13] gfxstream + rutabaga: add initial support for gfxstream Gurchetan Singh
2023-04-22 15:37 ` Akihiko Odaki
2023-04-21 1:12 ` [RFC PATCH 11/13] gfxstream + rutabaga: enable rutabaga Gurchetan Singh
2023-04-21 1:12 ` [RFC PATCH 12/13] HACK: use memory region API to inject memory to guest Gurchetan Singh
2023-04-22 15:46 ` Akihiko Odaki
2023-04-25 0:08 ` Gurchetan Singh
2023-04-22 19:22 ` Peter Maydell
2023-04-21 1:12 ` [RFC PATCH 13/13] HACK: schedule fence return on main AIO context Gurchetan Singh
2023-04-21 15:59 ` Stefan Hajnoczi
2023-04-21 23:20 ` Gurchetan Singh
2023-04-25 12:04 ` Stefan Hajnoczi
2023-04-21 16:02 ` [RFC PATCH 00/13] gfxstream + rutabaga_gfx: a surprising delight or startling epiphany? Stefan Hajnoczi
2023-04-21 23:54 ` Gurchetan Singh
2023-04-22 16:41 ` Akihiko Odaki
2023-04-25 0:16 ` Gurchetan Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c7b18d6-3fc1-0855-08a8-d28e1d47f037@gmail.com \
--to=akihiko.odaki@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=david@redhat.com \
--cc=dmitry.osipenko@collabora.com \
--cc=gurchetansingh@chromium.org \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=ray.huang@amd.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).