qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 {


  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).