* [PATCH v12 01/13] virtio-gpu: Unrealize GL device
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-22 10:32 ` Alex Bennée
2024-05-19 21:27 ` [PATCH v12 02/13] virtio-gpu: Handle virtio_gpu_virgl_init() failure Dmitry Osipenko
` (12 subsequent siblings)
13 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Even though GL GPU doesn't support hotplugging today, free virgl
resources when GL device is unrealized. For consistency.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-gl.c | 11 +++++++++++
hw/display/virtio-gpu-virgl.c | 6 ++++++
include/hw/virtio/virtio-gpu.h | 1 +
3 files changed, 18 insertions(+)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index e06be60dfbfc..0c0a8d136954 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -136,6 +136,16 @@ static Property virtio_gpu_gl_properties[] = {
DEFINE_PROP_END_OF_LIST(),
};
+static void virtio_gpu_gl_device_unrealize(DeviceState *qdev)
+{
+ VirtIOGPU *g = VIRTIO_GPU(qdev);
+ VirtIOGPUGL *gl = VIRTIO_GPU_GL(qdev);
+
+ if (gl->renderer_inited) {
+ virtio_gpu_virgl_deinit(g);
+ }
+}
+
static void virtio_gpu_gl_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
@@ -149,6 +159,7 @@ static void virtio_gpu_gl_class_init(ObjectClass *klass, void *data)
vgc->update_cursor_data = virtio_gpu_gl_update_cursor_data;
vdc->realize = virtio_gpu_gl_device_realize;
+ vdc->unrealize = virtio_gpu_gl_device_unrealize;
vdc->reset = virtio_gpu_gl_reset;
device_class_set_props(dc, virtio_gpu_gl_properties);
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 9f34d0e6619c..6ba4c24fda1d 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -665,3 +665,9 @@ int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
return capset2_max_ver ? 2 : 1;
}
+
+void virtio_gpu_virgl_deinit(VirtIOGPU *g)
+{
+ timer_free(g->fence_poll);
+ virgl_renderer_cleanup(NULL);
+}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 56d6e821bf04..8ece1ec2e98b 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -336,6 +336,7 @@ void virtio_gpu_virgl_fence_poll(VirtIOGPU *g);
void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g);
void virtio_gpu_virgl_reset(VirtIOGPU *g);
int virtio_gpu_virgl_init(VirtIOGPU *g);
+void virtio_gpu_virgl_deinit(VirtIOGPU *g);
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g);
#endif
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH v12 01/13] virtio-gpu: Unrealize GL device
2024-05-19 21:27 ` [PATCH v12 01/13] virtio-gpu: Unrealize GL device Dmitry Osipenko
@ 2024-05-22 10:32 ` Alex Bennée
0 siblings, 0 replies; 34+ messages in thread
From: Alex Bennée @ 2024-05-22 10:32 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> Even though GL GPU doesn't support hotplugging today, free virgl
> resources when GL device is unrealized. For consistency.
>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---
> hw/display/virtio-gpu-gl.c | 11 +++++++++++
> hw/display/virtio-gpu-virgl.c | 6 ++++++
> include/hw/virtio/virtio-gpu.h | 1 +
> 3 files changed, 18 insertions(+)
>
> diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
> index e06be60dfbfc..0c0a8d136954 100644
> --- a/hw/display/virtio-gpu-gl.c
> +++ b/hw/display/virtio-gpu-gl.c
> @@ -136,6 +136,16 @@ static Property virtio_gpu_gl_properties[] = {
> DEFINE_PROP_END_OF_LIST(),
> };
>
> +static void virtio_gpu_gl_device_unrealize(DeviceState *qdev)
> +{
> + VirtIOGPU *g = VIRTIO_GPU(qdev);
> + VirtIOGPUGL *gl = VIRTIO_GPU_GL(qdev);
> +
> + if (gl->renderer_inited) {
> + virtio_gpu_virgl_deinit(g);
Should we reset the flag at this point or are we relying on the QOM
lifetime to ensure *gl will be gone shortly after this?
> + }
> +}
> +
> static void virtio_gpu_gl_class_init(ObjectClass *klass, void *data)
> {
> DeviceClass *dc = DEVICE_CLASS(klass);
> @@ -149,6 +159,7 @@ static void virtio_gpu_gl_class_init(ObjectClass *klass, void *data)
> vgc->update_cursor_data = virtio_gpu_gl_update_cursor_data;
>
> vdc->realize = virtio_gpu_gl_device_realize;
> + vdc->unrealize = virtio_gpu_gl_device_unrealize;
> vdc->reset = virtio_gpu_gl_reset;
> device_class_set_props(dc, virtio_gpu_gl_properties);
> }
> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> index 9f34d0e6619c..6ba4c24fda1d 100644
> --- a/hw/display/virtio-gpu-virgl.c
> +++ b/hw/display/virtio-gpu-virgl.c
> @@ -665,3 +665,9 @@ int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
>
> return capset2_max_ver ? 2 : 1;
> }
> +
> +void virtio_gpu_virgl_deinit(VirtIOGPU *g)
> +{
> + timer_free(g->fence_poll);
> + virgl_renderer_cleanup(NULL);
> +}
> diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
> index 56d6e821bf04..8ece1ec2e98b 100644
> --- a/include/hw/virtio/virtio-gpu.h
> +++ b/include/hw/virtio/virtio-gpu.h
> @@ -336,6 +336,7 @@ void virtio_gpu_virgl_fence_poll(VirtIOGPU *g);
> void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g);
> void virtio_gpu_virgl_reset(VirtIOGPU *g);
> int virtio_gpu_virgl_init(VirtIOGPU *g);
> +void virtio_gpu_virgl_deinit(VirtIOGPU *g);
> int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g);
>
> #endif
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v12 02/13] virtio-gpu: Handle virtio_gpu_virgl_init() failure
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 01/13] virtio-gpu: Unrealize GL device Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-22 12:37 ` Alex Bennée
2024-05-19 21:27 ` [PATCH v12 03/13] virtio-gpu: Use pkgconfig version to decide which virgl features are available Dmitry Osipenko
` (11 subsequent siblings)
13 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
virtio_gpu_virgl_init() may fail, leading to a further Qemu crash
because Qemu assumes it never fails. Check virtio_gpu_virgl_init()
return code and don't execute virtio commands on error. Failed
virtio_gpu_virgl_init() will result in a timed out virtio commands
for a guest OS.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-gl.c | 15 +++++++++++++--
hw/display/virtio-gpu-virgl.c | 3 +++
include/hw/virtio/virtio-gpu.h | 1 +
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index 0c0a8d136954..b353c3193afa 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -29,9 +29,14 @@ static void virtio_gpu_gl_update_cursor_data(VirtIOGPU *g,
struct virtio_gpu_scanout *s,
uint32_t resource_id)
{
+ VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
uint32_t width, height;
uint32_t pixels, *data;
+ if (!gl->renderer_inited) {
+ return;
+ }
+
data = virgl_renderer_get_cursor_data(resource_id, &width, &height);
if (!data) {
return;
@@ -60,13 +65,18 @@ static void virtio_gpu_gl_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
VirtIOGPU *g = VIRTIO_GPU(vdev);
VirtIOGPUGL *gl = VIRTIO_GPU_GL(vdev);
struct virtio_gpu_ctrl_command *cmd;
+ int ret;
- if (!virtio_queue_ready(vq)) {
+ if (!virtio_queue_ready(vq) || gl->renderer_init_failed) {
return;
}
if (!gl->renderer_inited) {
- virtio_gpu_virgl_init(g);
+ ret = virtio_gpu_virgl_init(g);
+ if (ret) {
+ gl->renderer_init_failed = true;
+ return;
+ }
gl->renderer_inited = true;
}
if (gl->renderer_reset) {
@@ -101,6 +111,7 @@ static void virtio_gpu_gl_reset(VirtIODevice *vdev)
if (gl->renderer_inited && !gl->renderer_reset) {
virtio_gpu_virgl_reset_scanout(g);
gl->renderer_reset = true;
+ gl->renderer_init_failed = false;
}
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 6ba4c24fda1d..bfbc6553e879 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -668,6 +668,9 @@ int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
void virtio_gpu_virgl_deinit(VirtIOGPU *g)
{
+ if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
+ timer_free(g->print_stats);
+ }
timer_free(g->fence_poll);
virgl_renderer_cleanup(NULL);
}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 8ece1ec2e98b..236daba24dd2 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -230,6 +230,7 @@ struct VirtIOGPUGL {
bool renderer_inited;
bool renderer_reset;
+ bool renderer_init_failed;
};
struct VhostUserGPU {
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH v12 02/13] virtio-gpu: Handle virtio_gpu_virgl_init() failure
2024-05-19 21:27 ` [PATCH v12 02/13] virtio-gpu: Handle virtio_gpu_virgl_init() failure Dmitry Osipenko
@ 2024-05-22 12:37 ` Alex Bennée
0 siblings, 0 replies; 34+ messages in thread
From: Alex Bennée @ 2024-05-22 12:37 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> virtio_gpu_virgl_init() may fail, leading to a further Qemu crash
> because Qemu assumes it never fails. Check virtio_gpu_virgl_init()
> return code and don't execute virtio commands on error. Failed
> virtio_gpu_virgl_init() will result in a timed out virtio commands
> for a guest OS.
>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---
> hw/display/virtio-gpu-gl.c | 15 +++++++++++++--
> hw/display/virtio-gpu-virgl.c | 3 +++
> include/hw/virtio/virtio-gpu.h | 1 +
> 3 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
> index 0c0a8d136954..b353c3193afa 100644
> --- a/hw/display/virtio-gpu-gl.c
> +++ b/hw/display/virtio-gpu-gl.c
> @@ -29,9 +29,14 @@ static void virtio_gpu_gl_update_cursor_data(VirtIOGPU *g,
> struct virtio_gpu_scanout *s,
> uint32_t resource_id)
> {
> + VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
> uint32_t width, height;
> uint32_t pixels, *data;
>
> + if (!gl->renderer_inited) {
> + return;
> + }
> +
> data = virgl_renderer_get_cursor_data(resource_id, &width, &height);
> if (!data) {
> return;
> @@ -60,13 +65,18 @@ static void virtio_gpu_gl_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
> VirtIOGPU *g = VIRTIO_GPU(vdev);
> VirtIOGPUGL *gl = VIRTIO_GPU_GL(vdev);
> struct virtio_gpu_ctrl_command *cmd;
> + int ret;
>
> - if (!virtio_queue_ready(vq)) {
> + if (!virtio_queue_ready(vq) || gl->renderer_init_failed) {
> return;
> }
>
> if (!gl->renderer_inited) {
> - virtio_gpu_virgl_init(g);
> + ret = virtio_gpu_virgl_init(g);
> + if (ret) {
> + gl->renderer_init_failed = true;
> + return;
> + }
> gl->renderer_inited = true;
> }
> if (gl->renderer_reset) {
> @@ -101,6 +111,7 @@ static void virtio_gpu_gl_reset(VirtIODevice *vdev)
> if (gl->renderer_inited && !gl->renderer_reset) {
> virtio_gpu_virgl_reset_scanout(g);
> gl->renderer_reset = true;
> + gl->renderer_init_failed = false;
> }
> }
>
> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> index 6ba4c24fda1d..bfbc6553e879 100644
> --- a/hw/display/virtio-gpu-virgl.c
> +++ b/hw/display/virtio-gpu-virgl.c
> @@ -668,6 +668,9 @@ int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
>
> void virtio_gpu_virgl_deinit(VirtIOGPU *g)
> {
> + if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
> + timer_free(g->print_stats);
> + }
> timer_free(g->fence_poll);
> virgl_renderer_cleanup(NULL);
> }
> diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
> index 8ece1ec2e98b..236daba24dd2 100644
> --- a/include/hw/virtio/virtio-gpu.h
> +++ b/include/hw/virtio/virtio-gpu.h
> @@ -230,6 +230,7 @@ struct VirtIOGPUGL {
>
> bool renderer_inited;
> bool renderer_reset;
> + bool renderer_init_failed;
Do we really want 3 bools to represent a bunch of mutually incompatible
state? How about:
typedef enum {
/** starting state */
RS_START = 0,
/** renderer initialised */
RS_INITED,
/** renderer reset */
RS_RESET,
/** failed initialisation */
RS_INIT_FAILED
} RenderState;
then for example you could flow virtio_gpu_gl_handle_ctrl() as:
switch (gl->render_state) {
case RS_START:
{
gl->render_state = virtio_gpu_virgl_init(g) ? RS_INIT_FAILED : RS_INITED;
}
case RS_RESET:
{
virtio_gpu_virgl_reset(g);
gl->render_state = RS_INITED;
break;
}
case RS_INIT_FAILED:
/* nothing to do, return early and maybe log */
return;
case RS_INITED:
/* just continue */
break;
}
> };
>
> struct VhostUserGPU {
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v12 03/13] virtio-gpu: Use pkgconfig version to decide which virgl features are available
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 01/13] virtio-gpu: Unrealize GL device Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 02/13] virtio-gpu: Handle virtio_gpu_virgl_init() failure Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-22 12:48 ` Alex Bennée
2024-05-19 21:27 ` [PATCH v12 04/13] virtio-gpu: Support context-init feature with virglrenderer Dmitry Osipenko
` (10 subsequent siblings)
13 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
New virglrerenderer features were stabilized with release of v1.0.0.
Presence of symbols in virglrenderer.h doesn't guarantee ABI compatibility
with pre-release development versions of libvirglerender. Use virglrenderer
version to decide reliably which virgl features are available.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
meson.build | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/meson.build b/meson.build
index a9de71d45064..413ec5179145 100644
--- a/meson.build
+++ b/meson.build
@@ -2301,11 +2301,8 @@ config_host_data.set('CONFIG_PNG', png.found())
config_host_data.set('CONFIG_VNC', vnc.found())
config_host_data.set('CONFIG_VNC_JPEG', jpeg.found())
config_host_data.set('CONFIG_VNC_SASL', sasl.found())
-if virgl.found()
- config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT',
- cc.has_member('struct virgl_renderer_resource_info_ext', 'd3d_tex2d',
- prefix: '#include <virglrenderer.h>',
- dependencies: virgl))
+if virgl.version().version_compare('>=1.0.0')
+ config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
endif
config_host_data.set('CONFIG_VIRTFS', have_virtfs)
config_host_data.set('CONFIG_VTE', vte.found())
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH v12 03/13] virtio-gpu: Use pkgconfig version to decide which virgl features are available
2024-05-19 21:27 ` [PATCH v12 03/13] virtio-gpu: Use pkgconfig version to decide which virgl features are available Dmitry Osipenko
@ 2024-05-22 12:48 ` Alex Bennée
2024-05-26 23:57 ` Dmitry Osipenko
0 siblings, 1 reply; 34+ messages in thread
From: Alex Bennée @ 2024-05-22 12:48 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> New virglrerenderer features were stabilized with release of v1.0.0.
> Presence of symbols in virglrenderer.h doesn't guarantee ABI compatibility
> with pre-release development versions of libvirglerender. Use virglrenderer
> version to decide reliably which virgl features are available.
Is the requirement for 087e9a96d13 (venus: make cross-device optional)
on the host or guest side? Because I can't see its in a tagged version.
> --- a/meson.build
> +++ b/meson.build
> @@ -2301,11 +2301,8 @@ config_host_data.set('CONFIG_PNG', png.found())
> config_host_data.set('CONFIG_VNC', vnc.found())
> config_host_data.set('CONFIG_VNC_JPEG', jpeg.found())
> config_host_data.set('CONFIG_VNC_SASL', sasl.found())
> -if virgl.found()
> - config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT',
> - cc.has_member('struct virgl_renderer_resource_info_ext', 'd3d_tex2d',
> - prefix: '#include <virglrenderer.h>',
> - dependencies: virgl))
> +if virgl.version().version_compare('>=1.0.0')
> + config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
> endif
If all the host side needs is 1.0.0 then:
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH v12 03/13] virtio-gpu: Use pkgconfig version to decide which virgl features are available
2024-05-22 12:48 ` Alex Bennée
@ 2024-05-26 23:57 ` Dmitry Osipenko
0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-26 23:57 UTC (permalink / raw)
To: Alex Bennée
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 5/22/24 15:48, Alex Bennée wrote:
>> New virglrerenderer features were stabilized with release of v1.0.0.
>> Presence of symbols in virglrenderer.h doesn't guarantee ABI compatibility
>> with pre-release development versions of libvirglerender. Use virglrenderer
>> version to decide reliably which virgl features are available.
> Is the requirement for 087e9a96d13 (venus: make cross-device optional)
> on the host or guest side? Because I can't see its in a tagged version.
It's required only on guest side. Mesa 24.2 hasn't been tagged yet.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v12 04/13] virtio-gpu: Support context-init feature with virglrenderer
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (2 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 03/13] virtio-gpu: Use pkgconfig version to decide which virgl features are available Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 05/13] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled Dmitry Osipenko
` (9 subsequent siblings)
13 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
From: Huang Rui <ray.huang@amd.com>
Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
feature flags. Expose this feature and support creating virglrenderer
context with flags using context_id if libvirglrenderer is new enough.
Originally-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Antonio Caggiano <quic_acaggian@quicinc.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-gl.c | 4 ++++
hw/display/virtio-gpu-virgl.c | 20 ++++++++++++++++++--
meson.build | 1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index b353c3193afa..4d0a10070ab3 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -138,6 +138,10 @@ static void virtio_gpu_gl_device_realize(DeviceState *qdev, Error **errp)
VIRTIO_GPU_BASE(g)->virtio_config.num_capsets =
virtio_gpu_virgl_get_num_capsets(g);
+#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
+ g->parent_obj.conf.flags |= 1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED;
+#endif
+
virtio_gpu_device_realize(qdev, errp);
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index bfbc6553e879..fc667559cc41 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -106,8 +106,24 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
cc.debug_name);
- virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
- cc.debug_name);
+ if (cc.context_init) {
+ if (!virtio_gpu_context_init_enabled(g->parent_obj.conf)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: context_init disabled",
+ __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+ return;
+ }
+
+#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
+ virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
+ cc.context_init,
+ cc.nlen,
+ cc.debug_name);
+ return;
+#endif
+ }
+
+ virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
}
static void virgl_cmd_context_destroy(VirtIOGPU *g,
diff --git a/meson.build b/meson.build
index 413ec5179145..ba0f067484ca 100644
--- a/meson.build
+++ b/meson.build
@@ -2303,6 +2303,7 @@ config_host_data.set('CONFIG_VNC_JPEG', jpeg.found())
config_host_data.set('CONFIG_VNC_SASL', sasl.found())
if virgl.version().version_compare('>=1.0.0')
config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
+ config_host_data.set('HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS', 1)
endif
config_host_data.set('CONFIG_VIRTFS', have_virtfs)
config_host_data.set('CONFIG_VTE', vte.found())
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH v12 05/13] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (3 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 04/13] virtio-gpu: Support context-init feature with virglrenderer Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 06/13] virtio-gpu: Add virgl resource management Dmitry Osipenko
` (8 subsequent siblings)
13 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
The udmabuf usage is mandatory when virgl is disabled and blobs feature
enabled in the Qemu machine configuration. If virgl and blobs are enabled,
then udmabuf requirement is optional. Since udmabuf isn't widely supported
by a popular Linux distros today, let's relax the udmabuf requirement for
blobs=on,virgl=on. Now, a full-featured virtio-gpu acceleration is
available to Qemu users without a need to have udmabuf available in the
system.
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Antonio Caggiano <quic_acaggian@quicinc.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index ae831b6b3e3e..dac272ecadb1 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1472,6 +1472,7 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp)
if (virtio_gpu_blob_enabled(g->parent_obj.conf)) {
if (!virtio_gpu_rutabaga_enabled(g->parent_obj.conf) &&
+ !virtio_gpu_virgl_enabled(g->parent_obj.conf) &&
!virtio_gpu_have_udmabuf()) {
error_setg(errp, "need rutabaga or udmabuf for blob resources");
return;
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH v12 06/13] virtio-gpu: Add virgl resource management
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (4 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 05/13] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 07/13] virtio-gpu: Support blob scanout using dmabuf fd Dmitry Osipenko
` (7 subsequent siblings)
13 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
From: Huang Rui <ray.huang@amd.com>
In a preparation to adding host blobs support to virtio-gpu, add virgl
resource management that allows to retrieve resource based on its ID
and virgl resource wrapper on top of simple resource that will be contain
fields specific to virgl.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Antonio Caggiano <quic_acaggian@quicinc.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-virgl.c | 76 +++++++++++++++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index fc667559cc41..612fa86e5f34 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -22,6 +22,23 @@
#include <virglrenderer.h>
+struct virtio_gpu_virgl_resource {
+ struct virtio_gpu_simple_resource base;
+};
+
+static struct virtio_gpu_virgl_resource *
+virtio_gpu_virgl_find_resource(VirtIOGPU *g, uint32_t resource_id)
+{
+ struct virtio_gpu_simple_resource *res;
+
+ res = virtio_gpu_find_resource(g, resource_id);
+ if (!res) {
+ return NULL;
+ }
+
+ return container_of(res, struct virtio_gpu_virgl_resource, base);
+}
+
#if VIRGL_RENDERER_CALLBACKS_VERSION >= 4
static void *
virgl_get_egl_display(G_GNUC_UNUSED void *cookie)
@@ -35,11 +52,34 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_2d c2d;
struct virgl_renderer_resource_create_args args;
+ struct virtio_gpu_virgl_resource *res;
VIRTIO_GPU_FILL_CMD(c2d);
trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
c2d.width, c2d.height);
+ if (c2d.resource_id == 0) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = virtio_gpu_virgl_find_resource(g, c2d.resource_id);
+ if (res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
+ __func__, c2d.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = g_new0(struct virtio_gpu_virgl_resource, 1);
+ res->base.width = c2d.width;
+ res->base.height = c2d.height;
+ res->base.format = c2d.format;
+ res->base.resource_id = c2d.resource_id;
+ QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
+
args.handle = c2d.resource_id;
args.target = 2;
args.format = c2d.format;
@@ -59,11 +99,34 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_3d c3d;
struct virgl_renderer_resource_create_args args;
+ struct virtio_gpu_virgl_resource *res;
VIRTIO_GPU_FILL_CMD(c3d);
trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
c3d.width, c3d.height, c3d.depth);
+ if (c3d.resource_id == 0) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = virtio_gpu_virgl_find_resource(g, c3d.resource_id);
+ if (res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
+ __func__, c3d.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = g_new0(struct virtio_gpu_virgl_resource, 1);
+ res->base.width = c3d.width;
+ res->base.height = c3d.height;
+ res->base.format = c3d.format;
+ res->base.resource_id = c3d.resource_id;
+ QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
+
args.handle = c3d.resource_id;
args.target = c3d.target;
args.format = c3d.format;
@@ -82,12 +145,21 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
struct virtio_gpu_resource_unref unref;
+ struct virtio_gpu_virgl_resource *res;
struct iovec *res_iovs = NULL;
int num_iovs = 0;
VIRTIO_GPU_FILL_CMD(unref);
trace_virtio_gpu_cmd_res_unref(unref.resource_id);
+ res = virtio_gpu_virgl_find_resource(g, unref.resource_id);
+ if (!res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not exist %d\n",
+ __func__, unref.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
virgl_renderer_resource_detach_iov(unref.resource_id,
&res_iovs,
&num_iovs);
@@ -95,6 +167,10 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs);
}
virgl_renderer_resource_unref(unref.resource_id);
+
+ QTAILQ_REMOVE(&g->reslist, &res->base, next);
+
+ g_free(res);
}
static void virgl_cmd_context_create(VirtIOGPU *g,
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH v12 07/13] virtio-gpu: Support blob scanout using dmabuf fd
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (5 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 06/13] virtio-gpu: Add virgl resource management Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 08/13] virtio-gpu: Support suspension of commands processing Dmitry Osipenko
` (6 subsequent siblings)
13 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
From: Robert Beckett <bob.beckett@collabora.com>
Support displaying blob resources by handling SET_SCANOUT_BLOB
command.
Signed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Antonio Caggiano <quic_acaggian@quicinc.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-virgl.c | 109 +++++++++++++++++++++++++++++++++
hw/display/virtio-gpu.c | 12 ++--
include/hw/virtio/virtio-gpu.h | 7 +++
meson.build | 1 +
4 files changed, 123 insertions(+), 6 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 612fa86e5f34..7d4d2882a5af 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -17,6 +17,8 @@
#include "trace.h"
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
+#include "hw/virtio/virtio-gpu-bswap.h"
+#include "hw/virtio/virtio-gpu-pixman.h"
#include "ui/egl-helpers.h"
@@ -78,6 +80,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
res->base.height = c2d.height;
res->base.format = c2d.format;
res->base.resource_id = c2d.resource_id;
+ res->base.dmabuf_fd = -1;
QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
args.handle = c2d.resource_id;
@@ -125,6 +128,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
res->base.height = c3d.height;
res->base.format = c3d.format;
res->base.resource_id = c3d.resource_id;
+ res->base.dmabuf_fd = -1;
QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
args.handle = c3d.resource_id;
@@ -509,6 +513,106 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
g_free(resp);
}
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+ struct virtio_gpu_framebuffer fb = { 0 };
+ struct virgl_renderer_resource_info info;
+ struct virtio_gpu_virgl_resource *res;
+ struct virtio_gpu_set_scanout_blob ss;
+ uint64_t fbend;
+
+ VIRTIO_GPU_FILL_CMD(ss);
+ virtio_gpu_scanout_blob_bswap(&ss);
+ trace_virtio_gpu_cmd_set_scanout_blob(ss.scanout_id, ss.resource_id,
+ ss.r.width, ss.r.height, ss.r.x,
+ ss.r.y);
+
+ if (ss.scanout_id >= g->parent_obj.conf.max_outputs) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: illegal scanout id specified %d",
+ __func__, ss.scanout_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_SCANOUT_ID;
+ return;
+ }
+
+ if (ss.resource_id == 0) {
+ virtio_gpu_disable_scanout(g, ss.scanout_id);
+ return;
+ }
+
+ if (ss.width < 16 ||
+ ss.height < 16 ||
+ ss.r.x + ss.r.width > ss.width ||
+ ss.r.y + ss.r.height > ss.height) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: illegal scanout %d bounds for"
+ " resource %d, rect (%d,%d)+%d,%d, fb %d %d\n",
+ __func__, ss.scanout_id, ss.resource_id,
+ ss.r.x, ss.r.y, ss.r.width, ss.r.height,
+ ss.width, ss.height);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+ return;
+ }
+
+ res = virtio_gpu_virgl_find_resource(g, ss.resource_id);
+ if (!res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not exist %d\n",
+ __func__, ss.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+ if (virgl_renderer_resource_get_info(ss.resource_id, &info)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not have info %d\n",
+ __func__, ss.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+ if (res->base.dmabuf_fd < 0) {
+ res->base.dmabuf_fd = info.fd;
+ }
+ if (res->base.dmabuf_fd < 0) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource not backed by dmabuf %d\n",
+ __func__, ss.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ fb.format = virtio_gpu_get_pixman_format(ss.format);
+ if (!fb.format) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: pixel format not supported %d\n",
+ __func__, ss.format);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+ return;
+ }
+
+ fb.bytes_pp = DIV_ROUND_UP(PIXMAN_FORMAT_BPP(fb.format), 8);
+ fb.width = ss.width;
+ fb.height = ss.height;
+ fb.stride = ss.strides[0];
+ fb.offset = ss.offsets[0] + ss.r.x * fb.bytes_pp + ss.r.y * fb.stride;
+
+ fbend = fb.offset;
+ fbend += fb.stride * (ss.r.height - 1);
+ fbend += fb.bytes_pp * ss.r.width;
+ if (fbend > res->base.blob_size) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: fb end out of range\n",
+ __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+ return;
+ }
+
+ g->parent_obj.enable = 1;
+ if (virtio_gpu_update_dmabuf(g, ss.scanout_id, &res->base, &fb, &ss.r)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to update dmabuf\n",
+ __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+ return;
+ }
+
+ virtio_gpu_update_scanout(g, ss.scanout_id, &res->base, &fb, &ss.r);
+}
+#endif /* HAVE_VIRGL_RESOURCE_BLOB */
+
void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
@@ -575,6 +679,11 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
case VIRTIO_GPU_CMD_GET_EDID:
virtio_gpu_get_edid(g, cmd);
break;
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+ case VIRTIO_GPU_CMD_SET_SCANOUT_BLOB:
+ virgl_cmd_set_scanout_blob(g, cmd);
+ break;
+#endif /* HAVE_VIRGL_RESOURCE_BLOB */
default:
cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index dac272ecadb1..1e57a53d346c 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -380,7 +380,7 @@ static void virtio_gpu_resource_create_blob(VirtIOGPU *g,
QTAILQ_INSERT_HEAD(&g->reslist, res, next);
}
-static void virtio_gpu_disable_scanout(VirtIOGPU *g, int scanout_id)
+void virtio_gpu_disable_scanout(VirtIOGPU *g, int scanout_id)
{
struct virtio_gpu_scanout *scanout = &g->parent_obj.scanout[scanout_id];
struct virtio_gpu_simple_resource *res;
@@ -597,11 +597,11 @@ static void virtio_unref_resource(pixman_image_t *image, void *data)
pixman_image_unref(data);
}
-static void virtio_gpu_update_scanout(VirtIOGPU *g,
- uint32_t scanout_id,
- struct virtio_gpu_simple_resource *res,
- struct virtio_gpu_framebuffer *fb,
- struct virtio_gpu_rect *r)
+void virtio_gpu_update_scanout(VirtIOGPU *g,
+ uint32_t scanout_id,
+ struct virtio_gpu_simple_resource *res,
+ struct virtio_gpu_framebuffer *fb,
+ struct virtio_gpu_rect *r)
{
struct virtio_gpu_simple_resource *ores;
struct virtio_gpu_scanout *scanout;
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 236daba24dd2..a98cb47ca0fa 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -330,6 +330,13 @@ int virtio_gpu_update_dmabuf(VirtIOGPU *g,
struct virtio_gpu_framebuffer *fb,
struct virtio_gpu_rect *r);
+void virtio_gpu_update_scanout(VirtIOGPU *g,
+ uint32_t scanout_id,
+ struct virtio_gpu_simple_resource *res,
+ struct virtio_gpu_framebuffer *fb,
+ struct virtio_gpu_rect *r);
+void virtio_gpu_disable_scanout(VirtIOGPU *g, int scanout_id);
+
/* virtio-gpu-3d.c */
void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd);
diff --git a/meson.build b/meson.build
index ba0f067484ca..503a7736eda0 100644
--- a/meson.build
+++ b/meson.build
@@ -2304,6 +2304,7 @@ config_host_data.set('CONFIG_VNC_SASL', sasl.found())
if virgl.version().version_compare('>=1.0.0')
config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
config_host_data.set('HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS', 1)
+ config_host_data.set('HAVE_VIRGL_RESOURCE_BLOB', 1)
endif
config_host_data.set('CONFIG_VIRTFS', have_virtfs)
config_host_data.set('CONFIG_VTE', vte.found())
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH v12 08/13] virtio-gpu: Support suspension of commands processing
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (6 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 07/13] virtio-gpu: Support blob scanout using dmabuf fd Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 09/13] virtio-gpu: Handle resource blob commands Dmitry Osipenko
` (5 subsequent siblings)
13 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Check whether command processing has been finished; otherwise, stop
processing commands and retry the command again next time. This allows
us to support asynchronous execution of non-fenced commands needed for
unmapping host blobs safely.
Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 1e57a53d346c..6c8c7213bafa 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1054,6 +1054,11 @@ void virtio_gpu_process_cmdq(VirtIOGPU *g)
/* process command */
vgc->process_cmd(g, cmd);
+ /* command suspended */
+ if (!cmd->finished && !(cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_FENCE)) {
+ break;
+ }
+
QTAILQ_REMOVE(&g->cmdq, cmd, next);
if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
g->stats.requests++;
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH v12 09/13] virtio-gpu: Handle resource blob commands
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (7 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 08/13] virtio-gpu: Support suspension of commands processing Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-20 3:50 ` Akihiko Odaki
2024-05-19 21:27 ` [PATCH v12 10/13] virtio-gpu: Move fence_poll timer to VirtIOGPUGL Dmitry Osipenko
` (4 subsequent siblings)
13 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
From: Antonio Caggiano <antonio.caggiano@collabora.com>
Support BLOB resources creation, mapping and unmapping by calling the
new stable virglrenderer 0.10 interface. Only enabled when available and
via the blob config. E.g. -device virtio-vga-gl,blob=true
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Signed-off-by: Xenia Ragiadakou <xenia.ragiadakou@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-virgl.c | 310 ++++++++++++++++++++++++++++++++-
hw/display/virtio-gpu.c | 4 +-
include/hw/virtio/virtio-gpu.h | 2 +
3 files changed, 312 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 7d4d2882a5af..63a5a983aad6 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -26,6 +26,18 @@
struct virtio_gpu_virgl_resource {
struct virtio_gpu_simple_resource base;
+ MemoryRegion *mr;
+
+ /*
+ * Used by virgl_cmd_resource_unref() to know whether async
+ * unmapping has been started. Blob can be both mapped/unmapped
+ * on unref and we shouldn't unmap blob that wasn't mapped in the
+ * first place because it's a error condition. This flag prevents
+ * performing step 3 of the async unmapping process described in the
+ * comment to virtio_gpu_virgl_async_unmap_resource_blob() if blob
+ * wasn't mapped in the first place on unref.
+ */
+ bool async_unmap_in_progress;
};
static struct virtio_gpu_virgl_resource *
@@ -49,6 +61,128 @@ virgl_get_egl_display(G_GNUC_UNUSED void *cookie)
}
#endif
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+struct virtio_gpu_virgl_hostmem_region {
+ MemoryRegion mr;
+ struct VirtIOGPU *g;
+ struct virtio_gpu_virgl_resource *res;
+};
+
+static void virtio_gpu_virgl_resume_cmdq_bh(void *opaque)
+{
+ VirtIOGPU *g = opaque;
+
+ virtio_gpu_process_cmdq(g);
+}
+
+static void virtio_gpu_virgl_hostmem_region_free(void *obj)
+{
+ MemoryRegion *mr = MEMORY_REGION(obj);
+ struct virtio_gpu_virgl_hostmem_region *vmr;
+ VirtIOGPUBase *b;
+ VirtIOGPUGL *gl;
+
+ vmr = container_of(mr, struct virtio_gpu_virgl_hostmem_region, mr);
+ vmr->res->mr = NULL;
+
+ b = VIRTIO_GPU_BASE(vmr->g);
+ b->renderer_blocked--;
+
+ /*
+ * memory_region_unref() is executed from RCU thread context, while
+ * virglrenderer works only on the main-loop thread that's holding GL
+ * context.
+ */
+ gl = VIRTIO_GPU_GL(vmr->g);
+ qemu_bh_schedule(gl->cmdq_resume_bh);
+ g_free(vmr);
+}
+
+static int
+virtio_gpu_virgl_map_resource_blob(VirtIOGPU *g,
+ struct virtio_gpu_virgl_resource *res,
+ uint64_t offset)
+{
+ struct virtio_gpu_virgl_hostmem_region *vmr;
+ VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
+ MemoryRegion *mr;
+ uint64_t size;
+ void *data;
+ int ret;
+
+ if (!virtio_gpu_hostmem_enabled(b->conf)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: hostmem disabled\n", __func__);
+ return -EOPNOTSUPP;
+ }
+
+ ret = virgl_renderer_resource_map(res->base.resource_id, &data, &size);
+ if (ret) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to map virgl resource: %s\n",
+ __func__, strerror(-ret));
+ return ret;
+ }
+
+ vmr = g_new0(struct virtio_gpu_virgl_hostmem_region, 1);
+ vmr->res = res;
+ vmr->g = g;
+
+ mr = &vmr->mr;
+ memory_region_init_ram_ptr(mr, OBJECT(mr), "blob", size, data);
+ memory_region_add_subregion(&b->hostmem, offset, mr);
+ memory_region_set_enabled(mr, true);
+
+ /*
+ * MR could outlive the resource if MR's reference is held outside of
+ * virtio-gpu. In order to prevent unmapping resource while MR is alive,
+ * and thus, making the data pointer invalid, we will block virtio-gpu
+ * command processing until MR is fully unreferenced and freed.
+ */
+ OBJECT(mr)->free = virtio_gpu_virgl_hostmem_region_free;
+
+ res->mr = mr;
+
+ return 0;
+}
+
+static int
+virtio_gpu_virgl_async_unmap_resource_blob(VirtIOGPU *g,
+ struct virtio_gpu_virgl_resource *res)
+{
+ VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
+ MemoryRegion *mr = res->mr;
+ int ret;
+
+ /*
+ * Perform async unmapping in 3 steps:
+ *
+ * 1. Begin async unmapping with memory_region_del_subregion()
+ * and suspend/block cmd processing.
+ * 2. Wait for res->mr to be freed and cmd processing resumed
+ * asynchronously by virtio_gpu_virgl_hostmem_region_free().
+ * 3. Finish the unmapping with final virgl_renderer_resource_unmap().
+ */
+ if (mr) {
+ /* render will be unblocked once MR is freed */
+ b->renderer_blocked++;
+
+ /* memory region owns self res->mr object and frees it by itself */
+ memory_region_set_enabled(mr, false);
+ memory_region_del_subregion(&b->hostmem, mr);
+ object_unparent(OBJECT(mr));
+ } else {
+ ret = virgl_renderer_resource_unmap(res->base.resource_id);
+ if (ret) {
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: failed to unmap virgl resource: %s\n",
+ __func__, strerror(-ret));
+ return ret;
+ }
+ }
+
+ return 0;
+}
+#endif /* HAVE_VIRGL_RESOURCE_BLOB */
+
static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
@@ -146,12 +280,14 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
}
static void virgl_cmd_resource_unref(VirtIOGPU *g,
- struct virtio_gpu_ctrl_command *cmd)
+ struct virtio_gpu_ctrl_command *cmd,
+ bool *cmd_suspended)
{
struct virtio_gpu_resource_unref unref;
struct virtio_gpu_virgl_resource *res;
struct iovec *res_iovs = NULL;
int num_iovs = 0;
+ int ret;
VIRTIO_GPU_FILL_CMD(unref);
trace_virtio_gpu_cmd_res_unref(unref.resource_id);
@@ -164,6 +300,22 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
return;
}
+ if (res->mr || res->async_unmap_in_progress) {
+ ret = virtio_gpu_virgl_async_unmap_resource_blob(g, res);
+ if (ret) {
+ cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+ return;
+ }
+
+ if (res->mr) {
+ res->async_unmap_in_progress = true;
+ *cmd_suspended = true;
+ return;
+ } else {
+ res->async_unmap_in_progress = false;
+ }
+ }
+
virgl_renderer_resource_detach_iov(unref.resource_id,
&res_iovs,
&num_iovs);
@@ -514,6 +666,137 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
}
#ifdef HAVE_VIRGL_RESOURCE_BLOB
+static void virgl_cmd_resource_create_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+ struct virgl_renderer_resource_create_blob_args virgl_args = { 0 };
+ struct virtio_gpu_resource_create_blob cblob;
+ struct virtio_gpu_virgl_resource *res;
+ int ret;
+
+ if (!virtio_gpu_blob_enabled(g->parent_obj.conf)) {
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+ return;
+ }
+
+ VIRTIO_GPU_FILL_CMD(cblob);
+ virtio_gpu_create_blob_bswap(&cblob);
+ trace_virtio_gpu_cmd_res_create_blob(cblob.resource_id, cblob.size);
+
+ if (cblob.resource_id == 0) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = virtio_gpu_virgl_find_resource(g, cblob.resource_id);
+ if (res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
+ __func__, cblob.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = g_new0(struct virtio_gpu_virgl_resource, 1);
+ res->base.resource_id = cblob.resource_id;
+ res->base.blob_size = cblob.size;
+ res->base.dmabuf_fd = -1;
+
+ if (cblob.blob_mem != VIRTIO_GPU_BLOB_MEM_HOST3D) {
+ ret = virtio_gpu_create_mapping_iov(g, cblob.nr_entries, sizeof(cblob),
+ cmd, &res->base.addrs,
+ &res->base.iov, &res->base.iov_cnt);
+ if (!ret) {
+ g_free(res);
+ cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+ return;
+ }
+ }
+
+ virgl_args.res_handle = cblob.resource_id;
+ virgl_args.ctx_id = cblob.hdr.ctx_id;
+ virgl_args.blob_mem = cblob.blob_mem;
+ virgl_args.blob_id = cblob.blob_id;
+ virgl_args.blob_flags = cblob.blob_flags;
+ virgl_args.size = cblob.size;
+ virgl_args.iovecs = res->base.iov;
+ virgl_args.num_iovs = res->base.iov_cnt;
+
+ ret = virgl_renderer_resource_create_blob(&virgl_args);
+ if (ret) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: virgl blob create error: %s\n",
+ __func__, strerror(-ret));
+ cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+ virtio_gpu_cleanup_mapping(g, &res->base);
+ g_free(res);
+ return;
+ }
+
+ QTAILQ_INSERT_HEAD(&g->reslist, &res->base, next);
+}
+
+static void virgl_cmd_resource_map_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+ struct virtio_gpu_resource_map_blob mblob;
+ struct virtio_gpu_virgl_resource *res;
+ struct virtio_gpu_resp_map_info resp;
+ int ret;
+
+ VIRTIO_GPU_FILL_CMD(mblob);
+ virtio_gpu_map_blob_bswap(&mblob);
+
+ res = virtio_gpu_virgl_find_resource(g, mblob.resource_id);
+ if (!res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not exist %d\n",
+ __func__, mblob.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ ret = virtio_gpu_virgl_map_resource_blob(g, res, mblob.offset);
+ if (ret) {
+ cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+ return;
+ }
+
+ memset(&resp, 0, sizeof(resp));
+ resp.hdr.type = VIRTIO_GPU_RESP_OK_MAP_INFO;
+ virgl_renderer_resource_get_map_info(mblob.resource_id, &resp.map_info);
+ virtio_gpu_ctrl_response(g, cmd, &resp.hdr, sizeof(resp));
+}
+
+static void virgl_cmd_resource_unmap_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd,
+ bool *cmd_suspended)
+{
+ struct virtio_gpu_resource_unmap_blob ublob;
+ struct virtio_gpu_virgl_resource *res;
+ int ret;
+
+ VIRTIO_GPU_FILL_CMD(ublob);
+ virtio_gpu_unmap_blob_bswap(&ublob);
+
+ res = virtio_gpu_virgl_find_resource(g, ublob.resource_id);
+ if (!res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not exist %d\n",
+ __func__, ublob.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ ret = virtio_gpu_virgl_async_unmap_resource_blob(g, res);
+ if (ret) {
+ cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+ return;
+ }
+
+ if (res->mr) {
+ *cmd_suspended = true;
+ }
+}
+
static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
@@ -616,6 +899,8 @@ static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
+ bool cmd_suspended = false;
+
VIRTIO_GPU_FILL_CMD(cmd->cmd_hdr);
virgl_renderer_force_ctx_0();
@@ -657,7 +942,7 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
virgl_cmd_resource_flush(g, cmd);
break;
case VIRTIO_GPU_CMD_RESOURCE_UNREF:
- virgl_cmd_resource_unref(g, cmd);
+ virgl_cmd_resource_unref(g, cmd, &cmd_suspended);
break;
case VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE:
/* TODO add security */
@@ -680,6 +965,15 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
virtio_gpu_get_edid(g, cmd);
break;
#ifdef HAVE_VIRGL_RESOURCE_BLOB
+ case VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB:
+ virgl_cmd_resource_create_blob(g, cmd);
+ break;
+ case VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB:
+ virgl_cmd_resource_map_blob(g, cmd);
+ break;
+ case VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB:
+ virgl_cmd_resource_unmap_blob(g, cmd, &cmd_suspended);
+ break;
case VIRTIO_GPU_CMD_SET_SCANOUT_BLOB:
virgl_cmd_set_scanout_blob(g, cmd);
break;
@@ -689,7 +983,7 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
break;
}
- if (cmd->finished) {
+ if (cmd_suspended || cmd->finished) {
return;
}
if (cmd->error) {
@@ -827,6 +1121,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
{
int ret;
uint32_t flags = 0;
+ VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
#if VIRGL_RENDERER_CALLBACKS_VERSION >= 4
if (qemu_egl_display) {
@@ -854,6 +1149,11 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
virtio_gpu_print_stats, g);
timer_mod(g->print_stats, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 1000);
}
+
+ gl->cmdq_resume_bh = aio_bh_new(qemu_get_aio_context(),
+ virtio_gpu_virgl_resume_cmdq_bh,
+ g);
+
return 0;
}
@@ -869,6 +1169,10 @@ int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
void virtio_gpu_virgl_deinit(VirtIOGPU *g)
{
+ VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
+
+ qemu_bh_delete(gl->cmdq_resume_bh);
+
if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
timer_free(g->print_stats);
}
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 6c8c7213bafa..052ab493a00b 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1483,10 +1483,12 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp)
return;
}
+#ifndef HAVE_VIRGL_RESOURCE_BLOB
if (virtio_gpu_virgl_enabled(g->parent_obj.conf)) {
- error_setg(errp, "blobs and virgl are not compatible (yet)");
+ error_setg(errp, "old virglrenderer, blob resources unsupported");
return;
}
+#endif
}
if (!virtio_gpu_base_device_realize(qdev,
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index a98cb47ca0fa..f3c8014acc80 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -231,6 +231,8 @@ struct VirtIOGPUGL {
bool renderer_inited;
bool renderer_reset;
bool renderer_init_failed;
+
+ QEMUBH *cmdq_resume_bh;
};
struct VhostUserGPU {
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH v12 09/13] virtio-gpu: Handle resource blob commands
2024-05-19 21:27 ` [PATCH v12 09/13] virtio-gpu: Handle resource blob commands Dmitry Osipenko
@ 2024-05-20 3:50 ` Akihiko Odaki
0 siblings, 0 replies; 34+ messages in thread
From: Akihiko Odaki @ 2024-05-20 3:50 UTC (permalink / raw)
To: Dmitry Osipenko, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 2024/05/20 6:27, Dmitry Osipenko wrote:
> From: Antonio Caggiano <antonio.caggiano@collabora.com>
>
> Support BLOB resources creation, mapping and unmapping by calling the
> new stable virglrenderer 0.10 interface. Only enabled when available and
> via the blob config. E.g. -device virtio-vga-gl,blob=true
>
> Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
> Signed-off-by: Xenia Ragiadakou <xenia.ragiadakou@amd.com>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---
> hw/display/virtio-gpu-virgl.c | 310 ++++++++++++++++++++++++++++++++-
> hw/display/virtio-gpu.c | 4 +-
> include/hw/virtio/virtio-gpu.h | 2 +
> 3 files changed, 312 insertions(+), 4 deletions(-)
>
> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> index 7d4d2882a5af..63a5a983aad6 100644
> --- a/hw/display/virtio-gpu-virgl.c
> +++ b/hw/display/virtio-gpu-virgl.c
> @@ -26,6 +26,18 @@
>
> struct virtio_gpu_virgl_resource {
> struct virtio_gpu_simple_resource base;
> + MemoryRegion *mr;
> +
> + /*
> + * Used by virgl_cmd_resource_unref() to know whether async
> + * unmapping has been started. Blob can be both mapped/unmapped
> + * on unref and we shouldn't unmap blob that wasn't mapped in the
> + * first place because it's a error condition. This flag prevents
> + * performing step 3 of the async unmapping process described in the
> + * comment to virtio_gpu_virgl_async_unmap_resource_blob() if blob
> + * wasn't mapped in the first place on unref.
> + */
> + bool async_unmap_in_progress;
I suggest adding a field that tells if mr is deleted to
virtio_gpu_virgl_hostmem_region instead to minimize the size of
virtio_gpu_virgl_resource.
> };
>
> static struct virtio_gpu_virgl_resource *
> @@ -49,6 +61,128 @@ virgl_get_egl_display(G_GNUC_UNUSED void *cookie)
> }
> #endif
>
> +#ifdef HAVE_VIRGL_RESOURCE_BLOB
> +struct virtio_gpu_virgl_hostmem_region {
> + MemoryRegion mr;
> + struct VirtIOGPU *g;
> + struct virtio_gpu_virgl_resource *res;
> +};
> +
> +static void virtio_gpu_virgl_resume_cmdq_bh(void *opaque)
> +{
> + VirtIOGPU *g = opaque;
> +
> + virtio_gpu_process_cmdq(g);
> +}
> +
> +static void virtio_gpu_virgl_hostmem_region_free(void *obj)
> +{
> + MemoryRegion *mr = MEMORY_REGION(obj);
> + struct virtio_gpu_virgl_hostmem_region *vmr;
> + VirtIOGPUBase *b;
> + VirtIOGPUGL *gl;
> +
> + vmr = container_of(mr, struct virtio_gpu_virgl_hostmem_region, mr);
> + vmr->res->mr = NULL;
> +
> + b = VIRTIO_GPU_BASE(vmr->g);
> + b->renderer_blocked--;
> +
> + /*
> + * memory_region_unref() is executed from RCU thread context, while
> + * virglrenderer works only on the main-loop thread that's holding GL
> + * context.
> + */
> + gl = VIRTIO_GPU_GL(vmr->g);
> + qemu_bh_schedule(gl->cmdq_resume_bh);
> + g_free(vmr);
> +}
> +
> +static int
> +virtio_gpu_virgl_map_resource_blob(VirtIOGPU *g,
> + struct virtio_gpu_virgl_resource *res,
> + uint64_t offset)
> +{
> + struct virtio_gpu_virgl_hostmem_region *vmr;
> + VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
> + MemoryRegion *mr;
> + uint64_t size;
> + void *data;
> + int ret;
> +
> + if (!virtio_gpu_hostmem_enabled(b->conf)) {
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: hostmem disabled\n", __func__);
> + return -EOPNOTSUPP;
> + }
> +
> + ret = virgl_renderer_resource_map(res->base.resource_id, &data, &size);
> + if (ret) {
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to map virgl resource: %s\n",
> + __func__, strerror(-ret));
> + return ret;
> + }
> +
> + vmr = g_new0(struct virtio_gpu_virgl_hostmem_region, 1);
> + vmr->res = res;
> + vmr->g = g;
> +
> + mr = &vmr->mr;
> + memory_region_init_ram_ptr(mr, OBJECT(mr), "blob", size, data);
> + memory_region_add_subregion(&b->hostmem, offset, mr);
> + memory_region_set_enabled(mr, true);
> +
> + /*
> + * MR could outlive the resource if MR's reference is held outside of
> + * virtio-gpu. In order to prevent unmapping resource while MR is alive,
> + * and thus, making the data pointer invalid, we will block virtio-gpu
> + * command processing until MR is fully unreferenced and freed.
> + */
> + OBJECT(mr)->free = virtio_gpu_virgl_hostmem_region_free;
> +
> + res->mr = mr;
> +
> + return 0;
> +}
> +
> +static int
> +virtio_gpu_virgl_async_unmap_resource_blob(VirtIOGPU *g,
> + struct virtio_gpu_virgl_resource *res)
> +{
> + VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
> + MemoryRegion *mr = res->mr;
> + int ret;
> +
> + /*
> + * Perform async unmapping in 3 steps:
> + *
> + * 1. Begin async unmapping with memory_region_del_subregion()
> + * and suspend/block cmd processing.
> + * 2. Wait for res->mr to be freed and cmd processing resumed
> + * asynchronously by virtio_gpu_virgl_hostmem_region_free().
> + * 3. Finish the unmapping with final virgl_renderer_resource_unmap().
> + */
> + if (mr) {
> + /* render will be unblocked once MR is freed */
> + b->renderer_blocked++;
> +
> + /* memory region owns self res->mr object and frees it by itself */
> + memory_region_set_enabled(mr, false);
> + memory_region_del_subregion(&b->hostmem, mr);
> + object_unparent(OBJECT(mr));
> + } else {
> + ret = virgl_renderer_resource_unmap(res->base.resource_id);
> + if (ret) {
> + qemu_log_mask(LOG_GUEST_ERROR,
> + "%s: failed to unmap virgl resource: %s\n",
> + __func__, strerror(-ret));
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +#endif /* HAVE_VIRGL_RESOURCE_BLOB */
> +
> static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> struct virtio_gpu_ctrl_command *cmd)
> {
> @@ -146,12 +280,14 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> }
>
> static void virgl_cmd_resource_unref(VirtIOGPU *g,
> - struct virtio_gpu_ctrl_command *cmd)
> + struct virtio_gpu_ctrl_command *cmd,
> + bool *cmd_suspended)
> {
> struct virtio_gpu_resource_unref unref;
> struct virtio_gpu_virgl_resource *res;
> struct iovec *res_iovs = NULL;
> int num_iovs = 0;
> + int ret;
>
> VIRTIO_GPU_FILL_CMD(unref);
> trace_virtio_gpu_cmd_res_unref(unref.resource_id);
> @@ -164,6 +300,22 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
> return;
> }
>
> + if (res->mr || res->async_unmap_in_progress) {
> + ret = virtio_gpu_virgl_async_unmap_resource_blob(g, res);
> + if (ret) {
> + cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
> + return;
> + }
> +
> + if (res->mr) {
I suggest letting virtio_gpu_virgl_async_unmap_resource_blob() having a
"suspended" parameter since we have a similar pattern also in
virgl_cmd_resource_unmap_blob().
You may also remove "async" from the name of
virtio_gpu_virgl_async_unmap_resource_blob() because:
- It's obvious it can be asynchronous if there is a "suspended"
parameter; asynchronous if it becomes true.
- It synchronously completes the operation if the memory region is
already deleted. Again, it's obvious if there is a "suspended"
parameter; synchrouns if it becomes false.
- You don't name virgl_cmd_resource_unref() like
virgl_cmd_resource_async_unref().
> + res->async_unmap_in_progress = true;
> + *cmd_suspended = true;
> + return;
> + } else {
> + res->async_unmap_in_progress = false;
> + }
> + }
> +
> virgl_renderer_resource_detach_iov(unref.resource_id,
> &res_iovs,
> &num_iovs);
> @@ -514,6 +666,137 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
> }
>
> #ifdef HAVE_VIRGL_RESOURCE_BLOB
> +static void virgl_cmd_resource_create_blob(VirtIOGPU *g,
> + struct virtio_gpu_ctrl_command *cmd)
> +{
> + struct virgl_renderer_resource_create_blob_args virgl_args = { 0 };
> + struct virtio_gpu_resource_create_blob cblob;
> + struct virtio_gpu_virgl_resource *res;
> + int ret;
> +
> + if (!virtio_gpu_blob_enabled(g->parent_obj.conf)) {
> + cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
> + return;
> + }
> +
> + VIRTIO_GPU_FILL_CMD(cblob);
> + virtio_gpu_create_blob_bswap(&cblob);
> + trace_virtio_gpu_cmd_res_create_blob(cblob.resource_id, cblob.size);
> +
> + if (cblob.resource_id == 0) {
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
> + __func__);
> + cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
> + return;
> + }
> +
> + res = virtio_gpu_virgl_find_resource(g, cblob.resource_id);
> + if (res) {
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
> + __func__, cblob.resource_id);
> + cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
> + return;
> + }
> +
> + res = g_new0(struct virtio_gpu_virgl_resource, 1);
> + res->base.resource_id = cblob.resource_id;
> + res->base.blob_size = cblob.size;
> + res->base.dmabuf_fd = -1;
> +
> + if (cblob.blob_mem != VIRTIO_GPU_BLOB_MEM_HOST3D) {
> + ret = virtio_gpu_create_mapping_iov(g, cblob.nr_entries, sizeof(cblob),
> + cmd, &res->base.addrs,
> + &res->base.iov, &res->base.iov_cnt);
> + if (!ret) {
> + g_free(res);
Use g_autofree instead of writing duplicate g_free() calls. See
docs/devel/style.rst for details.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v12 10/13] virtio-gpu: Move fence_poll timer to VirtIOGPUGL
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (8 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 09/13] virtio-gpu: Handle resource blob commands Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-20 3:51 ` Akihiko Odaki
2024-05-19 21:27 ` [PATCH v12 11/13] virtio-gpu: Move print_stats " Dmitry Osipenko
` (3 subsequent siblings)
13 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Move fence_poll timer to VirtIOGPUGL for consistency with cmdq_resume_bh
that are used only by GL device.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-virgl.c | 9 +++++----
include/hw/virtio/virtio-gpu.h | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 63a5a983aad6..c8b25a0f5d7c 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -1089,11 +1089,12 @@ static void virtio_gpu_print_stats(void *opaque)
static void virtio_gpu_fence_poll(void *opaque)
{
VirtIOGPU *g = opaque;
+ VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
virgl_renderer_poll();
virtio_gpu_process_cmdq(g);
if (!QTAILQ_EMPTY(&g->cmdq) || !QTAILQ_EMPTY(&g->fenceq)) {
- timer_mod(g->fence_poll, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 10);
+ timer_mod(gl->fence_poll, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 10);
}
}
@@ -1141,8 +1142,8 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
return ret;
}
- g->fence_poll = timer_new_ms(QEMU_CLOCK_VIRTUAL,
- virtio_gpu_fence_poll, g);
+ gl->fence_poll = timer_new_ms(QEMU_CLOCK_VIRTUAL,
+ virtio_gpu_fence_poll, g);
if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
g->print_stats = timer_new_ms(QEMU_CLOCK_VIRTUAL,
@@ -1176,6 +1177,6 @@ void virtio_gpu_virgl_deinit(VirtIOGPU *g)
if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
timer_free(g->print_stats);
}
- timer_free(g->fence_poll);
+ timer_free(gl->fence_poll);
virgl_renderer_cleanup(NULL);
}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index f3c8014acc80..529c34481158 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -195,7 +195,6 @@ struct VirtIOGPU {
uint64_t hostmem;
bool processing_cmdq;
- QEMUTimer *fence_poll;
QEMUTimer *print_stats;
uint32_t inflight;
@@ -233,6 +232,7 @@ struct VirtIOGPUGL {
bool renderer_init_failed;
QEMUBH *cmdq_resume_bh;
+ QEMUTimer *fence_poll;
};
struct VhostUserGPU {
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH v12 10/13] virtio-gpu: Move fence_poll timer to VirtIOGPUGL
2024-05-19 21:27 ` [PATCH v12 10/13] virtio-gpu: Move fence_poll timer to VirtIOGPUGL Dmitry Osipenko
@ 2024-05-20 3:51 ` Akihiko Odaki
2024-05-22 0:03 ` Dmitry Osipenko
0 siblings, 1 reply; 34+ messages in thread
From: Akihiko Odaki @ 2024-05-20 3:51 UTC (permalink / raw)
To: Dmitry Osipenko, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 2024/05/20 6:27, Dmitry Osipenko wrote:
> Move fence_poll timer to VirtIOGPUGL for consistency with cmdq_resume_bh
> that are used only by GL device.
>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Thanks for refacotoring.
Please move this before "[PATCH v12 01/13] virtio-gpu: Unrealize GL
device" so that you don't have to rewrite code introduced by that patch.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v12 10/13] virtio-gpu: Move fence_poll timer to VirtIOGPUGL
2024-05-20 3:51 ` Akihiko Odaki
@ 2024-05-22 0:03 ` Dmitry Osipenko
0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-22 0:03 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 5/20/24 06:51, Akihiko Odaki wrote:
> On 2024/05/20 6:27, Dmitry Osipenko wrote:
>> Move fence_poll timer to VirtIOGPUGL for consistency with cmdq_resume_bh
>> that are used only by GL device.
>>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>
> Thanks for refacotoring.
>
> Please move this before "[PATCH v12 01/13] virtio-gpu: Unrealize GL
> device" so that you don't have to rewrite code introduced by that patch.
I'll improve it all in v13, thank you for the review
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v12 11/13] virtio-gpu: Move print_stats timer to VirtIOGPUGL
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (9 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 10/13] virtio-gpu: Move fence_poll timer to VirtIOGPUGL Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-19 21:27 ` [PATCH v12 12/13] virtio-gpu: Register capsets dynamically Dmitry Osipenko
` (2 subsequent siblings)
13 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Move print_stats timer to VirtIOGPUGL for consistency with
cmdq_resume_bh and fence_poll that are used only by GL device.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-virgl.c | 12 +++++++-----
include/hw/virtio/virtio-gpu.h | 2 +-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index c8b25a0f5d7c..a41c4f8e1cef 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -1069,6 +1069,7 @@ static struct virgl_renderer_callbacks virtio_gpu_3d_cbs = {
static void virtio_gpu_print_stats(void *opaque)
{
VirtIOGPU *g = opaque;
+ VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
if (g->stats.requests) {
fprintf(stderr, "stats: vq req %4d, %3d -- 3D %4d (%5d)\n",
@@ -1083,7 +1084,7 @@ static void virtio_gpu_print_stats(void *opaque)
} else {
fprintf(stderr, "stats: idle\r");
}
- timer_mod(g->print_stats, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 1000);
+ timer_mod(gl->print_stats, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 1000);
}
static void virtio_gpu_fence_poll(void *opaque)
@@ -1146,9 +1147,10 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
virtio_gpu_fence_poll, g);
if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
- g->print_stats = timer_new_ms(QEMU_CLOCK_VIRTUAL,
- virtio_gpu_print_stats, g);
- timer_mod(g->print_stats, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 1000);
+ gl->print_stats = timer_new_ms(QEMU_CLOCK_VIRTUAL,
+ virtio_gpu_print_stats, g);
+ timer_mod(gl->print_stats,
+ qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 1000);
}
gl->cmdq_resume_bh = aio_bh_new(qemu_get_aio_context(),
@@ -1175,7 +1177,7 @@ void virtio_gpu_virgl_deinit(VirtIOGPU *g)
qemu_bh_delete(gl->cmdq_resume_bh);
if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
- timer_free(g->print_stats);
+ timer_free(gl->print_stats);
}
timer_free(gl->fence_poll);
virgl_renderer_cleanup(NULL);
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 529c34481158..aea559cdacc5 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -195,7 +195,6 @@ struct VirtIOGPU {
uint64_t hostmem;
bool processing_cmdq;
- QEMUTimer *print_stats;
uint32_t inflight;
struct {
@@ -233,6 +232,7 @@ struct VirtIOGPUGL {
QEMUBH *cmdq_resume_bh;
QEMUTimer *fence_poll;
+ QEMUTimer *print_stats;
};
struct VhostUserGPU {
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH v12 12/13] virtio-gpu: Register capsets dynamically
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (10 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 11/13] virtio-gpu: Move print_stats " Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-23 7:12 ` Manos Pitsidianakis
2024-05-19 21:27 ` [PATCH v12 13/13] virtio-gpu: Support Venus context Dmitry Osipenko
2024-05-21 13:15 ` [PATCH v12 00/13] Support blob memory and venus on qemu Alex Bennée
13 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
virtio_gpu_virgl_get_num_capsets will return "num_capsets", but we can't
assume that capset_index 1 is always VIRGL2 once we'll support more capsets,
like Venus and DRM capsets. Register capsets dynamically to avoid that problem.
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-gl.c | 6 ++++--
hw/display/virtio-gpu-virgl.c | 33 +++++++++++++++++++++------------
include/hw/virtio/virtio-gpu.h | 4 +++-
3 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index 4d0a10070ab3..b8f395be8d2d 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -135,8 +135,8 @@ static void virtio_gpu_gl_device_realize(DeviceState *qdev, Error **errp)
}
g->parent_obj.conf.flags |= (1 << VIRTIO_GPU_FLAG_VIRGL_ENABLED);
- VIRTIO_GPU_BASE(g)->virtio_config.num_capsets =
- virtio_gpu_virgl_get_num_capsets(g);
+ g->capset_ids = virtio_gpu_virgl_get_capsets(g);
+ VIRTIO_GPU_BASE(g)->virtio_config.num_capsets = g->capset_ids->len;
#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
g->parent_obj.conf.flags |= 1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED;
@@ -159,6 +159,8 @@ static void virtio_gpu_gl_device_unrealize(DeviceState *qdev)
if (gl->renderer_inited) {
virtio_gpu_virgl_deinit(g);
}
+
+ g_array_unref(g->capset_ids);
}
static void virtio_gpu_gl_class_init(ObjectClass *klass, void *data)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index a41c4f8e1cef..70e2d28ba966 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -623,19 +623,13 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
VIRTIO_GPU_FILL_CMD(info);
memset(&resp, 0, sizeof(resp));
- if (info.capset_index == 0) {
- resp.capset_id = VIRTIO_GPU_CAPSET_VIRGL;
- virgl_renderer_get_cap_set(resp.capset_id,
- &resp.capset_max_version,
- &resp.capset_max_size);
- } else if (info.capset_index == 1) {
- resp.capset_id = VIRTIO_GPU_CAPSET_VIRGL2;
+
+ if (info.capset_index < g->capset_ids->len) {
+ resp.capset_id = g_array_index(g->capset_ids, uint32_t,
+ info.capset_index);
virgl_renderer_get_cap_set(resp.capset_id,
&resp.capset_max_version,
&resp.capset_max_size);
- } else {
- resp.capset_max_version = 0;
- resp.capset_max_size = 0;
}
resp.hdr.type = VIRTIO_GPU_RESP_OK_CAPSET_INFO;
virtio_gpu_ctrl_response(g, cmd, &resp.hdr, sizeof(resp));
@@ -1160,14 +1154,29 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
return 0;
}
-int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
+static void virtio_gpu_virgl_add_capset(GArray *capset_ids, uint32_t capset_id)
+{
+ g_array_append_val(capset_ids, capset_id);
+}
+
+GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g)
{
uint32_t capset2_max_ver, capset2_max_size;
+ GArray *capset_ids;
+
+ capset_ids = g_array_new(false, false, sizeof(uint32_t));
+
+ /* VIRGL is always supported. */
+ virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VIRGL);
+
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
&capset2_max_ver,
&capset2_max_size);
+ if (capset2_max_ver) {
+ virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VIRGL2);
+ }
- return capset2_max_ver ? 2 : 1;
+ return capset_ids;
}
void virtio_gpu_virgl_deinit(VirtIOGPU *g)
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index aea559cdacc5..7e1fee836802 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -208,6 +208,8 @@ struct VirtIOGPU {
QTAILQ_HEAD(, VGPUDMABuf) bufs;
VGPUDMABuf *primary[VIRTIO_GPU_MAX_SCANOUTS];
} dmabuf;
+
+ GArray *capset_ids;
};
struct VirtIOGPUClass {
@@ -347,6 +349,6 @@ void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g);
void virtio_gpu_virgl_reset(VirtIOGPU *g);
int virtio_gpu_virgl_init(VirtIOGPU *g);
void virtio_gpu_virgl_deinit(VirtIOGPU *g);
-int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g);
+GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g);
#endif
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH v12 12/13] virtio-gpu: Register capsets dynamically
2024-05-19 21:27 ` [PATCH v12 12/13] virtio-gpu: Register capsets dynamically Dmitry Osipenko
@ 2024-05-23 7:12 ` Manos Pitsidianakis
0 siblings, 0 replies; 34+ messages in thread
From: Manos Pitsidianakis @ 2024-05-23 7:12 UTC (permalink / raw)
To: qemu-devel, Dmitry Osipenko, Akihiko Odaki, Huang Rui,
Marc-André Lureau, Philippe Mathieu-Daudé ,
Gerd Hoffmann, Michael S . Tsirkin, Stefano Stabellini,
Antonio Caggiano, Dr . David Alan Gilbert, Robert Beckett,
Gert Wollny, Alex Benné e
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné , Alex Deucher, Stefano Stabellini,
Christian Kö nig, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On Mon, 20 May 2024 00:27, Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote:
>From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
>
>virtio_gpu_virgl_get_num_capsets will return "num_capsets", but we can't
>assume that capset_index 1 is always VIRGL2 once we'll support more capsets,
>like Venus and DRM capsets. Register capsets dynamically to avoid that problem.
>
>Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
>Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>---
> hw/display/virtio-gpu-gl.c | 6 ++++--
> hw/display/virtio-gpu-virgl.c | 33 +++++++++++++++++++++------------
> include/hw/virtio/virtio-gpu.h | 4 +++-
> 3 files changed, 28 insertions(+), 15 deletions(-)
>
>diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
>index 4d0a10070ab3..b8f395be8d2d 100644
>--- a/hw/display/virtio-gpu-gl.c
>+++ b/hw/display/virtio-gpu-gl.c
>@@ -135,8 +135,8 @@ static void virtio_gpu_gl_device_realize(DeviceState *qdev, Error **errp)
> }
>
> g->parent_obj.conf.flags |= (1 << VIRTIO_GPU_FLAG_VIRGL_ENABLED);
>- VIRTIO_GPU_BASE(g)->virtio_config.num_capsets =
>- virtio_gpu_virgl_get_num_capsets(g);
>+ g->capset_ids = virtio_gpu_virgl_get_capsets(g);
>+ VIRTIO_GPU_BASE(g)->virtio_config.num_capsets = g->capset_ids->len;
>
> #ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
> g->parent_obj.conf.flags |= 1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED;
>@@ -159,6 +159,8 @@ static void virtio_gpu_gl_device_unrealize(DeviceState *qdev)
> if (gl->renderer_inited) {
> virtio_gpu_virgl_deinit(g);
> }
>+
>+ g_array_unref(g->capset_ids);
> }
>
> static void virtio_gpu_gl_class_init(ObjectClass *klass, void *data)
>diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
>index a41c4f8e1cef..70e2d28ba966 100644
>--- a/hw/display/virtio-gpu-virgl.c
>+++ b/hw/display/virtio-gpu-virgl.c
>@@ -623,19 +623,13 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
> VIRTIO_GPU_FILL_CMD(info);
>
> memset(&resp, 0, sizeof(resp));
>- if (info.capset_index == 0) {
>- resp.capset_id = VIRTIO_GPU_CAPSET_VIRGL;
>- virgl_renderer_get_cap_set(resp.capset_id,
>- &resp.capset_max_version,
>- &resp.capset_max_size);
>- } else if (info.capset_index == 1) {
>- resp.capset_id = VIRTIO_GPU_CAPSET_VIRGL2;
>+
>+ if (info.capset_index < g->capset_ids->len) {
>+ resp.capset_id = g_array_index(g->capset_ids, uint32_t,
>+ info.capset_index);
> virgl_renderer_get_cap_set(resp.capset_id,
> &resp.capset_max_version,
> &resp.capset_max_size);
>- } else {
>- resp.capset_max_version = 0;
>- resp.capset_max_size = 0;
> }
> resp.hdr.type = VIRTIO_GPU_RESP_OK_CAPSET_INFO;
> virtio_gpu_ctrl_response(g, cmd, &resp.hdr, sizeof(resp));
>@@ -1160,14 +1154,29 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> return 0;
> }
>
>-int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
>+static void virtio_gpu_virgl_add_capset(GArray *capset_ids, uint32_t capset_id)
>+{
>+ g_array_append_val(capset_ids, capset_id);
>+}
>+
>+GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g)
> {
> uint32_t capset2_max_ver, capset2_max_size;
>+ GArray *capset_ids;
>+
>+ capset_ids = g_array_new(false, false, sizeof(uint32_t));
>+
>+ /* VIRGL is always supported. */
>+ virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VIRGL);
>+
> virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
> &capset2_max_ver,
> &capset2_max_size);
>+ if (capset2_max_ver) {
>+ virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VIRGL2);
>+ }
>
>- return capset2_max_ver ? 2 : 1;
>+ return capset_ids;
> }
>
> void virtio_gpu_virgl_deinit(VirtIOGPU *g)
>diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
>index aea559cdacc5..7e1fee836802 100644
>--- a/include/hw/virtio/virtio-gpu.h
>+++ b/include/hw/virtio/virtio-gpu.h
>@@ -208,6 +208,8 @@ struct VirtIOGPU {
> QTAILQ_HEAD(, VGPUDMABuf) bufs;
> VGPUDMABuf *primary[VIRTIO_GPU_MAX_SCANOUTS];
> } dmabuf;
>+
>+ GArray *capset_ids;
> };
>
> struct VirtIOGPUClass {
>@@ -347,6 +349,6 @@ void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g);
> void virtio_gpu_virgl_reset(VirtIOGPU *g);
> int virtio_gpu_virgl_init(VirtIOGPU *g);
> void virtio_gpu_virgl_deinit(VirtIOGPU *g);
>-int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g);
>+GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g);
>
> #endif
>--
>2.44.0
>
>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v12 13/13] virtio-gpu: Support Venus context
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (11 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 12/13] virtio-gpu: Register capsets dynamically Dmitry Osipenko
@ 2024-05-19 21:27 ` Dmitry Osipenko
2024-05-23 7:18 ` Manos Pitsidianakis
2024-05-21 13:15 ` [PATCH v12 00/13] Support blob memory and venus on qemu Alex Bennée
13 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-19 21:27 UTC (permalink / raw)
To: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, Alex Bennée
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné, Alex Deucher, Stefano Stabellini,
Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
From: Antonio Caggiano <antonio.caggiano@collabora.com>
Request Venus when initializing VirGL and if venus=true flag is set for
virtio-gpu-gl device.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
hw/display/virtio-gpu-gl.c | 2 ++
hw/display/virtio-gpu-virgl.c | 22 ++++++++++++++++++----
hw/display/virtio-gpu.c | 13 +++++++++++++
include/hw/virtio/virtio-gpu.h | 3 +++
meson.build | 1 +
5 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index b8f395be8d2d..2078e74050bb 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -148,6 +148,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_BIT("venus", VirtIOGPU, parent_obj.conf.flags,
+ VIRTIO_GPU_FLAG_VENUS_ENABLED, false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 70e2d28ba966..2e9862dd186a 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -1130,6 +1130,11 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
flags |= VIRGL_RENDERER_D3D11_SHARE_TEXTURE;
}
#endif
+#ifdef VIRGL_RENDERER_VENUS
+ if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
+ flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
+ }
+#endif
ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
if (ret != 0) {
@@ -1161,7 +1166,7 @@ static void virtio_gpu_virgl_add_capset(GArray *capset_ids, uint32_t capset_id)
GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g)
{
- uint32_t capset2_max_ver, capset2_max_size;
+ uint32_t capset_max_ver, capset_max_size;
GArray *capset_ids;
capset_ids = g_array_new(false, false, sizeof(uint32_t));
@@ -1170,12 +1175,21 @@ GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g)
virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VIRGL);
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
- &capset2_max_ver,
- &capset2_max_size);
- if (capset2_max_ver) {
+ &capset_max_ver,
+ &capset_max_size);
+ if (capset_max_ver) {
virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VIRGL2);
}
+ if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
+ virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
+ &capset_max_ver,
+ &capset_max_size);
+ if (capset_max_size) {
+ virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VENUS);
+ }
+ }
+
return capset_ids;
}
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 052ab493a00b..0518bb858e88 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1491,6 +1491,19 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp)
#endif
}
+ if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
+#ifdef HAVE_VIRGL_VENUS
+ if (!virtio_gpu_blob_enabled(g->parent_obj.conf) ||
+ !virtio_gpu_hostmem_enabled(g->parent_obj.conf)) {
+ error_setg(errp, "venus requires enabled blob and hostmem options");
+ return;
+ }
+#else
+ error_setg(errp, "old virglrenderer, venus unsupported");
+ return;
+#endif
+ }
+
if (!virtio_gpu_base_device_realize(qdev,
virtio_gpu_handle_ctrl_cb,
virtio_gpu_handle_cursor_cb,
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 7e1fee836802..ec5d7517f141 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -99,6 +99,7 @@ enum virtio_gpu_base_conf_flags {
VIRTIO_GPU_FLAG_BLOB_ENABLED,
VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED,
VIRTIO_GPU_FLAG_RUTABAGA_ENABLED,
+ VIRTIO_GPU_FLAG_VENUS_ENABLED,
};
#define virtio_gpu_virgl_enabled(_cfg) \
@@ -117,6 +118,8 @@ enum virtio_gpu_base_conf_flags {
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_RUTABAGA_ENABLED))
#define virtio_gpu_hostmem_enabled(_cfg) \
(_cfg.hostmem > 0)
+#define virtio_gpu_venus_enabled(_cfg) \
+ (_cfg.flags & (1 << VIRTIO_GPU_FLAG_VENUS_ENABLED))
struct virtio_gpu_base_conf {
uint32_t max_outputs;
diff --git a/meson.build b/meson.build
index 503a7736eda0..5a2b7b660c67 100644
--- a/meson.build
+++ b/meson.build
@@ -2305,6 +2305,7 @@ if virgl.version().version_compare('>=1.0.0')
config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
config_host_data.set('HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS', 1)
config_host_data.set('HAVE_VIRGL_RESOURCE_BLOB', 1)
+ config_host_data.set('HAVE_VIRGL_VENUS', 1)
endif
config_host_data.set('CONFIG_VIRTFS', have_virtfs)
config_host_data.set('CONFIG_VTE', vte.found())
--
2.44.0
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH v12 13/13] virtio-gpu: Support Venus context
2024-05-19 21:27 ` [PATCH v12 13/13] virtio-gpu: Support Venus context Dmitry Osipenko
@ 2024-05-23 7:18 ` Manos Pitsidianakis
2024-05-23 23:33 ` Dmitry Osipenko
0 siblings, 1 reply; 34+ messages in thread
From: Manos Pitsidianakis @ 2024-05-23 7:18 UTC (permalink / raw)
To: qemu-devel, Dmitry Osipenko, Akihiko Odaki, Huang Rui,
Marc-André Lureau, Philippe Mathieu-Daudé ,
Gerd Hoffmann, Michael S . Tsirkin, Stefano Stabellini,
Antonio Caggiano, Dr . David Alan Gilbert, Robert Beckett,
Gert Wollny, Alex Benné e
Cc: qemu-devel, Gurchetan Singh, ernunes, Alyssa Ross,
Roger Pau Monné , Alex Deucher, Stefano Stabellini,
Christian Kö nig, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On Mon, 20 May 2024 00:27, Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote:
>From: Antonio Caggiano <antonio.caggiano@collabora.com>
>
>Request Venus when initializing VirGL and if venus=true flag is set for
>virtio-gpu-gl device.
>
>Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
>Signed-off-by: Huang Rui <ray.huang@amd.com>
>Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>---
> hw/display/virtio-gpu-gl.c | 2 ++
> hw/display/virtio-gpu-virgl.c | 22 ++++++++++++++++++----
> hw/display/virtio-gpu.c | 13 +++++++++++++
> include/hw/virtio/virtio-gpu.h | 3 +++
> meson.build | 1 +
> 5 files changed, 37 insertions(+), 4 deletions(-)
>
>diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
>index b8f395be8d2d..2078e74050bb 100644
>--- a/hw/display/virtio-gpu-gl.c
>+++ b/hw/display/virtio-gpu-gl.c
>@@ -148,6 +148,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_BIT("venus", VirtIOGPU, parent_obj.conf.flags,
>+ VIRTIO_GPU_FLAG_VENUS_ENABLED, false),
> DEFINE_PROP_END_OF_LIST(),
> };
>
>diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
>index 70e2d28ba966..2e9862dd186a 100644
>--- a/hw/display/virtio-gpu-virgl.c
>+++ b/hw/display/virtio-gpu-virgl.c
>@@ -1130,6 +1130,11 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> flags |= VIRGL_RENDERER_D3D11_SHARE_TEXTURE;
> }
> #endif
>+#ifdef VIRGL_RENDERER_VENUS
>+ if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
>+ flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
>+ }
>+#endif
>
> ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
> if (ret != 0) {
>@@ -1161,7 +1166,7 @@ static void virtio_gpu_virgl_add_capset(GArray *capset_ids, uint32_t capset_id)
>
> GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g)
> {
>- uint32_t capset2_max_ver, capset2_max_size;
>+ uint32_t capset_max_ver, capset_max_size;
> GArray *capset_ids;
>
> capset_ids = g_array_new(false, false, sizeof(uint32_t));
>@@ -1170,12 +1175,21 @@ GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g)
> virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VIRGL);
>
> virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
>- &capset2_max_ver,
>- &capset2_max_size);
>- if (capset2_max_ver) {
>+ &capset_max_ver,
>+ &capset_max_size);
>+ if (capset_max_ver) {
> virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VIRGL2);
> }
>
>+ if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
>+ virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
>+ &capset_max_ver,
>+ &capset_max_size);
>+ if (capset_max_size) {
>+ virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_VENUS);
>+ }
>+ }
>+
> return capset_ids;
> }
>
>diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
>index 052ab493a00b..0518bb858e88 100644
>--- a/hw/display/virtio-gpu.c
>+++ b/hw/display/virtio-gpu.c
>@@ -1491,6 +1491,19 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp)
> #endif
> }
>
>+ if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
>+#ifdef HAVE_VIRGL_VENUS
>+ if (!virtio_gpu_blob_enabled(g->parent_obj.conf) ||
>+ !virtio_gpu_hostmem_enabled(g->parent_obj.conf)) {
>+ error_setg(errp, "venus requires enabled blob and hostmem options");
>+ return;
>+ }
>+#else
>+ error_setg(errp, "old virglrenderer, venus unsupported");
>+ return;
>+#endif
>+ }
>+
> if (!virtio_gpu_base_device_realize(qdev,
> virtio_gpu_handle_ctrl_cb,
> virtio_gpu_handle_cursor_cb,
>diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
>index 7e1fee836802..ec5d7517f141 100644
>--- a/include/hw/virtio/virtio-gpu.h
>+++ b/include/hw/virtio/virtio-gpu.h
>@@ -99,6 +99,7 @@ enum virtio_gpu_base_conf_flags {
> VIRTIO_GPU_FLAG_BLOB_ENABLED,
> VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED,
> VIRTIO_GPU_FLAG_RUTABAGA_ENABLED,
>+ VIRTIO_GPU_FLAG_VENUS_ENABLED,
> };
>
> #define virtio_gpu_virgl_enabled(_cfg) \
>@@ -117,6 +118,8 @@ enum virtio_gpu_base_conf_flags {
> (_cfg.flags & (1 << VIRTIO_GPU_FLAG_RUTABAGA_ENABLED))
> #define virtio_gpu_hostmem_enabled(_cfg) \
> (_cfg.hostmem > 0)
>+#define virtio_gpu_venus_enabled(_cfg) \
>+ (_cfg.flags & (1 << VIRTIO_GPU_FLAG_VENUS_ENABLED))
>
Can we have both venus and rutabaga enabled on the same virtio-gpu
device? How would that work? It seems to me they should be mutually
exclusive.
> struct virtio_gpu_base_conf {
> uint32_t max_outputs;
>diff --git a/meson.build b/meson.build
>index 503a7736eda0..5a2b7b660c67 100644
>--- a/meson.build
>+++ b/meson.build
>@@ -2305,6 +2305,7 @@ if virgl.version().version_compare('>=1.0.0')
> config_host_data.set('HAVE_VIRGL_D3D_INFO_EXT', 1)
> config_host_data.set('HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS', 1)
> config_host_data.set('HAVE_VIRGL_RESOURCE_BLOB', 1)
>+ config_host_data.set('HAVE_VIRGL_VENUS', 1)
> endif
> config_host_data.set('CONFIG_VIRTFS', have_virtfs)
> config_host_data.set('CONFIG_VTE', vte.found())
>--
>2.44.0
>
>
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH v12 13/13] virtio-gpu: Support Venus context
2024-05-23 7:18 ` Manos Pitsidianakis
@ 2024-05-23 23:33 ` Dmitry Osipenko
0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-23 23:33 UTC (permalink / raw)
To: Manos Pitsidianakis, qemu-devel, Akihiko Odaki, Huang Rui,
Marc-Andr é Lureau, Philippe Mathieu-Daud é,
Gerd Hoffmann, Michael S . Tsirkin, Stefano Stabellini,
Antonio Caggiano, Dr . David Alan Gilbert, Robert Beckett,
Gert Wollny, Alex Benn é e
Cc: Gurchetan Singh, ernunes, Alyssa Ross, Roger Pau Monn é,
Alex Deucher, Stefano Stabellini, Christian K ö nig,
Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang,
Julia Zhang, Chen Jiqian, Yiwei Zhang
On 5/23/24 10:18, Manos Pitsidianakis wrote:
>> #define virtio_gpu_hostmem_enabled(_cfg) \
>> (_cfg.hostmem > 0)
>> +#define virtio_gpu_venus_enabled(_cfg) \
>> + (_cfg.flags & (1 << VIRTIO_GPU_FLAG_VENUS_ENABLED))
>>
>
> Can we have both venus and rutabaga enabled on the same virtio-gpu
> device? How would that work? It seems to me they should be mutually
> exclusive.
virtio-gpu-gl and virtio-gpu-rutabaga are separate device types. You
can't enable venus for rutabaga device because it doesn't support venus
and vice versa, Qemu will tell you that flag is invalid.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-05-19 21:26 [PATCH v12 00/13] Support blob memory and venus on qemu Dmitry Osipenko
` (12 preceding siblings ...)
2024-05-19 21:27 ` [PATCH v12 13/13] virtio-gpu: Support Venus context Dmitry Osipenko
@ 2024-05-21 13:15 ` Alex Bennée
2024-05-21 14:57 ` Alex Bennée
13 siblings, 1 reply; 34+ messages in thread
From: Alex Bennée @ 2024-05-21 13:15 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> Hello,
>
> This series enables Vulkan Venus context support on virtio-gpu.
>
> All virglrender and almost all Linux kernel prerequisite changes
> needed by Venus are already in upstream. For kernel there is a pending
> KVM patchset that fixes mapping of compound pages needed for DRM drivers
> using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error
> from Qemu.
>
> [1] https://lore.kernel.org/kvm/20240229025759.1187910-1-stevensd@google.com/
>
> You'll need to use recent Mesa version containing patch that removes
> dependency on cross-device feature from Venus that isn't supported by
> Qemu [2].
>
> [2] https://gitlab.freedesktop.org/mesa/mesa/-/commit/087e9a96d13155e26987befae78b6ccbb7ae242b
>
> Example Qemu cmdline that enables Venus:
>
> qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=true,venus=true \
> -machine q35,accel=kvm,memory-backend=mem1 \
> -object memory-backend-memfd,id=mem1,size=8G -m 8G
What is the correct device for non-x86 guests? We have virtio-gpu-gl-pci
but when doing that I get:
-device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true
qemu-system-aarch64: -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true: opengl is not available
According to 37f86af087 (virtio-gpu: move virgl realize + properties):
Drop the virgl property, the virtio-gpu-gl-device has virgl enabled no
matter what. Just use virtio-gpu-device instead if you don't want
enable virgl and opengl. This simplifies the logic and reduces the test
matrix.
but that's not a good solution because that needs virtio-mmio and there
are reasons to have a PCI device (for one thing no ambiguity about
discovery).
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-05-21 13:15 ` [PATCH v12 00/13] Support blob memory and venus on qemu Alex Bennée
@ 2024-05-21 14:57 ` Alex Bennée
2024-05-22 0:02 ` Dmitry Osipenko
0 siblings, 1 reply; 34+ messages in thread
From: Alex Bennée @ 2024-05-21 14:57 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Alex Bennée <alex.bennee@linaro.org> writes:
> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>
>> Hello,
>>
>> This series enables Vulkan Venus context support on virtio-gpu.
>>
>> All virglrender and almost all Linux kernel prerequisite changes
>> needed by Venus are already in upstream. For kernel there is a pending
>> KVM patchset that fixes mapping of compound pages needed for DRM drivers
>> using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error
>> from Qemu.
>>
>> [1] https://lore.kernel.org/kvm/20240229025759.1187910-1-stevensd@google.com/
>>
>> You'll need to use recent Mesa version containing patch that removes
>> dependency on cross-device feature from Venus that isn't supported by
>> Qemu [2].
>>
>> [2] https://gitlab.freedesktop.org/mesa/mesa/-/commit/087e9a96d13155e26987befae78b6ccbb7ae242b
>>
>> Example Qemu cmdline that enables Venus:
>>
>> qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=true,venus=true \
>> -machine q35,accel=kvm,memory-backend=mem1 \
>> -object memory-backend-memfd,id=mem1,size=8G -m 8G
>
> What is the correct device for non-x86 guests? We have virtio-gpu-gl-pci
> but when doing that I get:
>
> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true
> qemu-system-aarch64: -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true: opengl is not available
>
> According to 37f86af087 (virtio-gpu: move virgl realize + properties):
>
> Drop the virgl property, the virtio-gpu-gl-device has virgl enabled no
> matter what. Just use virtio-gpu-device instead if you don't want
> enable virgl and opengl. This simplifies the logic and reduces the test
> matrix.
>
> but that's not a good solution because that needs virtio-mmio and there
> are reasons to have a PCI device (for one thing no ambiguity about
> discovery).
Oops my mistake forgetting:
--display gtk,gl=on
Although I do see a lot of eglMakeContext failures.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-05-21 14:57 ` Alex Bennée
@ 2024-05-22 0:02 ` Dmitry Osipenko
2024-05-22 9:00 ` Alex Bennée
0 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-22 0:02 UTC (permalink / raw)
To: Alex Bennée
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 5/21/24 17:57, Alex Bennée wrote:
> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>
>>> Hello,
>>>
>>> This series enables Vulkan Venus context support on virtio-gpu.
>>>
>>> All virglrender and almost all Linux kernel prerequisite changes
>>> needed by Venus are already in upstream. For kernel there is a pending
>>> KVM patchset that fixes mapping of compound pages needed for DRM drivers
>>> using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error
>>> from Qemu.
>>>
>>> [1] https://lore.kernel.org/kvm/20240229025759.1187910-1-stevensd@google.com/
>>>
>>> You'll need to use recent Mesa version containing patch that removes
>>> dependency on cross-device feature from Venus that isn't supported by
>>> Qemu [2].
>>>
>>> [2] https://gitlab.freedesktop.org/mesa/mesa/-/commit/087e9a96d13155e26987befae78b6ccbb7ae242b
>>>
>>> Example Qemu cmdline that enables Venus:
>>>
>>> qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=true,venus=true \
>>> -machine q35,accel=kvm,memory-backend=mem1 \
>>> -object memory-backend-memfd,id=mem1,size=8G -m 8G
>>
>> What is the correct device for non-x86 guests? We have virtio-gpu-gl-pci
>> but when doing that I get:
>>
>> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true
>> qemu-system-aarch64: -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true: opengl is not available
>>
>> According to 37f86af087 (virtio-gpu: move virgl realize + properties):
>>
>> Drop the virgl property, the virtio-gpu-gl-device has virgl enabled no
>> matter what. Just use virtio-gpu-device instead if you don't want
>> enable virgl and opengl. This simplifies the logic and reduces the test
>> matrix.
>>
>> but that's not a good solution because that needs virtio-mmio and there
>> are reasons to have a PCI device (for one thing no ambiguity about
>> discovery).
>
> Oops my mistake forgetting:
>
> --display gtk,gl=on
>
> Although I do see a lot of eglMakeContext failures.
Please post the full Qemu cmdline you're using
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-05-22 0:02 ` Dmitry Osipenko
@ 2024-05-22 9:00 ` Alex Bennée
2024-05-26 23:46 ` Dmitry Osipenko
2024-05-27 0:07 ` Dmitry Osipenko
0 siblings, 2 replies; 34+ messages in thread
From: Alex Bennée @ 2024-05-22 9:00 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> On 5/21/24 17:57, Alex Bennée wrote:
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>>
>>>> Hello,
>>>>
>>>> This series enables Vulkan Venus context support on virtio-gpu.
>>>>
>>>> All virglrender and almost all Linux kernel prerequisite changes
>>>> needed by Venus are already in upstream. For kernel there is a pending
>>>> KVM patchset that fixes mapping of compound pages needed for DRM drivers
>>>> using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error
>>>> from Qemu.
>>>>
>>>> [1] https://lore.kernel.org/kvm/20240229025759.1187910-1-stevensd@google.com/
>>>>
>>>> You'll need to use recent Mesa version containing patch that removes
>>>> dependency on cross-device feature from Venus that isn't supported by
>>>> Qemu [2].
>>>>
>>>> [2] https://gitlab.freedesktop.org/mesa/mesa/-/commit/087e9a96d13155e26987befae78b6ccbb7ae242b
>>>>
>>>> Example Qemu cmdline that enables Venus:
>>>>
>>>> qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=true,venus=true \
>>>> -machine q35,accel=kvm,memory-backend=mem1 \
>>>> -object memory-backend-memfd,id=mem1,size=8G -m 8G
>>>
>>> What is the correct device for non-x86 guests? We have virtio-gpu-gl-pci
>>> but when doing that I get:
>>>
>>> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true
>>> qemu-system-aarch64: -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true: opengl is not available
>>>
>>> According to 37f86af087 (virtio-gpu: move virgl realize + properties):
>>>
>>> Drop the virgl property, the virtio-gpu-gl-device has virgl enabled no
>>> matter what. Just use virtio-gpu-device instead if you don't want
>>> enable virgl and opengl. This simplifies the logic and reduces the test
>>> matrix.
>>>
>>> but that's not a good solution because that needs virtio-mmio and there
>>> are reasons to have a PCI device (for one thing no ambiguity about
>>> discovery).
>>
>> Oops my mistake forgetting:
>>
>> --display gtk,gl=on
>>
>> Although I do see a lot of eglMakeContext failures.
>
> Please post the full Qemu cmdline you're using
With:
./qemu-system-aarch64 \
-machine type=virt,virtualization=on,pflash0=rom,pflash1=efivars \
-cpu neoverse-n1 \
-smp 4 \
-accel tcg \
-device virtio-net-pci,netdev=unet \
-device virtio-scsi-pci \
-device scsi-hd,drive=hd \
-netdev user,id=unet,hostfwd=tcp::2222-:22 \
-blockdev driver=raw,node-name=hd,file.driver=host_device,file.filename=/dev/zen-ssd2/trixie-arm64,discard=unmap \
-serial mon:stdio \
-blockdev node-name=rom,driver=file,filename=(pwd)/pc-bios/edk2-aarch64-code.fd,read-only=true \
-blockdev node-name=efivars,driver=file,filename=$HOME/images/qemu-arm64-efivars \
-m 8192 \
-object memory-backend-memfd,id=mem,size=8G,share=on \
-device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true \
-display gtk,gl=on,show-cursor=on -vga none \
-device qemu-xhci -device usb-kbd -device usb-tablet
I get a boot up with a lot of:
(qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
(qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
(qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
(qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
In the guest I run:
meson devenv -C /root/lsrc/graphics/mesa.git/build fish
to bring in the latest Mesa (with virtio enabled). Running vulkaninfo
reports two cards:
==========
VULKANINFO
==========
Vulkan Instance Version: 1.3.280
Instance Extensions: count = 14
-------------------------------
VK_EXT_debug_report : extension revision 10
VK_EXT_debug_utils : extension revision 2
VK_EXT_headless_surface : extension revision 1
VK_KHR_device_group_creation : extension revision 1
VK_KHR_external_fence_capabilities : extension revision 1
VK_KHR_external_memory_capabilities : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2 : extension revision 1
VK_KHR_portability_enumeration : extension revision 1
VK_KHR_surface : extension revision 25
VK_KHR_surface_protected_capabilities : extension revision 1
VK_KHR_wayland_surface : extension revision 6
VK_LUNARG_direct_driver_loading : extension revision 1
Instance Layers: count = 2
--------------------------
VK_LAYER_MESA_device_select Linux device selection layer 1.3.211 version 1
VK_LAYER_MESA_overlay Mesa Overlay layer 1.3.211
version 1
Devices:
========
GPU0:
apiVersion = 1.3.230
driverVersion = 24.1.99
vendorID = 0x8086
deviceID = 0xa780
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = Virtio-GPU Venus (Intel(R) Graphics (RPL-S))
driverID = DRIVER_ID_MESA_VENUS
driverName = venus
driverInfo = Mesa 24.2.0-devel (git-0b582449f0)
conformanceVersion = 1.3.0.0
deviceUUID = 29d2e940-a1a0-3054-0f9a-9f7dec52a084
driverUUID = 3694c390-f245-612a-12ce-7d3a99127622
GPU1:
apiVersion = 1.2.0
driverVersion = 24.1.99
vendorID = 0x10005
deviceID = 0x0000
deviceType = PHYSICAL_DEVICE_TYPE_CPU
deviceName = Virtio-GPU Venus (llvmpipe (LLVM 15.0.6, 256 bits))
driverID = DRIVER_ID_MESA_VENUS
driverName = venus
driverInfo = Mesa 24.2.0-devel (git-0b582449f0)
conformanceVersion = 1.3.0.0
deviceUUID = 5fb5c03f-c537-f0fe-a7e6-9cd5866acb8d
driverUUID = 3694c390-f245-612a-12ce-7d3a99127622
Running weston and then vkcube-wayland reports its selecting "GPU 0:
Virtio-GPU Venus (Intel(R) Graphics (RPL-S))" but otherwise produces no
output.
If I run with "-display sdl,gl=on,show-cursor=on" and the same other
command line options the results for vulkaninfo are the same. However
vkcube-wayland gets a little further and draws the initial cube on the
screen before locking up with:
MESA-VIRTIO: debug: stuck in fence wait with iter at xxxx
where xxxx grows each time it prints. On shutting down I see some virgl
errors interspersed with the systemd logs:
[drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
[ OK ] Stopped systemd-logind.service - User Login Management.
virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
[ 475.257111] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
[drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
[ OK ] Stopped target network-online.target - Network is Online.
[ OK ] Stopped target remote-fs.target - Remote File Systems.
[ OK ] Stopped NetworkManager-wait-online…vice - Network Manager Wait Online.
Stopping avahi-daemon.service - Avahi mDNS/DNS-SD Stack...
Stopping cups.service - CUPS Scheduler...
Stopping user-runtime-dir@0.servic…er Runtime Directory /run/user/0...
[ OK ] Stopped avahi-daemon.service - Avahi mDNS/DNS-SD Stack.
[ OK ] Stopped cups.service - CUPS Scheduler.
virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
[ 475.357543] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
[drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
[ OK ] Stopped target network.target - Network.
[ OK ] Stopped target nss-user-lookup.target - User and Group Name Lookups.
Stopping NetworkManager.service - Network Manager...
Stopping networking.service - Raise network interfaces...
Stopping wpa_supplicant.service - WPA supplicant...
[ OK ] Stopped wpa_supplicant.service - WPA supplicant.
virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
[ 493.585261] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
[drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-05-22 9:00 ` Alex Bennée
@ 2024-05-26 23:46 ` Dmitry Osipenko
2024-05-27 0:52 ` Dmitry Osipenko
2024-06-05 14:47 ` Alex Bennée
2024-05-27 0:07 ` Dmitry Osipenko
1 sibling, 2 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-26 23:46 UTC (permalink / raw)
To: Alex Bennée
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 5/22/24 12:00, Alex Bennée wrote:
> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>
>> On 5/21/24 17:57, Alex Bennée wrote:
>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>
>>>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> This series enables Vulkan Venus context support on virtio-gpu.
>>>>>
>>>>> All virglrender and almost all Linux kernel prerequisite changes
>>>>> needed by Venus are already in upstream. For kernel there is a pending
>>>>> KVM patchset that fixes mapping of compound pages needed for DRM drivers
>>>>> using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error
>>>>> from Qemu.
>>>>>
>>>>> [1] https://lore.kernel.org/kvm/20240229025759.1187910-1-stevensd@google.com/
>>>>>
>>>>> You'll need to use recent Mesa version containing patch that removes
>>>>> dependency on cross-device feature from Venus that isn't supported by
>>>>> Qemu [2].
>>>>>
>>>>> [2] https://gitlab.freedesktop.org/mesa/mesa/-/commit/087e9a96d13155e26987befae78b6ccbb7ae242b
>>>>>
>>>>> Example Qemu cmdline that enables Venus:
>>>>>
>>>>> qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=true,venus=true \
>>>>> -machine q35,accel=kvm,memory-backend=mem1 \
>>>>> -object memory-backend-memfd,id=mem1,size=8G -m 8G
>>>>
>>>> What is the correct device for non-x86 guests? We have virtio-gpu-gl-pci
>>>> but when doing that I get:
>>>>
>>>> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true
>>>> qemu-system-aarch64: -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true: opengl is not available
>>>>
>>>> According to 37f86af087 (virtio-gpu: move virgl realize + properties):
>>>>
>>>> Drop the virgl property, the virtio-gpu-gl-device has virgl enabled no
>>>> matter what. Just use virtio-gpu-device instead if you don't want
>>>> enable virgl and opengl. This simplifies the logic and reduces the test
>>>> matrix.
>>>>
>>>> but that's not a good solution because that needs virtio-mmio and there
>>>> are reasons to have a PCI device (for one thing no ambiguity about
>>>> discovery).
>>>
>>> Oops my mistake forgetting:
>>>
>>> --display gtk,gl=on
>>>
>>> Although I do see a lot of eglMakeContext failures.
>>
>> Please post the full Qemu cmdline you're using
>
> With:
>
> ./qemu-system-aarch64 \
> -machine type=virt,virtualization=on,pflash0=rom,pflash1=efivars \
> -cpu neoverse-n1 \
> -smp 4 \
> -accel tcg \
> -device virtio-net-pci,netdev=unet \
> -device virtio-scsi-pci \
> -device scsi-hd,drive=hd \
> -netdev user,id=unet,hostfwd=tcp::2222-:22 \
> -blockdev driver=raw,node-name=hd,file.driver=host_device,file.filename=/dev/zen-ssd2/trixie-arm64,discard=unmap \
> -serial mon:stdio \
> -blockdev node-name=rom,driver=file,filename=(pwd)/pc-bios/edk2-aarch64-code.fd,read-only=true \
> -blockdev node-name=efivars,driver=file,filename=$HOME/images/qemu-arm64-efivars \
> -m 8192 \
> -object memory-backend-memfd,id=mem,size=8G,share=on \
> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true \
> -display gtk,gl=on,show-cursor=on -vga none \
> -device qemu-xhci -device usb-kbd -device usb-tablet
>
> I get a boot up with a lot of:
>
>
> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>
> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>
> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>
> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>
> In the guest I run:
>
> meson devenv -C /root/lsrc/graphics/mesa.git/build fish
>
> to bring in the latest Mesa (with virtio enabled). Running vulkaninfo
> reports two cards:
>
> ==========
> VULKANINFO
> ==========
>
> Vulkan Instance Version: 1.3.280
>
>
> Instance Extensions: count = 14
> -------------------------------
> VK_EXT_debug_report : extension revision 10
> VK_EXT_debug_utils : extension revision 2
> VK_EXT_headless_surface : extension revision 1
> VK_KHR_device_group_creation : extension revision 1
> VK_KHR_external_fence_capabilities : extension revision 1
> VK_KHR_external_memory_capabilities : extension revision 1
> VK_KHR_external_semaphore_capabilities : extension revision 1
> VK_KHR_get_physical_device_properties2 : extension revision 2
> VK_KHR_get_surface_capabilities2 : extension revision 1
> VK_KHR_portability_enumeration : extension revision 1
> VK_KHR_surface : extension revision 25
> VK_KHR_surface_protected_capabilities : extension revision 1
> VK_KHR_wayland_surface : extension revision 6
> VK_LUNARG_direct_driver_loading : extension revision 1
>
> Instance Layers: count = 2
> --------------------------
> VK_LAYER_MESA_device_select Linux device selection layer 1.3.211 version 1
> VK_LAYER_MESA_overlay Mesa Overlay layer 1.3.211
> version 1
>
> Devices:
> ========
> GPU0:
> apiVersion = 1.3.230
> driverVersion = 24.1.99
> vendorID = 0x8086
> deviceID = 0xa780
> deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
> deviceName = Virtio-GPU Venus (Intel(R) Graphics (RPL-S))
> driverID = DRIVER_ID_MESA_VENUS
> driverName = venus
> driverInfo = Mesa 24.2.0-devel (git-0b582449f0)
> conformanceVersion = 1.3.0.0
> deviceUUID = 29d2e940-a1a0-3054-0f9a-9f7dec52a084
> driverUUID = 3694c390-f245-612a-12ce-7d3a99127622
> GPU1:
> apiVersion = 1.2.0
> driverVersion = 24.1.99
> vendorID = 0x10005
> deviceID = 0x0000
> deviceType = PHYSICAL_DEVICE_TYPE_CPU
> deviceName = Virtio-GPU Venus (llvmpipe (LLVM 15.0.6, 256 bits))
> driverID = DRIVER_ID_MESA_VENUS
> driverName = venus
> driverInfo = Mesa 24.2.0-devel (git-0b582449f0)
> conformanceVersion = 1.3.0.0
> deviceUUID = 5fb5c03f-c537-f0fe-a7e6-9cd5866acb8d
> driverUUID = 3694c390-f245-612a-12ce-7d3a99127622
>
> Running weston and then vkcube-wayland reports its selecting "GPU 0:
> Virtio-GPU Venus (Intel(R) Graphics (RPL-S))" but otherwise produces no
> output.
>
> If I run with "-display sdl,gl=on,show-cursor=on" and the same other
> command line options the results for vulkaninfo are the same. However
> vkcube-wayland gets a little further and draws the initial cube on the
> screen before locking up with:
>
> MESA-VIRTIO: debug: stuck in fence wait with iter at xxxx
>
> where xxxx grows each time it prints. On shutting down I see some virgl
> errors interspersed with the systemd logs:
>
> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
> [ OK ] Stopped systemd-logind.service - User Login Management.
> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
> [ 475.257111] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
> [ OK ] Stopped target network-online.target - Network is Online.
> [ OK ] Stopped target remote-fs.target - Remote File Systems.
> [ OK ] Stopped NetworkManager-wait-online…vice - Network Manager Wait Online.
> Stopping avahi-daemon.service - Avahi mDNS/DNS-SD Stack...
> Stopping cups.service - CUPS Scheduler...
> Stopping user-runtime-dir@0.servic…er Runtime Directory /run/user/0...
> [ OK ] Stopped avahi-daemon.service - Avahi mDNS/DNS-SD Stack.
> [ OK ] Stopped cups.service - CUPS Scheduler.
> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
> [ 475.357543] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
> [ OK ] Stopped target network.target - Network.
> [ OK ] Stopped target nss-user-lookup.target - User and Group Name Lookups.
> Stopping NetworkManager.service - Network Manager...
> Stopping networking.service - Raise network interfaces...
> Stopping wpa_supplicant.service - WPA supplicant...
> [ OK ] Stopped wpa_supplicant.service - WPA supplicant.
> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
> [ 493.585261] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>
I've reproduced this with qemu-system-aarch64. Vkcube works for a second
and then stops, Qemu compeltely gets frozen after closing and re-running
vkcube. Doesn't feel like this is a problem with venus, but with arm64.
For now don't know where is the bug, will take a closer look.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-05-26 23:46 ` Dmitry Osipenko
@ 2024-05-27 0:52 ` Dmitry Osipenko
2024-06-05 14:47 ` Alex Bennée
1 sibling, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-27 0:52 UTC (permalink / raw)
To: Alex Bennée
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 5/27/24 02:46, Dmitry Osipenko wrote:
> On 5/22/24 12:00, Alex Bennée wrote:
>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>
>>> On 5/21/24 17:57, Alex Bennée wrote:
>>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>>
>>>>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> This series enables Vulkan Venus context support on virtio-gpu.
>>>>>>
>>>>>> All virglrender and almost all Linux kernel prerequisite changes
>>>>>> needed by Venus are already in upstream. For kernel there is a pending
>>>>>> KVM patchset that fixes mapping of compound pages needed for DRM drivers
>>>>>> using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error
>>>>>> from Qemu.
>>>>>>
>>>>>> [1] https://lore.kernel.org/kvm/20240229025759.1187910-1-stevensd@google.com/
>>>>>>
>>>>>> You'll need to use recent Mesa version containing patch that removes
>>>>>> dependency on cross-device feature from Venus that isn't supported by
>>>>>> Qemu [2].
>>>>>>
>>>>>> [2] https://gitlab.freedesktop.org/mesa/mesa/-/commit/087e9a96d13155e26987befae78b6ccbb7ae242b
>>>>>>
>>>>>> Example Qemu cmdline that enables Venus:
>>>>>>
>>>>>> qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=true,venus=true \
>>>>>> -machine q35,accel=kvm,memory-backend=mem1 \
>>>>>> -object memory-backend-memfd,id=mem1,size=8G -m 8G
>>>>>
>>>>> What is the correct device for non-x86 guests? We have virtio-gpu-gl-pci
>>>>> but when doing that I get:
>>>>>
>>>>> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true
>>>>> qemu-system-aarch64: -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true: opengl is not available
>>>>>
>>>>> According to 37f86af087 (virtio-gpu: move virgl realize + properties):
>>>>>
>>>>> Drop the virgl property, the virtio-gpu-gl-device has virgl enabled no
>>>>> matter what. Just use virtio-gpu-device instead if you don't want
>>>>> enable virgl and opengl. This simplifies the logic and reduces the test
>>>>> matrix.
>>>>>
>>>>> but that's not a good solution because that needs virtio-mmio and there
>>>>> are reasons to have a PCI device (for one thing no ambiguity about
>>>>> discovery).
>>>>
>>>> Oops my mistake forgetting:
>>>>
>>>> --display gtk,gl=on
>>>>
>>>> Although I do see a lot of eglMakeContext failures.
>>>
>>> Please post the full Qemu cmdline you're using
>>
>> With:
>>
>> ./qemu-system-aarch64 \
>> -machine type=virt,virtualization=on,pflash0=rom,pflash1=efivars \
>> -cpu neoverse-n1 \
>> -smp 4 \
>> -accel tcg \
>> -device virtio-net-pci,netdev=unet \
>> -device virtio-scsi-pci \
>> -device scsi-hd,drive=hd \
>> -netdev user,id=unet,hostfwd=tcp::2222-:22 \
>> -blockdev driver=raw,node-name=hd,file.driver=host_device,file.filename=/dev/zen-ssd2/trixie-arm64,discard=unmap \
>> -serial mon:stdio \
>> -blockdev node-name=rom,driver=file,filename=(pwd)/pc-bios/edk2-aarch64-code.fd,read-only=true \
>> -blockdev node-name=efivars,driver=file,filename=$HOME/images/qemu-arm64-efivars \
>> -m 8192 \
>> -object memory-backend-memfd,id=mem,size=8G,share=on \
>> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true \
>> -display gtk,gl=on,show-cursor=on -vga none \
>> -device qemu-xhci -device usb-kbd -device usb-tablet
>>
>> I get a boot up with a lot of:
>>
>>
>> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>>
>> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>>
>> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>>
>> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>>
>> In the guest I run:
>>
>> meson devenv -C /root/lsrc/graphics/mesa.git/build fish
>>
>> to bring in the latest Mesa (with virtio enabled). Running vulkaninfo
>> reports two cards:
>>
>> ==========
>> VULKANINFO
>> ==========
>>
>> Vulkan Instance Version: 1.3.280
>>
>>
>> Instance Extensions: count = 14
>> -------------------------------
>> VK_EXT_debug_report : extension revision 10
>> VK_EXT_debug_utils : extension revision 2
>> VK_EXT_headless_surface : extension revision 1
>> VK_KHR_device_group_creation : extension revision 1
>> VK_KHR_external_fence_capabilities : extension revision 1
>> VK_KHR_external_memory_capabilities : extension revision 1
>> VK_KHR_external_semaphore_capabilities : extension revision 1
>> VK_KHR_get_physical_device_properties2 : extension revision 2
>> VK_KHR_get_surface_capabilities2 : extension revision 1
>> VK_KHR_portability_enumeration : extension revision 1
>> VK_KHR_surface : extension revision 25
>> VK_KHR_surface_protected_capabilities : extension revision 1
>> VK_KHR_wayland_surface : extension revision 6
>> VK_LUNARG_direct_driver_loading : extension revision 1
>>
>> Instance Layers: count = 2
>> --------------------------
>> VK_LAYER_MESA_device_select Linux device selection layer 1.3.211 version 1
>> VK_LAYER_MESA_overlay Mesa Overlay layer 1.3.211
>> version 1
>>
>> Devices:
>> ========
>> GPU0:
>> apiVersion = 1.3.230
>> driverVersion = 24.1.99
>> vendorID = 0x8086
>> deviceID = 0xa780
>> deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
>> deviceName = Virtio-GPU Venus (Intel(R) Graphics (RPL-S))
>> driverID = DRIVER_ID_MESA_VENUS
>> driverName = venus
>> driverInfo = Mesa 24.2.0-devel (git-0b582449f0)
>> conformanceVersion = 1.3.0.0
>> deviceUUID = 29d2e940-a1a0-3054-0f9a-9f7dec52a084
>> driverUUID = 3694c390-f245-612a-12ce-7d3a99127622
>> GPU1:
>> apiVersion = 1.2.0
>> driverVersion = 24.1.99
>> vendorID = 0x10005
>> deviceID = 0x0000
>> deviceType = PHYSICAL_DEVICE_TYPE_CPU
>> deviceName = Virtio-GPU Venus (llvmpipe (LLVM 15.0.6, 256 bits))
>> driverID = DRIVER_ID_MESA_VENUS
>> driverName = venus
>> driverInfo = Mesa 24.2.0-devel (git-0b582449f0)
>> conformanceVersion = 1.3.0.0
>> deviceUUID = 5fb5c03f-c537-f0fe-a7e6-9cd5866acb8d
>> driverUUID = 3694c390-f245-612a-12ce-7d3a99127622
>>
>> Running weston and then vkcube-wayland reports its selecting "GPU 0:
>> Virtio-GPU Venus (Intel(R) Graphics (RPL-S))" but otherwise produces no
>> output.
>>
>> If I run with "-display sdl,gl=on,show-cursor=on" and the same other
>> command line options the results for vulkaninfo are the same. However
>> vkcube-wayland gets a little further and draws the initial cube on the
>> screen before locking up with:
>>
>> MESA-VIRTIO: debug: stuck in fence wait with iter at xxxx
>>
>> where xxxx grows each time it prints. On shutting down I see some virgl
>> errors interspersed with the systemd logs:
>>
>> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [ OK ] Stopped systemd-logind.service - User Login Management.
>> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
>> [ 475.257111] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [ OK ] Stopped target network-online.target - Network is Online.
>> [ OK ] Stopped target remote-fs.target - Remote File Systems.
>> [ OK ] Stopped NetworkManager-wait-online…vice - Network Manager Wait Online.
>> Stopping avahi-daemon.service - Avahi mDNS/DNS-SD Stack...
>> Stopping cups.service - CUPS Scheduler...
>> Stopping user-runtime-dir@0.servic…er Runtime Directory /run/user/0...
>> [ OK ] Stopped avahi-daemon.service - Avahi mDNS/DNS-SD Stack.
>> [ OK ] Stopped cups.service - CUPS Scheduler.
>> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
>> [ 475.357543] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [ OK ] Stopped target network.target - Network.
>> [ OK ] Stopped target nss-user-lookup.target - User and Group Name Lookups.
>> Stopping NetworkManager.service - Network Manager...
>> Stopping networking.service - Raise network interfaces...
>> Stopping wpa_supplicant.service - WPA supplicant...
>> [ OK ] Stopped wpa_supplicant.service - WPA supplicant.
>> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
>> [ 493.585261] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>>
>
> I've reproduced this with qemu-system-aarch64. Vkcube works for a second
> and then stops, Qemu compeltely gets frozen after closing and re-running
> vkcube. Doesn't feel like this is a problem with venus, but with arm64.
> For now don't know where is the bug, will take a closer look.
Interestingly, on another try vkcube now works with no issues.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-05-26 23:46 ` Dmitry Osipenko
2024-05-27 0:52 ` Dmitry Osipenko
@ 2024-06-05 14:47 ` Alex Bennée
2024-06-05 16:29 ` Dmitry Osipenko
1 sibling, 1 reply; 34+ messages in thread
From: Alex Bennée @ 2024-06-05 14:47 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> On 5/22/24 12:00, Alex Bennée wrote:
>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>
>>> On 5/21/24 17:57, Alex Bennée wrote:
>>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>>
>>>>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> This series enables Vulkan Venus context support on virtio-gpu.
>>>>>>
>>>>>> All virglrender and almost all Linux kernel prerequisite changes
>>>>>> needed by Venus are already in upstream. For kernel there is a pending
>>>>>> KVM patchset that fixes mapping of compound pages needed for DRM drivers
>>>>>> using TTM [1], othewrwise hostmem blob mapping will fail with a KVM error
>>>>>> from Qemu.
>>>>>>
>>>>>> [1] https://lore.kernel.org/kvm/20240229025759.1187910-1-stevensd@google.com/
>>>>>>
>>>>>> You'll need to use recent Mesa version containing patch that removes
>>>>>> dependency on cross-device feature from Venus that isn't supported by
>>>>>> Qemu [2].
>>>>>>
>>>>>> [2] https://gitlab.freedesktop.org/mesa/mesa/-/commit/087e9a96d13155e26987befae78b6ccbb7ae242b
>>>>>>
>>>>>> Example Qemu cmdline that enables Venus:
>>>>>>
>>>>>> qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=true,venus=true \
>>>>>> -machine q35,accel=kvm,memory-backend=mem1 \
>>>>>> -object memory-backend-memfd,id=mem1,size=8G -m 8G
>>>>>
>>>>> What is the correct device for non-x86 guests? We have virtio-gpu-gl-pci
>>>>> but when doing that I get:
>>>>>
>>>>> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true
>>>>> qemu-system-aarch64: -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true: opengl is not available
>>>>>
>>>>> According to 37f86af087 (virtio-gpu: move virgl realize + properties):
>>>>>
>>>>> Drop the virgl property, the virtio-gpu-gl-device has virgl enabled no
>>>>> matter what. Just use virtio-gpu-device instead if you don't want
>>>>> enable virgl and opengl. This simplifies the logic and reduces the test
>>>>> matrix.
>>>>>
>>>>> but that's not a good solution because that needs virtio-mmio and there
>>>>> are reasons to have a PCI device (for one thing no ambiguity about
>>>>> discovery).
>>>>
>>>> Oops my mistake forgetting:
>>>>
>>>> --display gtk,gl=on
>>>>
>>>> Although I do see a lot of eglMakeContext failures.
>>>
>>> Please post the full Qemu cmdline you're using
>>
>> With:
>>
>> ./qemu-system-aarch64 \
>> -machine type=virt,virtualization=on,pflash0=rom,pflash1=efivars \
>> -cpu neoverse-n1 \
>> -smp 4 \
>> -accel tcg \
>> -device virtio-net-pci,netdev=unet \
>> -device virtio-scsi-pci \
>> -device scsi-hd,drive=hd \
>> -netdev user,id=unet,hostfwd=tcp::2222-:22 \
>> -blockdev driver=raw,node-name=hd,file.driver=host_device,file.filename=/dev/zen-ssd2/trixie-arm64,discard=unmap \
>> -serial mon:stdio \
>> -blockdev node-name=rom,driver=file,filename=(pwd)/pc-bios/edk2-aarch64-code.fd,read-only=true \
>> -blockdev node-name=efivars,driver=file,filename=$HOME/images/qemu-arm64-efivars \
>> -m 8192 \
>> -object memory-backend-memfd,id=mem,size=8G,share=on \
>> -device virtio-gpu-gl-pci,hostmem=4G,blob=true,venus=true \
>> -display gtk,gl=on,show-cursor=on -vga none \
>> -device qemu-xhci -device usb-kbd -device usb-tablet
>>
>> I get a boot up with a lot of:
>>
>>
>> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>>
>> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>>
>> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>>
>> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
>>
>> In the guest I run:
>>
>> meson devenv -C /root/lsrc/graphics/mesa.git/build fish
>>
>> to bring in the latest Mesa (with virtio enabled). Running vulkaninfo
>> reports two cards:
>>
>> ==========
>> VULKANINFO
>> ==========
>>
>> Vulkan Instance Version: 1.3.280
>>
>>
>> Instance Extensions: count = 14
>> -------------------------------
>> VK_EXT_debug_report : extension revision 10
>> VK_EXT_debug_utils : extension revision 2
>> VK_EXT_headless_surface : extension revision 1
>> VK_KHR_device_group_creation : extension revision 1
>> VK_KHR_external_fence_capabilities : extension revision 1
>> VK_KHR_external_memory_capabilities : extension revision 1
>> VK_KHR_external_semaphore_capabilities : extension revision 1
>> VK_KHR_get_physical_device_properties2 : extension revision 2
>> VK_KHR_get_surface_capabilities2 : extension revision 1
>> VK_KHR_portability_enumeration : extension revision 1
>> VK_KHR_surface : extension revision 25
>> VK_KHR_surface_protected_capabilities : extension revision 1
>> VK_KHR_wayland_surface : extension revision 6
>> VK_LUNARG_direct_driver_loading : extension revision 1
>>
>> Instance Layers: count = 2
>> --------------------------
>> VK_LAYER_MESA_device_select Linux device selection layer 1.3.211 version 1
>> VK_LAYER_MESA_overlay Mesa Overlay layer 1.3.211
>> version 1
>>
>> Devices:
>> ========
>> GPU0:
>> apiVersion = 1.3.230
>> driverVersion = 24.1.99
>> vendorID = 0x8086
>> deviceID = 0xa780
>> deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
>> deviceName = Virtio-GPU Venus (Intel(R) Graphics (RPL-S))
>> driverID = DRIVER_ID_MESA_VENUS
>> driverName = venus
>> driverInfo = Mesa 24.2.0-devel (git-0b582449f0)
>> conformanceVersion = 1.3.0.0
>> deviceUUID = 29d2e940-a1a0-3054-0f9a-9f7dec52a084
>> driverUUID = 3694c390-f245-612a-12ce-7d3a99127622
>> GPU1:
>> apiVersion = 1.2.0
>> driverVersion = 24.1.99
>> vendorID = 0x10005
>> deviceID = 0x0000
>> deviceType = PHYSICAL_DEVICE_TYPE_CPU
>> deviceName = Virtio-GPU Venus (llvmpipe (LLVM 15.0.6, 256 bits))
>> driverID = DRIVER_ID_MESA_VENUS
>> driverName = venus
>> driverInfo = Mesa 24.2.0-devel (git-0b582449f0)
>> conformanceVersion = 1.3.0.0
>> deviceUUID = 5fb5c03f-c537-f0fe-a7e6-9cd5866acb8d
>> driverUUID = 3694c390-f245-612a-12ce-7d3a99127622
>>
>> Running weston and then vkcube-wayland reports its selecting "GPU 0:
>> Virtio-GPU Venus (Intel(R) Graphics (RPL-S))" but otherwise produces no
>> output.
>>
>> If I run with "-display sdl,gl=on,show-cursor=on" and the same other
>> command line options the results for vulkaninfo are the same. However
>> vkcube-wayland gets a little further and draws the initial cube on the
>> screen before locking up with:
>>
>> MESA-VIRTIO: debug: stuck in fence wait with iter at xxxx
>>
>> where xxxx grows each time it prints. On shutting down I see some virgl
>> errors interspersed with the systemd logs:
>>
>> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [ OK ] Stopped systemd-logind.service - User Login Management.
>> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
>> [ 475.257111] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [ OK ] Stopped target network-online.target - Network is Online.
>> [ OK ] Stopped target remote-fs.target - Remote File Systems.
>> [ OK ] Stopped NetworkManager-wait-online…vice - Network Manager Wait Online.
>> Stopping avahi-daemon.service - Avahi mDNS/DNS-SD Stack...
>> Stopping cups.service - CUPS Scheduler...
>> Stopping user-runtime-dir@0.servic…er Runtime Directory /run/user/0...
>> [ OK ] Stopped avahi-daemon.service - Avahi mDNS/DNS-SD Stack.
>> [ OK ] Stopped cups.service - CUPS Scheduler.
>> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
>> [ 475.357543] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [ OK ] Stopped target network.target - Network.
>> [ OK ] Stopped target nss-user-lookup.target - User and Group Name Lookups.
>> Stopping NetworkManager.service - Network Manager...
>> Stopping networking.service - Raise network interfaces...
>> Stopping wpa_supplicant.service - WPA supplicant...
>> [ OK ] Stopped wpa_supplicant.service - WPA supplicant.
>> virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200
>> [ 493.585261] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>> [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x209)
>>
>
> I've reproduced this with qemu-system-aarch64. Vkcube works for a second
> and then stops, Qemu compeltely gets frozen after closing and re-running
> vkcube. Doesn't feel like this is a problem with venus, but with arm64.
> For now don't know where is the bug, will take a closer look.
I'm guessing some sort of resource leak, if I run vkcube-wayland in the
guest it complains about being stuck on a fence with the iterator going
up. However on the host I see:
virtio_gpu_fence_ctrl fence 0x13f1, type 0x207
virtio_gpu_fence_ctrl fence 0x13f2, type 0x207
virtio_gpu_fence_resp fence 0x13f1
virtio_gpu_fence_resp fence 0x13f2
virtio_gpu_fence_ctrl fence 0x13f3, type 0x207
virtio_gpu_fence_ctrl fence 0x13f4, type 0x207
virtio_gpu_fence_resp fence 0x13f3
virtio_gpu_fence_resp fence 0x13f4
virtio_gpu_fence_ctrl fence 0x13f5, type 0x207
virtio_gpu_fence_ctrl fence 0x13f6, type 0x207
virtio_gpu_fence_resp fence 0x13f5
virtio_gpu_fence_resp fence 0x13f6
virtio_gpu_fence_ctrl fence 0x13f7, type 0x207
virtio_gpu_fence_ctrl fence 0x13f8, type 0x207
virtio_gpu_fence_resp fence 0x13f7
virtio_gpu_fence_resp fence 0x13f8
virtio_gpu_fence_ctrl fence 0x13f9, type 0x204
virtio_gpu_fence_resp fence 0x13f9
which looks like its going ok. However when I git Ctrl-C in the guest it
kills QEMU:
virtio_gpu_fence_ctrl fence 0x13fc, type 0x207
virtio_gpu_fence_ctrl fence 0x13fd, type 0x207
virtio_gpu_fence_ctrl fence 0x13fe, type 0x204
virtio_gpu_fence_ctrl fence 0x13ff, type 0x207
virtio_gpu_fence_ctrl fence 0x1400, type 0x207
virtio_gpu_fence_resp fence 0x13fc
virtio_gpu_fence_resp fence 0x13fd
virtio_gpu_fence_resp fence 0x13fe
virtio_gpu_fence_resp fence 0x13ff
virtio_gpu_fence_resp fence 0x1400
qemu-system-aarch64: ../../subprojects/virglrenderer/src/virglrenderer.c:1282: virgl_renderer_resource_unmap: Assertion `!ret' failed.
fish: Job 1, './qemu-system-aarch64 \' terminated by signal -machine type=virt,virtuali… ( -cpu neoverse-n1 \)
fish: Job -smp 4 \, ' -accel tcg \' terminated by signal -device virtio-net-pci,netd… ( -device virtio-scsi-pci \)
fish: Job -device scsi-hd,drive=hd \, ' -netdev user,id=unet,hostfw…' terminated by signal -blockdev driver=raw,node-n… ( -serial mon:stdio \)
fish: Job -blockdev node-name=rom,dri…, ' -blockdev node-name=efivars…' terminated by signal -m 8192 \ ( -object memory-backend-memf…)
fish: Job -device virtio-gpu-gl-pci,h…, ' -display sdl,gl=on,show-cur…' terminated by signal -device qemu-xhci -device u… ( -kernel /home/alex/lsrc/lin…)
fish: Job -d guest_errors,unimp,trace…, 'SIGABRT' terminated by signal Abort ()
The backtrace (and the 18G size of the core file!) indicates a leak:
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f0fa68a9e8f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007f0fa685afb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007f0fa6845472 in __GI_abort () at ./stdlib/abort.c:79
#4 0x00007f0fa6845395 in __assert_fail_base
(fmt=0x7f0fa69b9a90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55c3e1b0762d "!ret", file=file@entry=0x55c3e1d306f0 "../../subprojects/virglrenderer/src/virglrenderer.c", line=line@entry=1282, function=function@entry=0x55c3e1d30910 <__PRETTY_FUNCTION__.2> "virgl_renderer_resource_unmap") at ./assert/assert.c:92
#5 0x00007f0fa6853eb2 in __GI___assert_fail
(assertion=assertion@entry=0x55c3e1b0762d "!ret", file=file@entry=0x55c3e1d306f0 "../../subprojects/virglrenderer/src/virglrenderer.c", line=line@entry=1282, function=function@entry=0x55c3e1d30910 <__PRETTY_FUNCTION__.2> "virgl_renderer_resource_unmap") at ./assert/assert.c:101
#6 0x000055c3e1958b50 in virgl_renderer_resource_unmap (res_handle=<optimized out>) at ../../subprojects/virglrenderer/src/virglrenderer.c:1282
#7 0x000055c3e13d8507 in virtio_gpu_virgl_unmap_resource_blob (g=g@entry=0x55c3e5fed600, res=0x55c3e6e67b60, cmd_suspended=cmd_suspended@entry=0x7ffd5d720aaf)
at ../../hw/display/virtio-gpu-virgl.c:188
#8 0x000055c3e13d9af4 in virgl_cmd_resource_unmap_blob (cmd_suspended=0x7ffd5d720aaf, cmd=0x55c3e5bd9710, g=0x55c3e5fed600) at ../../hw/display/virtio-gpu-virgl.c:797
#9 virtio_gpu_virgl_process_cmd (g=0x55c3e5fed600, cmd=0x55c3e5bd9710) at ../../hw/display/virtio-gpu-virgl.c:979
#10 0x000055c3e13d6019 in virtio_gpu_process_cmdq (g=0x55c3e5fed600) at ../../hw/display/virtio-gpu.c:1055
#11 0x000055c3e190c646 in aio_bh_poll (ctx=ctx@entry=0x55c3e4c03710) at ../../util/async.c:218
#12 0x000055c3e18f562e in aio_dispatch (ctx=0x55c3e4c03710) at ../../util/aio-posix.c:423
#13 0x000055c3e190c2ce in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../../util/async.c:360
#14 0x00007f0fa8b047a9 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x000055c3e190db78 in glib_pollfds_poll () at ../../util/main-loop.c:287
#16 os_host_main_loop_wait (timeout=1882878) at ../../util/main-loop.c:310
#17 main_loop_wait (nonblocking=nonblocking@entry=0) at ../../util/main-loop.c:589
#18 0x000055c3e1348ac9 in qemu_main_loop () at ../../system/runstate.c:796
#19 0x000055c3e174f786 in qemu_default_main () at ../../system/main.c:37
#20 0x00007f0fa684624a in __libc_start_call_main (main=main@entry=0x55c3e10286e0 <main>, argc=argc@entry=47, argv=argv@entry=0x7ffd5d720f18)
at ../sysdeps/nptl/libc_start_call_main.h:58
#21 0x00007f0fa6846305 in __libc_start_main_impl
(main=0x55c3e10286e0 <main>, argc=47, argv=0x7ffd5d720f18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd5d720f08)
at ../csu/libc-start.c:360
#22 0x000055c3e102a3f1 in _start ()
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-06-05 14:47 ` Alex Bennée
@ 2024-06-05 16:29 ` Dmitry Osipenko
2024-06-05 17:37 ` Alex Bennée
0 siblings, 1 reply; 34+ messages in thread
From: Dmitry Osipenko @ 2024-06-05 16:29 UTC (permalink / raw)
To: Alex Bennée
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 6/5/24 17:47, Alex Bennée wrote:
....
> I'm guessing some sort of resource leak, if I run vkcube-wayland in the
> guest it complains about being stuck on a fence with the iterator going
> up. However on the host I see:
>
> virtio_gpu_fence_ctrl fence 0x13f1, type 0x207
> virtio_gpu_fence_ctrl fence 0x13f2, type 0x207
> virtio_gpu_fence_resp fence 0x13f1
> virtio_gpu_fence_resp fence 0x13f2
> virtio_gpu_fence_ctrl fence 0x13f3, type 0x207
> virtio_gpu_fence_ctrl fence 0x13f4, type 0x207
> virtio_gpu_fence_resp fence 0x13f3
> virtio_gpu_fence_resp fence 0x13f4
> virtio_gpu_fence_ctrl fence 0x13f5, type 0x207
> virtio_gpu_fence_ctrl fence 0x13f6, type 0x207
> virtio_gpu_fence_resp fence 0x13f5
> virtio_gpu_fence_resp fence 0x13f6
> virtio_gpu_fence_ctrl fence 0x13f7, type 0x207
> virtio_gpu_fence_ctrl fence 0x13f8, type 0x207
> virtio_gpu_fence_resp fence 0x13f7
> virtio_gpu_fence_resp fence 0x13f8
> virtio_gpu_fence_ctrl fence 0x13f9, type 0x204
> virtio_gpu_fence_resp fence 0x13f9
>
> which looks like its going ok. However when I git Ctrl-C in the guest it
> kills QEMU:
>
> virtio_gpu_fence_ctrl fence 0x13fc, type 0x207
> virtio_gpu_fence_ctrl fence 0x13fd, type 0x207
> virtio_gpu_fence_ctrl fence 0x13fe, type 0x204
> virtio_gpu_fence_ctrl fence 0x13ff, type 0x207
> virtio_gpu_fence_ctrl fence 0x1400, type 0x207
> virtio_gpu_fence_resp fence 0x13fc
> virtio_gpu_fence_resp fence 0x13fd
> virtio_gpu_fence_resp fence 0x13fe
> virtio_gpu_fence_resp fence 0x13ff
> virtio_gpu_fence_resp fence 0x1400
> qemu-system-aarch64: ../../subprojects/virglrenderer/src/virglrenderer.c:1282: virgl_renderer_resource_unmap: Assertion `!ret' failed.
> fish: Job 1, './qemu-system-aarch64 \' terminated by signal -machine type=virt,virtuali… ( -cpu neoverse-n1 \)
> fish: Job -smp 4 \, ' -accel tcg \' terminated by signal -device virtio-net-pci,netd… ( -device virtio-scsi-pci \)
> fish: Job -device scsi-hd,drive=hd \, ' -netdev user,id=unet,hostfw…' terminated by signal -blockdev driver=raw,node-n… ( -serial mon:stdio \)
> fish: Job -blockdev node-name=rom,dri…, ' -blockdev node-name=efivars…' terminated by signal -m 8192 \ ( -object memory-backend-memf…)
> fish: Job -device virtio-gpu-gl-pci,h…, ' -display sdl,gl=on,show-cur…' terminated by signal -device qemu-xhci -device u… ( -kernel /home/alex/lsrc/lin…)
> fish: Job -d guest_errors,unimp,trace…, 'SIGABRT' terminated by signal Abort ()
>
> The backtrace (and the 18G size of the core file!) indicates a leak:
The unmap debug-assert tells that BO wasn't mapped because mapping
failed, likely due to OOM. You won't hit this abort with a release build
of libvirglrenderer. The leak likely happens due to unsignalled fence.
Please try to run vkcube with disabled fence-feedback feature:
# VN_PERF_NO_FENCE_FEEDBACK=1 vkcube-wayland
It fixes hang for me. We had problems with combination of this Venus
optimization feature + Intel ANV driver for a long time and hoped that
it's fixed by now, apparently the issue was only masked.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-06-05 16:29 ` Dmitry Osipenko
@ 2024-06-05 17:37 ` Alex Bennée
0 siblings, 0 replies; 34+ messages in thread
From: Alex Bennée @ 2024-06-05 17:37 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> On 6/5/24 17:47, Alex Bennée wrote:
> ....
>> I'm guessing some sort of resource leak, if I run vkcube-wayland in the
>> guest it complains about being stuck on a fence with the iterator going
>> up. However on the host I see:
>>
<snip>
>>
>> The backtrace (and the 18G size of the core file!) indicates a leak:
>
> The unmap debug-assert tells that BO wasn't mapped because mapping
> failed, likely due to OOM. You won't hit this abort with a release build
> of libvirglrenderer.
AFAIK I should be building a release build (or at least I hope that is
what the wrapper I posted does):
Message-Id: <20240605133527.529950-1-alex.bennee@linaro.org>
Date: Wed, 5 Jun 2024 14:35:27 +0100
Subject: [RFC PATCH] subprojects: add a wrapper for libvirglrenderer
From: =?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>
Maybe I need to explicitly set builtype=release in the default options?
> The leak likely happens due to unsignalled fence.
>
> Please try to run vkcube with disabled fence-feedback feature:
>
> # VN_PERF_NO_FENCE_FEEDBACK=1 vkcube-wayland
>
> It fixes hang for me. We had problems with combination of this Venus
> optimization feature + Intel ANV driver for a long time and hoped that
> it's fixed by now, apparently the issue was only masked.
That doesn't help, still causes the crash:
virtio_gpu_fence_ctrl fence 0xdfd, type 0x204
virtio_gpu_fence_ctrl fence 0xdfe, type 0x207
virtio_gpu_fence_ctrl fence 0xdff, type 0x207
virtio_gpu_fence_ctrl fence 0xe00, type 0x207
virtio_gpu_fence_ctrl fence 0xe01, type 0x207
virtio_gpu_fence_ctrl fence 0xe02, type 0x207
virtio_gpu_fence_ctrl fence 0xe03, type 0x207
virtio_gpu_fence_resp fence 0xdfd
virtio_gpu_fence_resp fence 0xdfe
virtio_gpu_fence_resp fence 0xdff
virtio_gpu_fence_resp fence 0xe00
virtio_gpu_fence_resp fence 0xe01
virtio_gpu_fence_resp fence 0xe02
virtio_gpu_fence_resp fence 0xe03
stats: vq req 100, 7 -- 3D 25 (19560)
vrend_renderer_resource_unmap: invalid bits 0x83
virgl_renderer_resource_unmap: unexpected ret = -22, pipe:0x555559e5d0c0 fd_type:0
Thread 1 "qemu-system-aar" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
Which I think means VREND_STORAGE_GL_MEMOBJ | VREND_STORAGE_GL_TEXTURE |
VREND_STORAGE_GUEST_MEMORY
(I note the sense of has_bits is meant to be mask, bit but I don't think
that makes any difference)
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v12 00/13] Support blob memory and venus on qemu
2024-05-22 9:00 ` Alex Bennée
2024-05-26 23:46 ` Dmitry Osipenko
@ 2024-05-27 0:07 ` Dmitry Osipenko
1 sibling, 0 replies; 34+ messages in thread
From: Dmitry Osipenko @ 2024-05-27 0:07 UTC (permalink / raw)
To: Alex Bennée
Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau,
Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin,
Stefano Stabellini, Antonio Caggiano, Dr . David Alan Gilbert,
Robert Beckett, Gert Wollny, qemu-devel, Gurchetan Singh, ernunes,
Alyssa Ross, Roger Pau Monné, Alex Deucher,
Stefano Stabellini, Christian König, Xenia Ragiadakou,
Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang,
Chen Jiqian, Yiwei Zhang
On 5/22/24 12:00, Alex Bennée wrote:
> I get a boot up with a lot of:
> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
> (qemu:1545322): Gdk-WARNING **: 09:26:09.470: eglMakeCurrent failed
Have same problem with GTK and arm64/UEFI. Something is resetting
virtio-gpu device during boot (maybe UEFI fw) and it doesn't work
properly with GTK. I'd expect x86 should have same issue, but don't
recall x86 having it.
--
Best regards,
Dmitry
^ permalink raw reply [flat|nested] 34+ messages in thread