* [PATCH v5 0/8] Support virtio-gpu DRM native context @ 2025-01-19 22:00 Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 1/8] ui/sdl2: Restore original context after new context creation Dmitry Osipenko ` (9 more replies) 0 siblings, 10 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual This patchset adds DRM native context support to VirtIO-GPU on Qemu. Contarary to Virgl and Venus contexts that mediates high level GFX APIs, DRM native context [1] mediates lower level kernel driver UAPI, which reflects in a less CPU overhead and less/simpler code needed to support it. DRM context consists of a host and guest parts that have to be implemented for each GPU driver. On a guest side, DRM context presents a virtual GPU as a real/native host GPU device for GL/VK applications. [1] https://www.youtube.com/watch?v=9sFP_yddLLQ Today there are four known DRM native context drivers existing in a wild: - Freedreno (Qualcomm SoC GPUs), completely upstreamed - AMDGPU, mostly merged into upstreams - Intel (i915), merge requests are opened - Asahi (Apple SoC GPUs), WIP status # How to try out DRM context: 1. DRM context uses host blobs and requires latest developer version of Linux kernel [2] that has necessary KVM fixes. [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ 2. Use latest libvirglrenderer from upstream git/main for Freedreno and AMDGPU native contexts. For Intel use patches [3]. [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use Mesa patches [4], for Intel [5]. [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're running Xorg in guest. [6] https://lore.kernel.org/dri-devel/20241020224725.179937-1-dmitry.osipenko@collabora.com/ Example Qemu cmdline that enables DRM context: qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=on,drm_native_context=on \ -machine q35,accel=kvm,memory-backend=mem1 \ -object memory-backend-memfd,id=mem1,size=8G -m 8G # Note about known performance problem in Qemu: DRM contexts are mapping host blobs extensively and these mapping operations work slowly in Qemu. Exact reason is unknown. Mappings work fast on Crosvm For DRM contexts this problem is more visible than for Venus/Virgl. Changelog: v5: - Added r-bs from Akihiko Odaki. - Added acks from Michael Tsirkin. - Fixed compilation warning using older version of virglrenderer that was reported by Alex Bennée. Noticed that I need to keep old virgl_write_fence() code around for the older virglrenderer in "Support asynchronous fencing" patch, so added it back and verified that old virglrenderer works properly. - Added new patch from Alex Bennée that adds more virtio-gpu documentation with a couple corrections and additions to it from me. - Rebased patches on top of latest staging tree. v4: - Improved SDL2/dmabuf patch by reusing existing Meson X11 config option, better handling EGL error and extending comment telling that it's safe to enable SDL2 EGL preference hint. As was suggested by Akihiko Odaki. - Replaced another QSLIST_FOREACH_SAFE with QSLIST_EMPTY+FIRST in the async-fencing patch for more consistency of the code. As was suggested by Akihiko Odaki. - Added missing braces around if-statement that was spotted by Alex Bennée. - Renamed 'drm=on' option of virtio-gpu-gl device to 'drm_native_context=on' for more clarity as was suggested by Alex Bennée. Haven't added added new context-type option that was also proposed by Alex, might do it with a separate patch. This context-type option will duplicate and depecate existing options, but in a longer run likely will be worthwhile adding it. - Dropped Linux headers-update patch as headers has been updated in the staging tree. v3: - Improved EGL presence-check code on X11 systems for the SDL2 hint that prefers EGL over GLX by using better ifdefs and checking Xlib presence at a build time to avoid build failure if lib SDL2 and system are configured with a disabled X11 support. Also added clarifying comment telling that X11 hint doesn't affect Wayland systems. Suggested by Akihiko Odaki. - Corrected strerror(err) that used negative error where it should be positive and vice versa that was caught by Akihiko Odaki. Added clarifying comment for the case where we get positive error code from virglrenderer that differs from other virglrenderer API functions. - Improved QSLIST usage by dropping mutex protecting the async fence list and using atomic variant of QSLIST helpers instead. Switched away from using FOREACH helper to improve readability of the code, showing that we don't precess list in unoptimal way. Like was suggested by Akihiko Odaki. - Updated patchset base to Venus v18. v2: - Updated SDL2-dmabuf patch by making use of error_report() and checking presense of X11+EGL in the system before making SDL2 to prefer EGL backend over GLX, suggested by Akihiko Odaki. - Improved SDL2's dmabuf-presence check that wasn't done properly in v1, where EGL was set up only after first console was fully inited, and thus, SDL's display .has_dmabuf callback didn't work for the first console. Now dmabuf support status is pre-checked before console is registered. - Updated commit description of the patch that fixes SDL2's context switching logic with a more detailed explanation of the problem. Suggested by Akihiko Odaki. - Corrected rebase typo in the async-fencing patch and switched async-fencing to use a sigle-linked list instead of the double, as was suggested by Akihiko Odaki. - Replaced "=true" with "=on" in the DRM native context documentation example and made virtio_gpu_virgl_init() to fail with a error message if DRM context can't be initialized instead of giving a warning message, as was suggested by Akihiko Odaki. - Added patchew's dependecy tag to the cover letter as was suggested by Akihiko Odaki. Alex Bennée (1): docs/system: Expand the virtio-gpu documentation Dmitry Osipenko (6): ui/sdl2: Restore original context after new context creation virtio-gpu: Handle virgl fence creation errors virtio-gpu: Support asynchronous fencing virtio-gpu: Support DRM native context ui/sdl2: Don't disable scanout when display is refreshed ui/gtk: Don't disable scanout when display is refreshed Pierre-Eric Pelloux-Prayer (1): ui/sdl2: Implement dpy dmabuf functions docs/system/devices/virtio-gpu.rst | 105 +++++++++++++++++-- hw/display/virtio-gpu-gl.c | 5 + hw/display/virtio-gpu-virgl.c | 159 ++++++++++++++++++++++++++++- hw/display/virtio-gpu.c | 15 +++ include/hw/virtio/virtio-gpu.h | 16 +++ include/ui/sdl2.h | 7 ++ meson.build | 6 +- ui/gtk-egl.c | 1 - ui/gtk-gl-area.c | 1 - ui/sdl2-gl.c | 68 +++++++++++- ui/sdl2.c | 42 ++++++++ 11 files changed, 411 insertions(+), 14 deletions(-) -- 2.47.1 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 1/8] ui/sdl2: Restore original context after new context creation 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko @ 2025-01-19 22:00 ` Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 2/8] ui/sdl2: Implement dpy dmabuf functions Dmitry Osipenko ` (8 subsequent siblings) 9 siblings, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual SDL API changes GL context to a newly created GL context, which differs from other GL providers that don't switch context. Change SDL backend to restore the original GL context. This allows Qemu's virtio-gpu to support new virglrenderer async-fencing feature for Virgl contexts, otherwise virglrenderer's vrend creates a fence-sync context on the Qemu's main-loop thread that erroneously stays in-use by the main-loop after creation, not allowing vrend's fence-sync thread switch to this new context that belongs to it. Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> --- ui/sdl2-gl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c index e01d9ab0c7bf..b1fe96d6af22 100644 --- a/ui/sdl2-gl.c +++ b/ui/sdl2-gl.c @@ -168,6 +168,9 @@ QEMUGLContext sdl2_gl_create_context(DisplayGLCtx *dgc, SDL_GL_CONTEXT_PROFILE_ES); ctx = SDL_GL_CreateContext(scon->real_window); } + + SDL_GL_MakeCurrent(scon->real_window, scon->winctx); + return (QEMUGLContext)ctx; } -- 2.47.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v5 2/8] ui/sdl2: Implement dpy dmabuf functions 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 1/8] ui/sdl2: Restore original context after new context creation Dmitry Osipenko @ 2025-01-19 22:00 ` Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 3/8] virtio-gpu: Handle virgl fence creation errors Dmitry Osipenko ` (7 subsequent siblings) 9 siblings, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> If EGL is used, we can rely on dmabuf to import textures without doing copies. To get this working on X11, we use the existing SDL hint: SDL_HINT_VIDEO_X11_FORCE_EGL (because dmabuf can't be used with GLX). Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> --- include/ui/sdl2.h | 7 ++++++ meson.build | 6 ++--- ui/sdl2-gl.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++ ui/sdl2.c | 42 +++++++++++++++++++++++++++++++ 4 files changed, 115 insertions(+), 4 deletions(-) diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h index dbe6e3d9739b..9daf5ecffae7 100644 --- a/include/ui/sdl2.h +++ b/include/ui/sdl2.h @@ -45,6 +45,7 @@ struct sdl2_console { bool gui_keysym; SDL_GLContext winctx; QKbdState *kbd; + bool has_dmabuf; #ifdef CONFIG_OPENGL QemuGLShader *gls; egl_fb guest_fb; @@ -96,5 +97,11 @@ void sdl2_gl_scanout_texture(DisplayChangeListener *dcl, void *d3d_tex2d); void sdl2_gl_scanout_flush(DisplayChangeListener *dcl, uint32_t x, uint32_t y, uint32_t w, uint32_t h); +void sdl2_gl_scanout_dmabuf(DisplayChangeListener *dcl, + QemuDmaBuf *dmabuf); +void sdl2_gl_release_dmabuf(DisplayChangeListener *dcl, + QemuDmaBuf *dmabuf); +bool sdl2_gl_has_dmabuf(DisplayChangeListener *dcl); +void sdl2_gl_console_init(struct sdl2_console *scon); #endif /* SDL2_H */ diff --git a/meson.build b/meson.build index 15a066043b7b..dfee104582b0 100644 --- a/meson.build +++ b/meson.build @@ -1964,10 +1964,8 @@ if get_option('gtk') \ endif endif -x11 = not_found -if gtkx11.found() - x11 = dependency('x11', method: 'pkg-config', required: gtkx11.found()) -endif +x11 = dependency('x11', method: 'pkg-config', required: gtkx11.found()) + png = not_found if get_option('png').allowed() and have_system png = dependency('libpng', version: '>=1.6.34', required: get_option('png'), diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c index b1fe96d6af22..8d53e340d40d 100644 --- a/ui/sdl2-gl.c +++ b/ui/sdl2-gl.c @@ -26,6 +26,8 @@ */ #include "qemu/osdep.h" +#include "qemu/main-loop.h" +#include "qemu/error-report.h" #include "ui/console.h" #include "ui/input.h" #include "ui/sdl2.h" @@ -249,3 +251,65 @@ void sdl2_gl_scanout_flush(DisplayChangeListener *dcl, SDL_GL_SwapWindow(scon->real_window); } + +void sdl2_gl_scanout_dmabuf(DisplayChangeListener *dcl, + QemuDmaBuf *dmabuf) +{ + struct sdl2_console *scon = container_of(dcl, struct sdl2_console, dcl); + + assert(scon->opengl); + SDL_GL_MakeCurrent(scon->real_window, scon->winctx); + + egl_dmabuf_import_texture(dmabuf); + if (!qemu_dmabuf_get_texture(dmabuf)) { + error_report("%s: failed fd=%d", __func__, qemu_dmabuf_get_fd(dmabuf)); + return; + } + + sdl2_gl_scanout_texture(dcl, qemu_dmabuf_get_texture(dmabuf), false, + qemu_dmabuf_get_width(dmabuf), + qemu_dmabuf_get_height(dmabuf), + 0, 0, + qemu_dmabuf_get_width(dmabuf), + qemu_dmabuf_get_height(dmabuf), + NULL); + + if (qemu_dmabuf_get_allow_fences(dmabuf)) { + scon->guest_fb.dmabuf = dmabuf; + } +} + +void sdl2_gl_release_dmabuf(DisplayChangeListener *dcl, + QemuDmaBuf *dmabuf) +{ + egl_dmabuf_release_texture(dmabuf); +} + +bool sdl2_gl_has_dmabuf(DisplayChangeListener *dcl) +{ + struct sdl2_console *scon = container_of(dcl, struct sdl2_console, dcl); + + return scon->has_dmabuf; +} + +void sdl2_gl_console_init(struct sdl2_console *scon) +{ + bool hidden = scon->hidden; + + scon->hidden = true; + scon->surface = qemu_create_displaysurface(1, 1); + sdl2_window_create(scon); + + /* + * QEMU checks whether console supports dma-buf before switching + * to the console. To break this chicken-egg problem we pre-check + * dma-buf availability beforehand using a dummy SDL window. + */ + scon->has_dmabuf = qemu_egl_has_dmabuf(); + + sdl2_window_destroy(scon); + qemu_free_displaysurface(scon->surface); + + scon->surface = NULL; + scon->hidden = hidden; +} diff --git a/ui/sdl2.c b/ui/sdl2.c index 445eb1dd9f9a..3e262b994231 100644 --- a/ui/sdl2.c +++ b/ui/sdl2.c @@ -36,6 +36,10 @@ #include "qemu/log.h" #include "qemu-main.h" +#ifdef CONFIG_X11 +#include <X11/Xlib.h> +#endif + static int sdl2_num_outputs; static struct sdl2_console *sdl2_console; @@ -121,6 +125,9 @@ void sdl2_window_create(struct sdl2_console *scon) /* The SDL renderer is only used by sdl2-2D, when OpenGL is disabled */ scon->real_renderer = SDL_CreateRenderer(scon->real_window, -1, 0); } + + qemu_egl_display = eglGetCurrentDisplay(); + sdl_update_caption(scon); } @@ -821,6 +828,10 @@ static const DisplayChangeListenerOps dcl_gl_ops = { .dpy_gl_scanout_disable = sdl2_gl_scanout_disable, .dpy_gl_scanout_texture = sdl2_gl_scanout_texture, .dpy_gl_update = sdl2_gl_scanout_flush, + + .dpy_gl_scanout_dmabuf = sdl2_gl_scanout_dmabuf, + .dpy_gl_release_dmabuf = sdl2_gl_release_dmabuf, + .dpy_has_dmabuf = sdl2_gl_has_dmabuf, }; static bool @@ -848,6 +859,35 @@ static void sdl2_display_early_init(DisplayOptions *o) } } +static void sdl2_set_hint_x11_force_egl(void) +{ +#if defined(SDL_HINT_VIDEO_X11_FORCE_EGL) && defined(CONFIG_OPENGL) && \ + defined(CONFIG_X11) + Display *x_disp = XOpenDisplay(NULL); + EGLDisplay egl_display; + + if (!x_disp) { + return; + } + + /* Prefer EGL over GLX to get dma-buf support. */ + egl_display = eglGetDisplay((EGLNativeDisplayType)x_disp); + + if (egl_display != EGL_NO_DISPLAY) { + /* + * Setting X11_FORCE_EGL hint doesn't make SDL to prefer X11 over + * Wayland. SDL will use Wayland driver even if XWayland presents. + * It's always safe to set the hint even if X11 is not used by SDL. + * SDL will work regardless of the hint. + */ + SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1"); + eglTerminate(egl_display); + } + + XCloseDisplay(x_disp); +#endif +} + static void sdl2_display_init(DisplayState *ds, DisplayOptions *o) { uint8_t data = 0; @@ -878,6 +918,7 @@ static void sdl2_display_init(DisplayState *ds, DisplayOptions *o) SDL_SetHint(SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED, "0"); #endif SDL_SetHint(SDL_HINT_WINDOWS_NO_CLOSE_ON_ALT_F4, "1"); + sdl2_set_hint_x11_force_egl(); SDL_EnableScreenSaver(); memset(&info, 0, sizeof(info)); SDL_VERSION(&info.version); @@ -924,6 +965,7 @@ static void sdl2_display_init(DisplayState *ds, DisplayOptions *o) sdl2_console[i].kbd = qkbd_state_init(con); if (display_opengl) { qemu_console_set_display_gl_ctx(con, &sdl2_console[i].dgc); + sdl2_gl_console_init(&sdl2_console[i]); } register_displaychangelistener(&sdl2_console[i].dcl); -- 2.47.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v5 3/8] virtio-gpu: Handle virgl fence creation errors 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 1/8] ui/sdl2: Restore original context after new context creation Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 2/8] ui/sdl2: Implement dpy dmabuf functions Dmitry Osipenko @ 2025-01-19 22:00 ` Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 4/8] virtio-gpu: Support asynchronous fencing Dmitry Osipenko ` (6 subsequent siblings) 9 siblings, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual Print out error messages when virgl fence creation fails to aid debugging of the fence-related bugs. Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> --- hw/display/virtio-gpu-virgl.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c index 145a0b387956..2eb6aaab4e84 100644 --- a/hw/display/virtio-gpu-virgl.c +++ b/hw/display/virtio-gpu-virgl.c @@ -872,6 +872,7 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g, struct virtio_gpu_ctrl_command *cmd) { bool cmd_suspended = false; + int ret; VIRTIO_GPU_FILL_CMD(cmd->cmd_hdr); @@ -970,7 +971,17 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g, } trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type); - virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type); + + /* + * Unlike other virglrenderer functions, this one returns a positive + * error code. + */ + ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0); + if (ret) { + qemu_log_mask(LOG_GUEST_ERROR, + "%s: virgl_renderer_create_fence error: %s", + __func__, strerror(ret)); + } } static void virgl_write_fence(void *opaque, uint32_t fence) -- 2.47.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v5 4/8] virtio-gpu: Support asynchronous fencing 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko ` (2 preceding siblings ...) 2025-01-19 22:00 ` [PATCH v5 3/8] virtio-gpu: Handle virgl fence creation errors Dmitry Osipenko @ 2025-01-19 22:00 ` Dmitry Osipenko [not found] ` <87cyghr3l2.fsf@draig.linaro.org> 2025-01-19 22:00 ` [PATCH v5 5/8] virtio-gpu: Support DRM native context Dmitry Osipenko ` (5 subsequent siblings) 9 siblings, 1 reply; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual Support asynchronous fencing feature of virglrenderer. It allows Qemu to handle fence as soon as it's signalled instead of periodically polling the fence status. This feature is required for enabling DRM context support in Qemu because legacy fencing mode isn't supported for DRM contexts in virglrenderer. Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> --- hw/display/virtio-gpu-gl.c | 3 + hw/display/virtio-gpu-virgl.c | 142 ++++++++++++++++++++++++++++++--- include/hw/virtio/virtio-gpu.h | 13 +++ 3 files changed, 149 insertions(+), 9 deletions(-) diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c index 683fad3bf8a8..d9bb50ac1d4a 100644 --- a/hw/display/virtio-gpu-gl.c +++ b/hw/display/virtio-gpu-gl.c @@ -169,6 +169,9 @@ static void virtio_gpu_gl_device_unrealize(DeviceState *qdev) if (gl->renderer_state >= RS_INITED) { #if VIRGL_VERSION_MAJOR >= 1 qemu_bh_delete(gl->cmdq_resume_bh); + + virtio_gpu_virgl_reset_async_fences(g); + qemu_bh_delete(gl->async_fence_bh); #endif if (virtio_gpu_stats_enabled(g->parent_obj.conf)) { timer_free(gl->print_stats); diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c index 2eb6aaab4e84..15a465acf43b 100644 --- a/hw/display/virtio-gpu-virgl.c +++ b/hw/display/virtio-gpu-virgl.c @@ -871,6 +871,7 @@ static void virgl_cmd_set_scanout_blob(VirtIOGPU *g, void virtio_gpu_virgl_process_cmd(VirtIOGPU *g, struct virtio_gpu_ctrl_command *cmd) { + VirtIOGPUGL *gl = VIRTIO_GPU_GL(g); bool cmd_suspended = false; int ret; @@ -972,15 +973,29 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g, trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type); - /* - * Unlike other virglrenderer functions, this one returns a positive - * error code. - */ - ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0); - if (ret) { - qemu_log_mask(LOG_GUEST_ERROR, - "%s: virgl_renderer_create_fence error: %s", - __func__, strerror(ret)); + if (gl->context_fence_enabled && + (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX)) { + uint32_t flags = 0; + + ret = virgl_renderer_context_create_fence(cmd->cmd_hdr.ctx_id, flags, + cmd->cmd_hdr.ring_idx, + cmd->cmd_hdr.fence_id); + if (ret) { + qemu_log_mask(LOG_GUEST_ERROR, + "%s: virgl_renderer_context_create_fence error: %s", + __func__, strerror(-ret)); + } + } else { + /* + * Unlike other virglrenderer functions, this one returns a positive + * error code. + */ + ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0); + if (ret) { + qemu_log_mask(LOG_GUEST_ERROR, + "%s: virgl_renderer_create_fence error: %s", + __func__, strerror(ret)); + } } } @@ -1008,6 +1023,102 @@ static void virgl_write_fence(void *opaque, uint32_t fence) } } +void virtio_gpu_virgl_reset_async_fences(VirtIOGPU *g) +{ + struct virtio_gpu_virgl_context_fence *f; + VirtIOGPUGL *gl = VIRTIO_GPU_GL(g); + + while (!QSLIST_EMPTY(&gl->async_fenceq)) { + f = QSLIST_FIRST(&gl->async_fenceq); + + QSLIST_REMOVE_HEAD(&gl->async_fenceq, next); + + g_free(f); + } +} + +#if VIRGL_VERSION_MAJOR >= 1 +static void virtio_gpu_virgl_async_fence_bh(void *opaque) +{ + QSLIST_HEAD(, virtio_gpu_virgl_context_fence) async_fenceq; + struct virtio_gpu_ctrl_command *cmd, *tmp; + struct virtio_gpu_virgl_context_fence *f; + VirtIOGPU *g = opaque; + VirtIOGPUGL *gl = VIRTIO_GPU_GL(g); + + QSLIST_MOVE_ATOMIC(&async_fenceq, &gl->async_fenceq); + + while (!QSLIST_EMPTY(&async_fenceq)) { + f = QSLIST_FIRST(&async_fenceq); + + QSLIST_REMOVE_HEAD(&async_fenceq, next); + + QTAILQ_FOREACH_SAFE(cmd, &g->fenceq, next, tmp) { + /* + * the guest can end up emitting fences out of order + * so we should check all fenced cmds not just the first one. + */ + if (cmd->cmd_hdr.fence_id > f->fence_id) { + continue; + } + if (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX) { + if (cmd->cmd_hdr.ring_idx != f->ring_idx) { + continue; + } + if (cmd->cmd_hdr.ctx_id != f->ctx_id) { + continue; + } + } else if (f->ring_idx >= 0) { + /* ctx0 GL-query fences don't have ring info */ + continue; + } + virtio_gpu_ctrl_response_nodata(g, cmd, VIRTIO_GPU_RESP_OK_NODATA); + QTAILQ_REMOVE(&g->fenceq, cmd, next); + g_free(cmd); + } + + trace_virtio_gpu_fence_resp(f->fence_id); + g_free(f); + g->inflight--; + if (virtio_gpu_stats_enabled(g->parent_obj.conf)) { + trace_virtio_gpu_dec_inflight_fences(g->inflight); + } + } +} + +static void +virtio_gpu_virgl_push_async_fence(VirtIOGPU *g, uint32_t ctx_id, + int64_t ring_idx, uint64_t fence_id) +{ + struct virtio_gpu_virgl_context_fence *f; + VirtIOGPUGL *gl = VIRTIO_GPU_GL(g); + + f = g_new(struct virtio_gpu_virgl_context_fence, 1); + f->ctx_id = ctx_id; + f->ring_idx = ring_idx; + f->fence_id = fence_id; + + QSLIST_INSERT_HEAD_ATOMIC(&gl->async_fenceq, f, next); + + qemu_bh_schedule(gl->async_fence_bh); +} + +static void virgl_write_async_fence(void *opaque, uint32_t fence) +{ + VirtIOGPU *g = opaque; + + virtio_gpu_virgl_push_async_fence(g, 0, -1, fence); +} + +static void virgl_write_async_context_fence(void *opaque, uint32_t ctx_id, + uint32_t ring_idx, uint64_t fence) +{ + VirtIOGPU *g = opaque; + + virtio_gpu_virgl_push_async_fence(g, ctx_id, ring_idx, fence); +} +#endif + static virgl_renderer_gl_context virgl_create_context(void *opaque, int scanout_idx, struct virgl_renderer_gl_ctx_param *params) @@ -1095,6 +1206,8 @@ void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g) dpy_gfx_replace_surface(g->parent_obj.scanout[i].con, NULL); dpy_gl_scanout_disable(g->parent_obj.scanout[i].con); } + + virtio_gpu_virgl_reset_async_fences(g); } void virtio_gpu_virgl_reset(VirtIOGPU *g) @@ -1112,6 +1225,13 @@ int virtio_gpu_virgl_init(VirtIOGPU *g) if (qemu_egl_display) { virtio_gpu_3d_cbs.version = 4; virtio_gpu_3d_cbs.get_egl_display = virgl_get_egl_display; +#if VIRGL_VERSION_MAJOR >= 1 + virtio_gpu_3d_cbs.write_fence = virgl_write_async_fence; + virtio_gpu_3d_cbs.write_context_fence = virgl_write_async_context_fence; + flags |= VIRGL_RENDERER_ASYNC_FENCE_CB; + flags |= VIRGL_RENDERER_THREAD_SYNC; + gl->context_fence_enabled = true; +#endif } #endif #ifdef VIRGL_RENDERER_D3D11_SHARE_TEXTURE @@ -1145,6 +1265,10 @@ int virtio_gpu_virgl_init(VirtIOGPU *g) gl->cmdq_resume_bh = aio_bh_new(qemu_get_aio_context(), virtio_gpu_virgl_resume_cmdq_bh, g); + + gl->async_fence_bh = aio_bh_new(qemu_get_aio_context(), + virtio_gpu_virgl_async_fence_bh, + g); #endif return 0; diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h index a42957c4e2cc..bd2cccdc60d7 100644 --- a/include/hw/virtio/virtio-gpu.h +++ b/include/hw/virtio/virtio-gpu.h @@ -230,6 +230,13 @@ struct VirtIOGPUClass { Error **errp); }; +struct virtio_gpu_virgl_context_fence { + uint32_t ctx_id; + int64_t ring_idx; + uint64_t fence_id; + QSLIST_ENTRY(virtio_gpu_virgl_context_fence) next; +}; + /* VirtIOGPUGL renderer states */ typedef enum { RS_START, /* starting state */ @@ -247,6 +254,11 @@ struct VirtIOGPUGL { QEMUTimer *print_stats; QEMUBH *cmdq_resume_bh; + + QEMUBH *async_fence_bh; + QSLIST_HEAD(, virtio_gpu_virgl_context_fence) async_fenceq; + + bool context_fence_enabled; }; struct VhostUserGPU { @@ -376,5 +388,6 @@ void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g); void virtio_gpu_virgl_reset(VirtIOGPU *g); int virtio_gpu_virgl_init(VirtIOGPU *g); GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g); +void virtio_gpu_virgl_reset_async_fences(VirtIOGPU *g); #endif -- 2.47.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
[parent not found: <87cyghr3l2.fsf@draig.linaro.org>]
* Re: [PATCH v5 4/8] virtio-gpu: Support asynchronous fencing [not found] ` <87cyghr3l2.fsf@draig.linaro.org> @ 2025-01-22 12:18 ` Dmitry Osipenko 0 siblings, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-22 12:18 UTC (permalink / raw) To: Alex Bennée Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 1/20/25 16:56, Alex Bennée wrote: ... >> @@ -972,15 +973,29 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g, >> >> trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type); >> >> - /* >> - * Unlike other virglrenderer functions, this one returns a positive >> - * error code. >> - */ >> - ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0); >> - if (ret) { >> - qemu_log_mask(LOG_GUEST_ERROR, >> - "%s: virgl_renderer_create_fence error: %s", >> - __func__, strerror(ret)); >> + if (gl->context_fence_enabled && >> + (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX)) { >> + uint32_t flags = 0; > > Is this is constant or do we expect to change this later? There are no immediate plans for using this flags variable in QEMU today. But in general context-specific flags could be specified here. Crosv makes use of the flags. >> + ret = virgl_renderer_context_create_fence(cmd->cmd_hdr.ctx_id, flags, >> + cmd->cmd_hdr.ring_idx, >> + cmd->cmd_hdr.fence_id); >> + if (ret) { >> + qemu_log_mask(LOG_GUEST_ERROR, >> + "%s: virgl_renderer_context_create_fence error: %s", >> + __func__, strerror(-ret)); > > This still fails with older virglrenderers: > > ../../hw/display/virtio-gpu-virgl.c: In function ‘virtio_gpu_virgl_process_cmd’: > ../../hw/display/virtio-gpu-virgl.c:980:15: error: implicit declaration of function ‘virgl_renderer_context_create_fence’; did you mean ‘virgl_renderer_context_create’? [-Werror=implicit-function-declaration] > 980 | ret = virgl_renderer_context_create_fence(cmd->cmd_hdr.ctx_id, flags, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | virgl_renderer_context_create > ../../hw/display/virtio-gpu-virgl.c:980:15: error: nested extern declaration of ‘virgl_renderer_context_create_fence’ [-Werror=nested-externs] > cc1: all warnings being treated as errors > [1981/2819] Compiling C object libcommon.a.p/ui_sdl2-gl.c.o Indeed! Good catch again, thanks! Will fix in v6 -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 5/8] virtio-gpu: Support DRM native context 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko ` (3 preceding siblings ...) 2025-01-19 22:00 ` [PATCH v5 4/8] virtio-gpu: Support asynchronous fencing Dmitry Osipenko @ 2025-01-19 22:00 ` Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 6/8] ui/sdl2: Don't disable scanout when display is refreshed Dmitry Osipenko ` (4 subsequent siblings) 9 siblings, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual Add support for DRM native contexts to VirtIO-GPU. DRM context is enabled using a new virtio-gpu-gl device option "drm_native_context=on". Unlike Virgl and Venus contexts that operate on application API level, DRM native contexts work on a kernel UAPI level. This lower level results in a lightweight context implementations that yield better performance. Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> --- docs/system/devices/virtio-gpu.rst | 11 +++++++++++ hw/display/virtio-gpu-gl.c | 2 ++ hw/display/virtio-gpu-virgl.c | 22 ++++++++++++++++++++++ hw/display/virtio-gpu.c | 15 +++++++++++++++ include/hw/virtio/virtio-gpu.h | 3 +++ 5 files changed, 53 insertions(+) diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst index b7eb0fc0e727..f20c60016376 100644 --- a/docs/system/devices/virtio-gpu.rst +++ b/docs/system/devices/virtio-gpu.rst @@ -82,6 +82,17 @@ of virtio-gpu host memory window. This is typically between 256M and 8G. .. _venus: https://gitlab.freedesktop.org/virgl/venus-protocol/ +DRM native context is supported since release of `virglrenderer`_ v1.0.0 +using `drm`_ protocol. ``DRM`` virtio-gpu capability set ("capset") requires +host blob support (``hostmem`` and ``blob`` fields) and should be enabled +using ``drm_native_context`` field. The ``hostmem`` field specifies the size +of virtio-gpu host memory window. This is typically between 256M and 8G. + +.. parsed-literal:: + -device virtio-gpu-gl,hostmem=8G,blob=on,drm_native_context=on + +.. _drm: https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm + virtio-gpu rutabaga ------------------- diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c index d9bb50ac1d4a..5f374ad56396 100644 --- a/hw/display/virtio-gpu-gl.c +++ b/hw/display/virtio-gpu-gl.c @@ -159,6 +159,8 @@ static const Property virtio_gpu_gl_properties[] = { VIRTIO_GPU_FLAG_STATS_ENABLED, false), DEFINE_PROP_BIT("venus", VirtIOGPU, parent_obj.conf.flags, VIRTIO_GPU_FLAG_VENUS_ENABLED, false), + DEFINE_PROP_BIT("drm_native_context", VirtIOGPU, parent_obj.conf.flags, + VIRTIO_GPU_FLAG_DRM_ENABLED, false), }; static void virtio_gpu_gl_device_unrealize(DeviceState *qdev) diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c index 15a465acf43b..34ba8118f31d 100644 --- a/hw/display/virtio-gpu-virgl.c +++ b/hw/display/virtio-gpu-virgl.c @@ -1243,6 +1243,19 @@ int virtio_gpu_virgl_init(VirtIOGPU *g) if (virtio_gpu_venus_enabled(g->parent_obj.conf)) { flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER; } + if (virtio_gpu_drm_enabled(g->parent_obj.conf)) { + flags |= VIRGL_RENDERER_DRM; + + if (!gl->context_fence_enabled) { + /* + * Virglrenderer skips enabling DRM context support without + * enabled async-fence feature. VirtIO-GPU will initialize + * successfully, but DRM context won't be available in guest. + */ + error_report("DRM native context requires EGL display"); + return -EINVAL; + } + } #endif ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs); @@ -1305,5 +1318,14 @@ GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g) } } + if (virtio_gpu_drm_enabled(g->parent_obj.conf)) { + virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_DRM, + &capset_max_ver, + &capset_max_size); + if (capset_max_size) { + virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_DRM); + } + } + return capset_ids; } diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c index 11a7a8575027..165a0976480d 100644 --- a/hw/display/virtio-gpu.c +++ b/hw/display/virtio-gpu.c @@ -1505,6 +1505,21 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp) #endif } + if (virtio_gpu_drm_enabled(g->parent_obj.conf)) { +#ifdef VIRGL_VERSION_MAJOR + #if VIRGL_VERSION_MAJOR >= 1 + if (!virtio_gpu_blob_enabled(g->parent_obj.conf) || + !virtio_gpu_hostmem_enabled(g->parent_obj.conf)) { + error_setg(errp, "drm requires enabled blob and hostmem options"); + return; + } + #else + error_setg(errp, "old virglrenderer, drm unsupported"); + return; + #endif +#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 bd2cccdc60d7..dcdf52b192b5 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_RUTABAGA_ENABLED, VIRTIO_GPU_FLAG_VENUS_ENABLED, VIRTIO_GPU_FLAG_RESOURCE_UUID_ENABLED, + VIRTIO_GPU_FLAG_DRM_ENABLED, }; #define virtio_gpu_virgl_enabled(_cfg) \ @@ -121,6 +122,8 @@ enum virtio_gpu_base_conf_flags { (_cfg.hostmem > 0) #define virtio_gpu_venus_enabled(_cfg) \ (_cfg.flags & (1 << VIRTIO_GPU_FLAG_VENUS_ENABLED)) +#define virtio_gpu_drm_enabled(_cfg) \ + (_cfg.flags & (1 << VIRTIO_GPU_FLAG_DRM_ENABLED)) struct virtio_gpu_base_conf { uint32_t max_outputs; -- 2.47.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v5 6/8] ui/sdl2: Don't disable scanout when display is refreshed 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko ` (4 preceding siblings ...) 2025-01-19 22:00 ` [PATCH v5 5/8] virtio-gpu: Support DRM native context Dmitry Osipenko @ 2025-01-19 22:00 ` Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 7/8] ui/gtk: " Dmitry Osipenko ` (3 subsequent siblings) 9 siblings, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual Display refreshment is invoked by a timer and it erroneously disables the active scanout if it happens to be invoked after scanout has been enabled. This offending scanout-disable race condition with a timer can be easily hit when Qemu runs with a disabled vsync by using SDL or GTK displays (with vblank_mode=0 for GTK). Refreshment of display's content shouldn't disable the active display. Fix it by keeping the scanout's state unchanged when display is redrawn. Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> --- ui/sdl2-gl.c | 1 - 1 file changed, 1 deletion(-) diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c index 8d53e340d40d..31f8fbe03286 100644 --- a/ui/sdl2-gl.c +++ b/ui/sdl2-gl.c @@ -53,7 +53,6 @@ static void sdl2_gl_render_surface(struct sdl2_console *scon) int ww, wh; SDL_GL_MakeCurrent(scon->real_window, scon->winctx); - sdl2_set_scanout_mode(scon, false); SDL_GetWindowSize(scon->real_window, &ww, &wh); surface_gl_setup_viewport(scon->gls, scon->surface, ww, wh); -- 2.47.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v5 7/8] ui/gtk: Don't disable scanout when display is refreshed 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko ` (5 preceding siblings ...) 2025-01-19 22:00 ` [PATCH v5 6/8] ui/sdl2: Don't disable scanout when display is refreshed Dmitry Osipenko @ 2025-01-19 22:00 ` Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation Dmitry Osipenko ` (2 subsequent siblings) 9 siblings, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual Display refreshment is invoked by a timer and it erroneously disables the active scanout if it happens to be invoked after scanout has been enabled. This offending scanout-disable race condition with a timer can be easily hit when Qemu runs with a disabled vsync by using SDL or GTK displays (with vblank_mode=0 for GTK). Refreshment of display's content shouldn't disable the active display. Fix it by keeping the scanout's state unchanged when display is redrawn. Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> --- ui/gtk-egl.c | 1 - ui/gtk-gl-area.c | 1 - 2 files changed, 2 deletions(-) diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c index f7a428c86a8d..0d1547d63ad0 100644 --- a/ui/gtk-egl.c +++ b/ui/gtk-egl.c @@ -179,7 +179,6 @@ void gd_egl_refresh(DisplayChangeListener *dcl) if (vc->gfx.glupdates) { vc->gfx.glupdates = 0; - gtk_egl_set_scanout_mode(vc, false); gd_egl_draw(vc); } } diff --git a/ui/gtk-gl-area.c b/ui/gtk-gl-area.c index 2c9a0db42571..53d81124f211 100644 --- a/ui/gtk-gl-area.c +++ b/ui/gtk-gl-area.c @@ -148,7 +148,6 @@ void gd_gl_area_refresh(DisplayChangeListener *dcl) if (vc->gfx.glupdates) { vc->gfx.glupdates = 0; - gtk_gl_area_set_scanout_mode(vc, false); gtk_gl_area_queue_render(GTK_GL_AREA(vc->gfx.drawing_area)); } } -- 2.47.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko ` (6 preceding siblings ...) 2025-01-19 22:00 ` [PATCH v5 7/8] ui/gtk: " Dmitry Osipenko @ 2025-01-19 22:00 ` Dmitry Osipenko [not found] ` <c2e1c362-5d02-488e-b849-d0b14781a60f@daynix.com> [not found] ` <871pwxqyr3.fsf@draig.linaro.org> 2025-01-22 17:00 ` Alex Bennée 9 siblings, 1 reply; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-19 22:00 UTC (permalink / raw) To: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Alex Bennée, Michael S . Tsirkin, Paolo Bonzini Cc: Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual From: Alex Bennée <alex.bennee@linaro.org> This attempts to tidy up the VirtIO GPU documentation to make the list of requirements clearer. There are still a lot of moving parts and the distros have some catching up to do before this is all handled automatically. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Sergio Lopez Pascual <slp@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> [dmitry.osipenko@collabora.com: Extended and corrected doc] --- docs/system/devices/virtio-gpu.rst | 94 ++++++++++++++++++++++++++++-- 1 file changed, 88 insertions(+), 6 deletions(-) diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst index f20c60016376..79af291a9316 100644 --- a/docs/system/devices/virtio-gpu.rst +++ b/docs/system/devices/virtio-gpu.rst @@ -4,14 +4,96 @@ virtio-gpu ========== -This document explains the setup and usage of the virtio-gpu device. -The virtio-gpu device paravirtualizes the GPU and display controller. - -Linux kernel support --------------------- +The virtio-gpu device provides a GPU and display controller +paravirtualized using VirtIO. It supports a number of different modes +from simple 2D displays to fully accelerated 3D graphics. + +Dependencies +............ + +.. note:: + GPU virtualisation is still an evolving field. Depending on the mode + you are running you may need to override distribution supplied + libraries with more recent versions or enable build options. + +Host requirements +----------------- + +Depending on the mode there are a number of requirements the host must +meet to be able to be able to support guests. For 3D acceleration QEMU +must be able to access the hosts GPU and for the best performance be +able to reliably share GPU memory with the guest. + +.. list-table:: Host Requirements + :header-rows: 1 + + * - Mode + - Kernel + - Userspace + * - virtio-gpu + - framebuffer enabled + - GTK or SDL display + * - virtio-gpu-gl (OpenGL pass-through) + - GPU enabled + - libvirglrenderer (virgl support) + * - virtio-gpu-gl (rutabaga/gfxstream) + - GPU enabled + - aemu/rutabaga_gfx_ffi or vhost-user client with support + * - virtio-gpu-gl (Vulkan pass-through) + - Linux 6.13+ + - libvirglrenderer (>= 1.0.0, venus support) + * - virtio-gpu-gl (vDRM native context/AMD) + - Linux 6.13+ + - libvirglrenderer (>= 1.1.0, DRM renderer support) + * - virtio-gpu-gl (vDRM native context/Freedreno) + - Linux 6.13+ + - libvirglrenderer (>= 1.0.0, DRM renderer support) + * - virtio-gpu-gl (vDRM native context/Intel i915) + - Linux 6.13+ + - libvirglrenderer (`mr1384`_, DRM renderer support) + +.. _mr1384: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 + +Guest requirements +------------------ virtio-gpu requires a guest Linux kernel built with the -``CONFIG_DRM_VIRTIO_GPU`` option. +``CONFIG_DRM_VIRTIO_GPU`` option. Otherwise for 3D accelerations you +will need support from Mesa configured for whichever encapsulation you +need. + +.. list-table:: Guest Requirements + :header-rows: 1 + + * - Mode + - Mesa Version + - Mesa build flags + * - virtio-gpu + - n/a + - n/a + * - virtio-gpu-gl (OpenGL pass-through) + - 20.3.0+ + - -Dgallium-drivers=virgl + * - virtio-gpu-gl (rutabaga/gfxstream) + - 24.3.0+ + - -Dvulkan-drivers=gfxstream + * - virtio-gpu-gl (Vulkan pass-through) + - 24.2+ + - -Dvulkan-drivers=virtio + * - virtio-gpu-gl (vDRM native context/AMD) + - 25.0.0+ + - -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true + * - virtio-gpu-gl (vDRM native context/Freedreno) + - 23.1.0+ + - -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno + * - virtio-gpu-gl (vDRM native context/Intel i915) + - `mr29870`_ + - -Dgallium-drivers=iris -Dvulkan-drivers=intel -Dintel-virtio-experimental=true + +.. _mr29870: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 + +Further information +................... QEMU virtio-gpu variants ------------------------ -- 2.47.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
[parent not found: <c2e1c362-5d02-488e-b849-d0b14781a60f@daynix.com>]
[parent not found: <87ikq9r7wj.fsf@draig.linaro.org>]
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation [not found] ` <87ikq9r7wj.fsf@draig.linaro.org> @ 2025-01-21 4:26 ` Akihiko Odaki 2025-01-26 18:06 ` Dmitry Osipenko 0 siblings, 1 reply; 28+ messages in thread From: Akihiko Odaki @ 2025-01-21 4:26 UTC (permalink / raw) To: Alex Bennée Cc: Dmitry Osipenko, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2025/01/20 21:23, Alex Bennée wrote: > Akihiko Odaki <akihiko.odaki@daynix.com> writes: > >> On 2025/01/20 7:00, Dmitry Osipenko wrote: >>> From: Alex Bennée <alex.bennee@linaro.org> >>> This attempts to tidy up the VirtIO GPU documentation to make the >>> list >>> of requirements clearer. There are still a lot of moving parts and the >>> distros have some catching up to do before this is all handled >>> automatically. >>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> >>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>> Cc: Sergio Lopez Pascual <slp@redhat.com> >>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>> [dmitry.osipenko@collabora.com: Extended and corrected doc] >>> --- >>> docs/system/devices/virtio-gpu.rst | 94 ++++++++++++++++++++++++++++-- >>> 1 file changed, 88 insertions(+), 6 deletions(-) >>> diff --git a/docs/system/devices/virtio-gpu.rst >>> b/docs/system/devices/virtio-gpu.rst >>> index f20c60016376..79af291a9316 100644 >>> --- a/docs/system/devices/virtio-gpu.rst >>> +++ b/docs/system/devices/virtio-gpu.rst >>> @@ -4,14 +4,96 @@ >>> virtio-gpu >>> ========== >>> -This document explains the setup and usage of the virtio-gpu >>> device. >>> -The virtio-gpu device paravirtualizes the GPU and display controller. >>> - >>> -Linux kernel support >>> --------------------- >>> +The virtio-gpu device provides a GPU and display controller >>> +paravirtualized using VirtIO. It supports a number of different modes >>> +from simple 2D displays to fully accelerated 3D graphics. >>> + >>> +Dependencies >>> +............ >>> + >>> +.. note:: >>> + GPU virtualisation is still an evolving field. Depending on the mode >>> + you are running you may need to override distribution supplied >>> + libraries with more recent versions or enable build options. >>> + >>> +Host requirements >>> +----------------- >>> + >>> +Depending on the mode there are a number of requirements the host must >>> +meet to be able to be able to support guests. For 3D acceleration QEMU >>> +must be able to access the hosts GPU and for the best performance be >>> +able to reliably share GPU memory with the guest. >>> + >>> +.. list-table:: Host Requirements >>> + :header-rows: 1 >>> + >>> + * - Mode >>> + - Kernel >>> + - Userspace >>> + * - virtio-gpu >>> + - framebuffer enabled >>> + - GTK or SDL display >>> + * - virtio-gpu-gl (OpenGL pass-through) >>> + - GPU enabled >>> + - libvirglrenderer (virgl support) >>> + * - virtio-gpu-gl (rutabaga/gfxstream) >>> + - GPU enabled >>> + - aemu/rutabaga_gfx_ffi or vhost-user client with support >>> + * - virtio-gpu-gl (Vulkan pass-through) >>> + - Linux 6.13+ >>> + - libvirglrenderer (>= 1.0.0, venus support) >>> + * - virtio-gpu-gl (vDRM native context/AMD) >>> + - Linux 6.13+ >>> + - libvirglrenderer (>= 1.1.0, DRM renderer support) >>> + * - virtio-gpu-gl (vDRM native context/Freedreno) >>> + - Linux 6.13+ >>> + - libvirglrenderer (>= 1.0.0, DRM renderer support) >>> + * - virtio-gpu-gl (vDRM native context/Intel i915) >>> + - Linux 6.13+ >>> + - libvirglrenderer (`mr1384`_, DRM renderer support) >>> + >>> +.. _mr1384: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 >>> + >>> +Guest requirements >>> +------------------ >>> virtio-gpu requires a guest Linux kernel built with the >>> -``CONFIG_DRM_VIRTIO_GPU`` option. >>> +``CONFIG_DRM_VIRTIO_GPU`` option. Otherwise for 3D accelerations you >>> +will need support from Mesa configured for whichever encapsulation you >>> +need. >>> + >>> +.. list-table:: Guest Requirements >>> + :header-rows: 1 >>> + >>> + * - Mode >>> + - Mesa Version >>> + - Mesa build flags >>> + * - virtio-gpu >>> + - n/a >>> + - n/a >>> + * - virtio-gpu-gl (OpenGL pass-through) >>> + - 20.3.0+ >>> + - -Dgallium-drivers=virgl >>> + * - virtio-gpu-gl (rutabaga/gfxstream) >>> + - 24.3.0+ >>> + - -Dvulkan-drivers=gfxstream >>> + * - virtio-gpu-gl (Vulkan pass-through) >>> + - 24.2+ >>> + - -Dvulkan-drivers=virtio >>> + * - virtio-gpu-gl (vDRM native context/AMD) >>> + - 25.0.0+ >>> + - -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true >>> + * - virtio-gpu-gl (vDRM native context/Freedreno) >>> + - 23.1.0+ >>> + - -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno >>> + * - virtio-gpu-gl (vDRM native context/Intel i915) >>> + - `mr29870`_ >>> + - -Dgallium-drivers=iris -Dvulkan-drivers=intel -Dintel-virtio-experimental=true >>> + >>> +.. _mr29870: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 >> >> I feel the dependency information for virglrenderer and Mesa are more >> suited for the Mesa documentation as they are not specific to QEMU and >> potentially useful also for e.g., libkrun and crosvm. > > I think while everything is in so much flux it doesn't hurt to include > in our docs. I don't know if mesa currently has a dedicated page for GPU > virtualisation. Mesa has pages for VirGL and Venus, which can be linked from the respective parts of this documentation. gfxstream is not documented but I think most people will use it only for Android anyway. A documentation for DRM native context will be a nice addition for Mesa. I will not object if you put this information to QEMU documentation though. > > >> >>> + >>> +Further information >>> +................... >> >> I'm not sure about putting the below sections behind "Further >> information". Anyone who want to use this feature will need to know >> the command line described below. >> >>> QEMU virtio-gpu variants >>> ------------------------ > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-01-21 4:26 ` Akihiko Odaki @ 2025-01-26 18:06 ` Dmitry Osipenko 2025-01-27 4:57 ` Akihiko Odaki 0 siblings, 1 reply; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-26 18:06 UTC (permalink / raw) To: Akihiko Odaki, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 1/21/25 07:26, Akihiko Odaki wrote: ... >>> I feel the dependency information for virglrenderer and Mesa are more >>> suited for the Mesa documentation as they are not specific to QEMU and >>> potentially useful also for e.g., libkrun and crosvm. >> >> I think while everything is in so much flux it doesn't hurt to include >> in our docs. I don't know if mesa currently has a dedicated page for GPU >> virtualisation. > > Mesa has pages for VirGL and Venus, which can be linked from the > respective parts of this documentation. gfxstream is not documented but > I think most people will use it only for Android anyway. A documentation > for DRM native context will be a nice addition for Mesa. I will not > object if you put this information to QEMU documentation though. Adding native context doc to Mesa indeed will be a good move, as well as adding links to the Mesa virgl/venus pages in QEMU. RE requirements documentation, it's also a valid point that stuff like build flags should belong to the relevant projects. On the other hand, it's a common headache for a newcoming people to figure everything out from scratch and having more centralized documentation helps. The build requirements aren't cleanly documented anywhere AFAICT, and the requirements also differ based on VMM. I'll update and keep this patch in v6, the requirements info should stay actual for a next couple years IMO. Let's discuss it further in v6 if more objections will arise. -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-01-26 18:06 ` Dmitry Osipenko @ 2025-01-27 4:57 ` Akihiko Odaki 2025-02-02 22:08 ` Dmitry Osipenko 0 siblings, 1 reply; 28+ messages in thread From: Akihiko Odaki @ 2025-01-27 4:57 UTC (permalink / raw) To: Dmitry Osipenko, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2025/01/27 3:06, Dmitry Osipenko wrote: > On 1/21/25 07:26, Akihiko Odaki wrote: > ... >>>> I feel the dependency information for virglrenderer and Mesa are more >>>> suited for the Mesa documentation as they are not specific to QEMU and >>>> potentially useful also for e.g., libkrun and crosvm. >>> >>> I think while everything is in so much flux it doesn't hurt to include >>> in our docs. I don't know if mesa currently has a dedicated page for GPU >>> virtualisation. >> >> Mesa has pages for VirGL and Venus, which can be linked from the >> respective parts of this documentation. gfxstream is not documented but >> I think most people will use it only for Android anyway. A documentation >> for DRM native context will be a nice addition for Mesa. I will not >> object if you put this information to QEMU documentation though. > > Adding native context doc to Mesa indeed will be a good move, as well as > adding links to the Mesa virgl/venus pages in QEMU. > > RE requirements documentation, it's also a valid point that stuff like > build flags should belong to the relevant projects. On the other hand, > it's a common headache for a newcoming people to figure everything out > from scratch and having more centralized documentation helps. The build > requirements aren't cleanly documented anywhere AFAICT, and the > requirements also differ based on VMM. I'll update and keep this patch > in v6, the requirements info should stay actual for a next couple years > IMO. Let's discuss it further in v6 if more objections will arise. > I think it's fine to require one click to reach the relevant documentation. How do the requirements described here vary with VMM? I'm not entirely sure the documentation will stay as is for that long. The requirements of Intel native context refer to merge requests that can be merged sooner or later. Asahi may need more updates if you document it too because its DRM ABI is still unstable. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-01-27 4:57 ` Akihiko Odaki @ 2025-02-02 22:08 ` Dmitry Osipenko 2025-02-03 5:31 ` Akihiko Odaki 0 siblings, 1 reply; 28+ messages in thread From: Dmitry Osipenko @ 2025-02-02 22:08 UTC (permalink / raw) To: Akihiko Odaki, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 1/27/25 07:57, Akihiko Odaki wrote: > On 2025/01/27 3:06, Dmitry Osipenko wrote: >> On 1/21/25 07:26, Akihiko Odaki wrote: >> ... >>>>> I feel the dependency information for virglrenderer and Mesa are more >>>>> suited for the Mesa documentation as they are not specific to QEMU and >>>>> potentially useful also for e.g., libkrun and crosvm. >>>> >>>> I think while everything is in so much flux it doesn't hurt to include >>>> in our docs. I don't know if mesa currently has a dedicated page for >>>> GPU >>>> virtualisation. >>> >>> Mesa has pages for VirGL and Venus, which can be linked from the >>> respective parts of this documentation. gfxstream is not documented but >>> I think most people will use it only for Android anyway. A documentation >>> for DRM native context will be a nice addition for Mesa. I will not >>> object if you put this information to QEMU documentation though. >> >> Adding native context doc to Mesa indeed will be a good move, as well as >> adding links to the Mesa virgl/venus pages in QEMU. >> >> RE requirements documentation, it's also a valid point that stuff like >> build flags should belong to the relevant projects. On the other hand, >> it's a common headache for a newcoming people to figure everything out >> from scratch and having more centralized documentation helps. The build >> requirements aren't cleanly documented anywhere AFAICT, and the >> requirements also differ based on VMM. I'll update and keep this patch >> in v6, the requirements info should stay actual for a next couple years >> IMO. Let's discuss it further in v6 if more objections will arise. >> > > I think it's fine to require one click to reach the relevant documentation. > > How do the requirements described here vary with VMM? Requirements don't vary much. For example virglrenderer minigbm support is mandatory for crosvm, while for QEMU it's not. > I'm not entirely sure the documentation will stay as is for that long. > The requirements of Intel native context refer to merge requests that > can be merged sooner or later. Asahi may need more updates if you > document it too because its DRM ABI is still unstable. The unstable parts of course will need to be updated sooner, but the stable should be solid for years. I expect that about a year later requirements will need to be revisited. -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-02-02 22:08 ` Dmitry Osipenko @ 2025-02-03 5:31 ` Akihiko Odaki 2025-02-05 17:40 ` Dmitry Osipenko 0 siblings, 1 reply; 28+ messages in thread From: Akihiko Odaki @ 2025-02-03 5:31 UTC (permalink / raw) To: Dmitry Osipenko, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2025/02/03 7:08, Dmitry Osipenko wrote: > On 1/27/25 07:57, Akihiko Odaki wrote: >> On 2025/01/27 3:06, Dmitry Osipenko wrote: >>> On 1/21/25 07:26, Akihiko Odaki wrote: >>> ... >>>>>> I feel the dependency information for virglrenderer and Mesa are more >>>>>> suited for the Mesa documentation as they are not specific to QEMU and >>>>>> potentially useful also for e.g., libkrun and crosvm. >>>>> >>>>> I think while everything is in so much flux it doesn't hurt to include >>>>> in our docs. I don't know if mesa currently has a dedicated page for >>>>> GPU >>>>> virtualisation. >>>> >>>> Mesa has pages for VirGL and Venus, which can be linked from the >>>> respective parts of this documentation. gfxstream is not documented but >>>> I think most people will use it only for Android anyway. A documentation >>>> for DRM native context will be a nice addition for Mesa. I will not >>>> object if you put this information to QEMU documentation though. >>> >>> Adding native context doc to Mesa indeed will be a good move, as well as >>> adding links to the Mesa virgl/venus pages in QEMU. >>> >>> RE requirements documentation, it's also a valid point that stuff like >>> build flags should belong to the relevant projects. On the other hand, >>> it's a common headache for a newcoming people to figure everything out >>> from scratch and having more centralized documentation helps. The build >>> requirements aren't cleanly documented anywhere AFAICT, and the >>> requirements also differ based on VMM. I'll update and keep this patch >>> in v6, the requirements info should stay actual for a next couple years >>> IMO. Let's discuss it further in v6 if more objections will arise. >>> >> >> I think it's fine to require one click to reach the relevant documentation. >> >> How do the requirements described here vary with VMM? > > Requirements don't vary much. For example virglrenderer minigbm support > is mandatory for crosvm, while for QEMU it's not. Is that true? It seems that virglrenderer uses builds without minigbm support to run tests on GitLab CI. Anyway, if there is any variance in the build procedure, that may justify having a separate build instruction in QEMU tree to avoid confusion. Otherwise, it's better to have a documentation shared with other VMMs. > >> I'm not entirely sure the documentation will stay as is for that long. >> The requirements of Intel native context refer to merge requests that >> can be merged sooner or later. Asahi may need more updates if you >> document it too because its DRM ABI is still unstable. > > The unstable parts of course will need to be updated sooner, but the > stable should be solid for years. I expect that about a year later > requirements will need to be revisited. > It will be some burden in the future. Now you are adding this documentation just for QEMU, but crosvm and libkrun may gain similar documentation. The DRM native context support for Intel and Asahi is in development, and I guess nvk will support it someday. So, a very rough estimation of future documentation updates will be: (number of VMMs) * (number of DRM native contexts in development) = 3 * 3 = 9 That's manageable but suboptimal. Regards, Akihiko Odaki ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-02-03 5:31 ` Akihiko Odaki @ 2025-02-05 17:40 ` Dmitry Osipenko 2025-02-06 5:41 ` Akihiko Odaki 0 siblings, 1 reply; 28+ messages in thread From: Dmitry Osipenko @ 2025-02-05 17:40 UTC (permalink / raw) To: Akihiko Odaki, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2/3/25 08:31, Akihiko Odaki wrote: ... >> Requirements don't vary much. For example virglrenderer minigbm support >> is mandatory for crosvm, while for QEMU it's not. > > Is that true? It seems that virglrenderer uses builds without minigbm > support to run tests on GitLab CI. CI is running in a headless mode using software renderer. For a full-featured crosvm support running on a baremetal, minigbm should be needed, along with other downstream features. > Anyway, if there is any variance in the build procedure, that may > justify having a separate build instruction in QEMU tree to avoid > confusion. Otherwise, it's better to have a documentation shared with > other VMMs. > >> >>> I'm not entirely sure the documentation will stay as is for that long. >>> The requirements of Intel native context refer to merge requests that >>> can be merged sooner or later. Asahi may need more updates if you >>> document it too because its DRM ABI is still unstable. >> >> The unstable parts of course will need to be updated sooner, but the >> stable should be solid for years. I expect that about a year later >> requirements will need to be revisited. >> > > It will be some burden in the future. Now you are adding this > documentation just for QEMU, but crosvm and libkrun may gain similar > documentation. The DRM native context support for Intel and Asahi is in > development, and I guess nvk will support it someday. > > So, a very rough estimation of future documentation updates will be: > (number of VMMs) * (number of DRM native contexts in development) > = 3 * 3 > = 9 > > That's manageable but suboptimal. I don't mind deferring the doc addition if that's preferred. Either way is fine with me. Yet it's better to have doc than not. In my view crosvm and libkrun exist separately from QEMU, they serve a different purpose. Majority of QEMU users likely never heard about those other VMMs. A unified doc won't be a worthwhile effort, IMO. -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-02-05 17:40 ` Dmitry Osipenko @ 2025-02-06 5:41 ` Akihiko Odaki 2025-02-09 21:03 ` Dmitry Osipenko 0 siblings, 1 reply; 28+ messages in thread From: Akihiko Odaki @ 2025-02-06 5:41 UTC (permalink / raw) To: Dmitry Osipenko, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2025/02/06 2:40, Dmitry Osipenko wrote: > On 2/3/25 08:31, Akihiko Odaki wrote: > ... >>> Requirements don't vary much. For example virglrenderer minigbm support >>> is mandatory for crosvm, while for QEMU it's not. >> >> Is that true? It seems that virglrenderer uses builds without minigbm >> support to run tests on GitLab CI. > > CI is running in a headless mode using software renderer. For a > full-featured crosvm support running on a baremetal, minigbm should be > needed, along with other downstream features. That makes sense. Based on your input, for QEMU, I don't think we need a separate documentation to describe libvirglrenderer's build flags though crosvm should have some documentation saying it requires minigbm. > >> Anyway, if there is any variance in the build procedure, that may >> justify having a separate build instruction in QEMU tree to avoid >> confusion. Otherwise, it's better to have a documentation shared with >> other VMMs. >> >>> >>>> I'm not entirely sure the documentation will stay as is for that long. >>>> The requirements of Intel native context refer to merge requests that >>>> can be merged sooner or later. Asahi may need more updates if you >>>> document it too because its DRM ABI is still unstable. >>> >>> The unstable parts of course will need to be updated sooner, but the >>> stable should be solid for years. I expect that about a year later >>> requirements will need to be revisited. >>> >> >> It will be some burden in the future. Now you are adding this >> documentation just for QEMU, but crosvm and libkrun may gain similar >> documentation. The DRM native context support for Intel and Asahi is in >> development, and I guess nvk will support it someday. >> >> So, a very rough estimation of future documentation updates will be: >> (number of VMMs) * (number of DRM native contexts in development) >> = 3 * 3 >> = 9 >> >> That's manageable but suboptimal. > > I don't mind deferring the doc addition if that's preferred. Either way > is fine with me. Yet it's better to have doc than not. My suggestion is not to defer the addition, but to add it to Mesa, which does not require deferring. > > In my view crosvm and libkrun exist separately from QEMU, they serve a > different purpose. Majority of QEMU users likely never heard about those > other VMMs. A unified doc won't be a worthwhile effort, IMO. > When evaluating the utility of a unified documentation, Whether the majority of Mesa/Virgl users care VMMs other than QEMU matters more. And I think it is true; libkrun and crosvm are excellent options for graphics-accelerated VMs. If we have a unified documentation, any VM can point to it for the build instruction of Mesa and virglrenderer. Once that's done, QEMU users who want graphics acceleration can take the following steps: 1. See docs/system/devices/virtio-gpu.rst 2. Figure out that they need Mesa and virglrenderer 3. Click the link to the unified documentation 4. Build Mesa and virglrenderer accordingly No other VMMs will bother them in this procedure. Regards, Akihiko Odaki ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-02-06 5:41 ` Akihiko Odaki @ 2025-02-09 21:03 ` Dmitry Osipenko 2025-02-13 4:32 ` Akihiko Odaki 0 siblings, 1 reply; 28+ messages in thread From: Dmitry Osipenko @ 2025-02-09 21:03 UTC (permalink / raw) To: Akihiko Odaki, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2/6/25 08:41, Akihiko Odaki wrote: > On 2025/02/06 2:40, Dmitry Osipenko wrote: >> On 2/3/25 08:31, Akihiko Odaki wrote: >> ... >>>> Requirements don't vary much. For example virglrenderer minigbm support >>>> is mandatory for crosvm, while for QEMU it's not. >>> >>> Is that true? It seems that virglrenderer uses builds without minigbm >>> support to run tests on GitLab CI. >> >> CI is running in a headless mode using software renderer. For a >> full-featured crosvm support running on a baremetal, minigbm should be >> needed, along with other downstream features. > > That makes sense. > > Based on your input, for QEMU, I don't think we need a separate > documentation to describe libvirglrenderer's build flags though crosvm > should have some documentation saying it requires minigbm. > >> >>> Anyway, if there is any variance in the build procedure, that may >>> justify having a separate build instruction in QEMU tree to avoid >>> confusion. Otherwise, it's better to have a documentation shared with >>> other VMMs. >>> >>>> >>>>> I'm not entirely sure the documentation will stay as is for that long. >>>>> The requirements of Intel native context refer to merge requests that >>>>> can be merged sooner or later. Asahi may need more updates if you >>>>> document it too because its DRM ABI is still unstable. >>>> >>>> The unstable parts of course will need to be updated sooner, but the >>>> stable should be solid for years. I expect that about a year later >>>> requirements will need to be revisited. >>>> >>> >>> It will be some burden in the future. Now you are adding this >>> documentation just for QEMU, but crosvm and libkrun may gain similar >>> documentation. The DRM native context support for Intel and Asahi is in >>> development, and I guess nvk will support it someday. >>> >>> So, a very rough estimation of future documentation updates will be: >>> (number of VMMs) * (number of DRM native contexts in development) >>> = 3 * 3 >>> = 9 >>> >>> That's manageable but suboptimal. >> >> I don't mind deferring the doc addition if that's preferred. Either way >> is fine with me. Yet it's better to have doc than not. > > My suggestion is not to defer the addition, but to add it to Mesa, which > does not require deferring. > >> >> In my view crosvm and libkrun exist separately from QEMU, they serve a >> different purpose. Majority of QEMU users likely never heard about those >> other VMMs. A unified doc won't be a worthwhile effort, IMO. >> > > When evaluating the utility of a unified documentation, Whether the > majority of Mesa/Virgl users care VMMs other than QEMU matters more. And > I think it is true; libkrun and crosvm are excellent options for > graphics-accelerated VMs. > > If we have a unified documentation, any VM can point to it for the build > instruction of Mesa and virglrenderer. Once that's done, QEMU users who > want graphics acceleration can take the following steps: > 1. See docs/system/devices/virtio-gpu.rst > 2. Figure out that they need Mesa and virglrenderer > 3. Click the link to the unified documentation > 4. Build Mesa and virglrenderer accordingly > > No other VMMs will bother them in this procedure. Will see. For the starter, adding example build flags to QEMU doesn't hurt, it's a very minimal information. Later on, if and when all relevant Mesa/virglrenderer doc pages will appear, it won't be a problem replace QEMU flags with the links. Please let's do it step-by-step, one step at a time :) -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-02-09 21:03 ` Dmitry Osipenko @ 2025-02-13 4:32 ` Akihiko Odaki 2025-02-18 6:27 ` Dmitry Osipenko 0 siblings, 1 reply; 28+ messages in thread From: Akihiko Odaki @ 2025-02-13 4:32 UTC (permalink / raw) To: Dmitry Osipenko, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2025/02/10 6:03, Dmitry Osipenko wrote: > On 2/6/25 08:41, Akihiko Odaki wrote: >> On 2025/02/06 2:40, Dmitry Osipenko wrote: >>> On 2/3/25 08:31, Akihiko Odaki wrote: >>> ... >>>>> Requirements don't vary much. For example virglrenderer minigbm support >>>>> is mandatory for crosvm, while for QEMU it's not. >>>> >>>> Is that true? It seems that virglrenderer uses builds without minigbm >>>> support to run tests on GitLab CI. >>> >>> CI is running in a headless mode using software renderer. For a >>> full-featured crosvm support running on a baremetal, minigbm should be >>> needed, along with other downstream features. >> >> That makes sense. >> >> Based on your input, for QEMU, I don't think we need a separate >> documentation to describe libvirglrenderer's build flags though crosvm >> should have some documentation saying it requires minigbm. >> >>> >>>> Anyway, if there is any variance in the build procedure, that may >>>> justify having a separate build instruction in QEMU tree to avoid >>>> confusion. Otherwise, it's better to have a documentation shared with >>>> other VMMs. >>>> >>>>> >>>>>> I'm not entirely sure the documentation will stay as is for that long. >>>>>> The requirements of Intel native context refer to merge requests that >>>>>> can be merged sooner or later. Asahi may need more updates if you >>>>>> document it too because its DRM ABI is still unstable. >>>>> >>>>> The unstable parts of course will need to be updated sooner, but the >>>>> stable should be solid for years. I expect that about a year later >>>>> requirements will need to be revisited. >>>>> >>>> >>>> It will be some burden in the future. Now you are adding this >>>> documentation just for QEMU, but crosvm and libkrun may gain similar >>>> documentation. The DRM native context support for Intel and Asahi is in >>>> development, and I guess nvk will support it someday. >>>> >>>> So, a very rough estimation of future documentation updates will be: >>>> (number of VMMs) * (number of DRM native contexts in development) >>>> = 3 * 3 >>>> = 9 >>>> >>>> That's manageable but suboptimal. >>> >>> I don't mind deferring the doc addition if that's preferred. Either way >>> is fine with me. Yet it's better to have doc than not. >> >> My suggestion is not to defer the addition, but to add it to Mesa, which >> does not require deferring. >> >>> >>> In my view crosvm and libkrun exist separately from QEMU, they serve a >>> different purpose. Majority of QEMU users likely never heard about those >>> other VMMs. A unified doc won't be a worthwhile effort, IMO. >>> >> >> When evaluating the utility of a unified documentation, Whether the >> majority of Mesa/Virgl users care VMMs other than QEMU matters more. And >> I think it is true; libkrun and crosvm are excellent options for >> graphics-accelerated VMs. >> >> If we have a unified documentation, any VM can point to it for the build >> instruction of Mesa and virglrenderer. Once that's done, QEMU users who >> want graphics acceleration can take the following steps: >> 1. See docs/system/devices/virtio-gpu.rst >> 2. Figure out that they need Mesa and virglrenderer >> 3. Click the link to the unified documentation >> 4. Build Mesa and virglrenderer accordingly >> >> No other VMMs will bother them in this procedure. > > Will see. For the starter, adding example build flags to QEMU doesn't > hurt, it's a very minimal information. Later on, if and when all > relevant Mesa/virglrenderer doc pages will appear, it won't be a problem > replace QEMU flags with the links. Please let's do it step-by-step, one > step at a time :) > To be honest, I'm concerned that you may be using QEMU as a staging tree for Mesa/virglrenderer. Submitting a documentation to QEMU as a preparation to submit one to Mesa is not OK. You shouldn't submit a documentation to QEMU if upstream Mesa developers rejects it because it contains too little information. It may not hurt QEMU, but still lacks a valid reasoning. Mesa should have more people who care virtio-gpu as there are people using other VMMs and perhaps it may be difficult to convince them to add a documentation like this. It is still not a good idea to workaround that by adding one to QEMU. The documentation submitted to QEMU is mostly reviewed only by me, who barely used Venus and DRM native contexts, which is not a good sign. Getting reviewed by more people is one of the advantage of open-source contribution after all so let's keep it. I can help you add a documentation to Mesa by reviewing and supporting one if you want, but I cannot support adding one to QEMU if it's done to avoid a potential challenge to add it to Mesa. Regards, Akihiko Odaki ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-02-13 4:32 ` Akihiko Odaki @ 2025-02-18 6:27 ` Dmitry Osipenko 2025-02-18 6:35 ` Dmitry Osipenko 2025-02-27 6:40 ` Akihiko Odaki 0 siblings, 2 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-02-18 6:27 UTC (permalink / raw) To: Akihiko Odaki, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2/13/25 07:32, Akihiko Odaki wrote: > On 2025/02/10 6:03, Dmitry Osipenko wrote: >> On 2/6/25 08:41, Akihiko Odaki wrote: >>> On 2025/02/06 2:40, Dmitry Osipenko wrote: >>>> On 2/3/25 08:31, Akihiko Odaki wrote: >>>> ... >>>>>> Requirements don't vary much. For example virglrenderer minigbm >>>>>> support >>>>>> is mandatory for crosvm, while for QEMU it's not. >>>>> >>>>> Is that true? It seems that virglrenderer uses builds without minigbm >>>>> support to run tests on GitLab CI. >>>> >>>> CI is running in a headless mode using software renderer. For a >>>> full-featured crosvm support running on a baremetal, minigbm should be >>>> needed, along with other downstream features. >>> >>> That makes sense. >>> >>> Based on your input, for QEMU, I don't think we need a separate >>> documentation to describe libvirglrenderer's build flags though crosvm >>> should have some documentation saying it requires minigbm. >>> >>>> >>>>> Anyway, if there is any variance in the build procedure, that may >>>>> justify having a separate build instruction in QEMU tree to avoid >>>>> confusion. Otherwise, it's better to have a documentation shared with >>>>> other VMMs. >>>>> >>>>>> >>>>>>> I'm not entirely sure the documentation will stay as is for that >>>>>>> long. >>>>>>> The requirements of Intel native context refer to merge requests >>>>>>> that >>>>>>> can be merged sooner or later. Asahi may need more updates if you >>>>>>> document it too because its DRM ABI is still unstable. >>>>>> >>>>>> The unstable parts of course will need to be updated sooner, but the >>>>>> stable should be solid for years. I expect that about a year later >>>>>> requirements will need to be revisited. >>>>>> >>>>> >>>>> It will be some burden in the future. Now you are adding this >>>>> documentation just for QEMU, but crosvm and libkrun may gain similar >>>>> documentation. The DRM native context support for Intel and Asahi >>>>> is in >>>>> development, and I guess nvk will support it someday. >>>>> >>>>> So, a very rough estimation of future documentation updates will be: >>>>> (number of VMMs) * (number of DRM native contexts in development) >>>>> = 3 * 3 >>>>> = 9 >>>>> >>>>> That's manageable but suboptimal. >>>> >>>> I don't mind deferring the doc addition if that's preferred. Either way >>>> is fine with me. Yet it's better to have doc than not. >>> >>> My suggestion is not to defer the addition, but to add it to Mesa, which >>> does not require deferring. >>> >>>> >>>> In my view crosvm and libkrun exist separately from QEMU, they serve a >>>> different purpose. Majority of QEMU users likely never heard about >>>> those >>>> other VMMs. A unified doc won't be a worthwhile effort, IMO. >>>> >>> >>> When evaluating the utility of a unified documentation, Whether the >>> majority of Mesa/Virgl users care VMMs other than QEMU matters more. And >>> I think it is true; libkrun and crosvm are excellent options for >>> graphics-accelerated VMs. >>> >>> If we have a unified documentation, any VM can point to it for the build >>> instruction of Mesa and virglrenderer. Once that's done, QEMU users who >>> want graphics acceleration can take the following steps: >>> 1. See docs/system/devices/virtio-gpu.rst >>> 2. Figure out that they need Mesa and virglrenderer >>> 3. Click the link to the unified documentation >>> 4. Build Mesa and virglrenderer accordingly >>> >>> No other VMMs will bother them in this procedure. >> >> Will see. For the starter, adding example build flags to QEMU doesn't >> hurt, it's a very minimal information. Later on, if and when all >> relevant Mesa/virglrenderer doc pages will appear, it won't be a problem >> replace QEMU flags with the links. Please let's do it step-by-step, one >> step at a time :) >> > > To be honest, I'm concerned that you may be using QEMU as a staging tree > for Mesa/virglrenderer. Submitting a documentation to QEMU as a > preparation to submit one to Mesa is not OK. > > You shouldn't submit a documentation to QEMU if upstream > Mesa developers rejects it because it contains too little information. > It may not hurt QEMU, but still lacks a valid reasoning. Don't understand what you're talking about here. I may remind that this is not my QEMU doc patch to begin with, hence it has nothing to do with Mesa nor with virglrenderer. Alex wants to help QEMU users by adding more QEMU documentation. Maybe you're also not very familiar with the Mesa development process. This is okay, no problems. > Mesa should have more people who care virtio-gpu as there are people > using other VMMs and perhaps it may be difficult to convince them to add > a documentation like this. It is still not a good idea to workaround > that by adding one to QEMU. The documentation submitted to QEMU is > mostly reviewed only by me, who barely used Venus and DRM native > contexts, which is not a good sign. Getting reviewed by more people is > one of the advantage of open-source contribution after all so let's keep > it. > > I can help you add a documentation to Mesa by reviewing and supporting > one if you want, but I cannot support adding one to QEMU if it's done to > avoid a potential challenge to add it to Mesa. Thanks a lot! More reviewers always good to have, will definitely ping you. Right now writing more Mesa documentation isn't a priority, hence will take time to get to it. -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-02-18 6:27 ` Dmitry Osipenko @ 2025-02-18 6:35 ` Dmitry Osipenko 2025-02-27 6:40 ` Akihiko Odaki 1 sibling, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-02-18 6:35 UTC (permalink / raw) To: Akihiko Odaki, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2/18/25 09:27, Dmitry Osipenko wrote: >> To be honest, I'm concerned that you may be using QEMU as a staging tree >> for Mesa/virglrenderer. Submitting a documentation to QEMU as a >> preparation to submit one to Mesa is not OK. >> >> You shouldn't submit a documentation to QEMU if upstream >> Mesa developers rejects it because it contains too little information. >> It may not hurt QEMU, but still lacks a valid reasoning. > Don't understand what you're talking about here. I may remind that this > is not my QEMU doc patch to begin with, hence it has nothing to do with > Mesa nor with virglrenderer. Alex wants to help QEMU users by adding > more QEMU documentation. > > Maybe you're also not very familiar with the Mesa development process. > This is okay, no problems. > >> Mesa should have more people who care virtio-gpu as there are people >> using other VMMs and perhaps it may be difficult to convince them to add >> a documentation like this. It is still not a good idea to workaround >> that by adding one to QEMU. The documentation submitted to QEMU is >> mostly reviewed only by me, who barely used Venus and DRM native >> contexts, which is not a good sign. Getting reviewed by more people is >> one of the advantage of open-source contribution after all so let's keep >> it. >> >> I can help you add a documentation to Mesa by reviewing and supporting >> one if you want, but I cannot support adding one to QEMU if it's done to >> avoid a potential challenge to add it to Mesa. > Thanks a lot! More reviewers always good to have, will definitely ping > you. Right now writing more Mesa documentation isn't a priority, hence > will take time to get to it. To finish this thread, I'll repeat what was said on the v8 that I'll drop the build flags from the QEMU doc since they are bothering you too much and your voice has a high value. Thanks again for helping with the reviewing, very appreciate it! :) -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation 2025-02-18 6:27 ` Dmitry Osipenko 2025-02-18 6:35 ` Dmitry Osipenko @ 2025-02-27 6:40 ` Akihiko Odaki 1 sibling, 0 replies; 28+ messages in thread From: Akihiko Odaki @ 2025-02-27 6:40 UTC (permalink / raw) To: Dmitry Osipenko, Alex Bennée Cc: Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 2025/02/18 15:27, Dmitry Osipenko wrote: > On 2/13/25 07:32, Akihiko Odaki wrote: >> On 2025/02/10 6:03, Dmitry Osipenko wrote: >>> On 2/6/25 08:41, Akihiko Odaki wrote: >>>> On 2025/02/06 2:40, Dmitry Osipenko wrote: >>>>> On 2/3/25 08:31, Akihiko Odaki wrote: >>>>> ... >>>>>>> Requirements don't vary much. For example virglrenderer minigbm >>>>>>> support >>>>>>> is mandatory for crosvm, while for QEMU it's not. >>>>>> >>>>>> Is that true? It seems that virglrenderer uses builds without minigbm >>>>>> support to run tests on GitLab CI. >>>>> >>>>> CI is running in a headless mode using software renderer. For a >>>>> full-featured crosvm support running on a baremetal, minigbm should be >>>>> needed, along with other downstream features. >>>> >>>> That makes sense. >>>> >>>> Based on your input, for QEMU, I don't think we need a separate >>>> documentation to describe libvirglrenderer's build flags though crosvm >>>> should have some documentation saying it requires minigbm. >>>> >>>>> >>>>>> Anyway, if there is any variance in the build procedure, that may >>>>>> justify having a separate build instruction in QEMU tree to avoid >>>>>> confusion. Otherwise, it's better to have a documentation shared with >>>>>> other VMMs. >>>>>> >>>>>>> >>>>>>>> I'm not entirely sure the documentation will stay as is for that >>>>>>>> long. >>>>>>>> The requirements of Intel native context refer to merge requests >>>>>>>> that >>>>>>>> can be merged sooner or later. Asahi may need more updates if you >>>>>>>> document it too because its DRM ABI is still unstable. >>>>>>> >>>>>>> The unstable parts of course will need to be updated sooner, but the >>>>>>> stable should be solid for years. I expect that about a year later >>>>>>> requirements will need to be revisited. >>>>>>> >>>>>> >>>>>> It will be some burden in the future. Now you are adding this >>>>>> documentation just for QEMU, but crosvm and libkrun may gain similar >>>>>> documentation. The DRM native context support for Intel and Asahi >>>>>> is in >>>>>> development, and I guess nvk will support it someday. >>>>>> >>>>>> So, a very rough estimation of future documentation updates will be: >>>>>> (number of VMMs) * (number of DRM native contexts in development) >>>>>> = 3 * 3 >>>>>> = 9 >>>>>> >>>>>> That's manageable but suboptimal. >>>>> >>>>> I don't mind deferring the doc addition if that's preferred. Either way >>>>> is fine with me. Yet it's better to have doc than not. >>>> >>>> My suggestion is not to defer the addition, but to add it to Mesa, which >>>> does not require deferring. >>>> >>>>> >>>>> In my view crosvm and libkrun exist separately from QEMU, they serve a >>>>> different purpose. Majority of QEMU users likely never heard about >>>>> those >>>>> other VMMs. A unified doc won't be a worthwhile effort, IMO. >>>>> >>>> >>>> When evaluating the utility of a unified documentation, Whether the >>>> majority of Mesa/Virgl users care VMMs other than QEMU matters more. And >>>> I think it is true; libkrun and crosvm are excellent options for >>>> graphics-accelerated VMs. >>>> >>>> If we have a unified documentation, any VM can point to it for the build >>>> instruction of Mesa and virglrenderer. Once that's done, QEMU users who >>>> want graphics acceleration can take the following steps: >>>> 1. See docs/system/devices/virtio-gpu.rst >>>> 2. Figure out that they need Mesa and virglrenderer >>>> 3. Click the link to the unified documentation >>>> 4. Build Mesa and virglrenderer accordingly >>>> >>>> No other VMMs will bother them in this procedure. >>> >>> Will see. For the starter, adding example build flags to QEMU doesn't >>> hurt, it's a very minimal information. Later on, if and when all >>> relevant Mesa/virglrenderer doc pages will appear, it won't be a problem >>> replace QEMU flags with the links. Please let's do it step-by-step, one >>> step at a time :) >>> >> >> To be honest, I'm concerned that you may be using QEMU as a staging tree >> for Mesa/virglrenderer. Submitting a documentation to QEMU as a >> preparation to submit one to Mesa is not OK. >> >> You shouldn't submit a documentation to QEMU if upstream >> Mesa developers rejects it because it contains too little information. >> It may not hurt QEMU, but still lacks a valid reasoning. > > Don't understand what you're talking about here. I may remind that this > is not my QEMU doc patch to begin with, hence it has nothing to do with > Mesa nor with virglrenderer. Alex wants to help QEMU users by adding > more QEMU documentation. I understand Alex and you intend to help QEMU users, but sometimes a change to help QEMU users is better to be done in the upstream of its dependency. For example, when I submitted a patch to suppress a sanitizer warning in the past, I was asked if it may be better to propose a change of the sanitizer behavior instead of changing QEMU code. We eventually concluded we should change our code at that time, but it could have turned out otherwise. It is no different from the normal review process; a submitter proposes a solution, a reviewer suggests alternatives, and both figure out the optimal one in the discussion. > > Maybe you're also not very familiar with the Mesa development process. > This is okay, no problems. > >> Mesa should have more people who care virtio-gpu as there are people >> using other VMMs and perhaps it may be difficult to convince them to add >> a documentation like this. It is still not a good idea to workaround >> that by adding one to QEMU. The documentation submitted to QEMU is >> mostly reviewed only by me, who barely used Venus and DRM native >> contexts, which is not a good sign. Getting reviewed by more people is >> one of the advantage of open-source contribution after all so let's keep >> it. >> >> I can help you add a documentation to Mesa by reviewing and supporting >> one if you want, but I cannot support adding one to QEMU if it's done to >> avoid a potential challenge to add it to Mesa. > > Thanks a lot! More reviewers always good to have, will definitely ping > you. Right now writing more Mesa documentation isn't a priority, hence > will take time to get to it. > I appreciate your contribution to the documentation too. Once there was no documentation, but Gurchetan Singh added one along with their Rutabaga patches. With your change, the documentation will be comprehensive also for virglrenderer. Regards, Akihiko Odaki ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <871pwxqyr3.fsf@draig.linaro.org>]
* Re: [PATCH v5 0/8] Support virtio-gpu DRM native context [not found] ` <871pwxqyr3.fsf@draig.linaro.org> @ 2025-01-22 12:25 ` Dmitry Osipenko 0 siblings, 0 replies; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-22 12:25 UTC (permalink / raw) To: Alex Bennée Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 1/20/25 18:41, Alex Bennée wrote: > Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > >> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >> >> Contarary to Virgl and Venus contexts that mediates high level GFX APIs, >> DRM native context [1] mediates lower level kernel driver UAPI, which >> reflects in a less CPU overhead and less/simpler code needed to support it. >> DRM context consists of a host and guest parts that have to be implemented >> for each GPU driver. On a guest side, DRM context presents a virtual GPU as >> a real/native host GPU device for GL/VK applications. >> >> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ >> >> Today there are four known DRM native context drivers existing in a wild: >> >> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >> - AMDGPU, mostly merged into upstreams >> - Intel (i915), merge requests are opened > > With the patch for the build failure: > > Tested-by: Alex Bennée <alex.bennee@linaro.org> > > Host: > > x86 > Trixie > virglrenderer @ digitx/native-context-iris/a0b1872d252430a2b7f007db9fdbb0526385cfc0 > -display sdl,gl=on > > KVM Guest > > x86 > Trixie > mesa @ digitx/native-context-iris/78b1508c3f06 > > With gtk,gl=on I'm still seeing a lot of screen corruption which mirrors > the terminal an leaves a destructive trail under the mouse cursor. > show-cursor on or off makes no difference. Thank you for the review and testing! I'm looking into that issue. Only some people are hitting it and Pierre-Eric said he had that mirroring issue without using nctx. Still interesting that the bug affects only certain setups and is triggered by nctx. -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 0/8] Support virtio-gpu DRM native context 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko ` (8 preceding siblings ...) [not found] ` <871pwxqyr3.fsf@draig.linaro.org> @ 2025-01-22 17:00 ` Alex Bennée 2025-01-23 11:23 ` Dmitry Osipenko 9 siblings, 1 reply; 28+ messages in thread From: Alex Bennée @ 2025-01-22 17:00 UTC (permalink / raw) To: Dmitry Osipenko Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > This patchset adds DRM native context support to VirtIO-GPU on Qemu. > > Contarary to Virgl and Venus contexts that mediates high level GFX APIs, > DRM native context [1] mediates lower level kernel driver UAPI, which > reflects in a less CPU overhead and less/simpler code needed to support it. > DRM context consists of a host and guest parts that have to be implemented > for each GPU driver. On a guest side, DRM context presents a virtual GPU as > a real/native host GPU device for GL/VK applications. > > [1] https://www.youtube.com/watch?v=9sFP_yddLLQ > > Today there are four known DRM native context drivers existing in a wild: > > - Freedreno (Qualcomm SoC GPUs), completely upstreamed > - AMDGPU, mostly merged into upstreams I tried my AMD system today with: Host: Aarch64 AVA system Trixie virglrenderer @ v1.1.0/99557f5aa130930d11f04ffeb07f3a9aa5963182 -display sdl,gl=on (gtk,gl=on also came up but handled window resizing poorly) KVM Guest Aarch64 Trixie mesa @ main/d27748a76f7dd9236bfcf9ef172dc13b8c0e170f -Dvulkan-drivers=virtio,amd -Dgallium-drivers=virgl,radeonsi -Damdgpu-virtio=true However when I ran vulkan-info --summary KVM faulted with: debian-trixie login: error: kvm run failed Bad address PC=0000ffffb9aa1eb0 X00=0000ffffba0450a4 X01=0000aaaaf7f32400 X02=000000000000013c X03=0000ffffba045098 X04=0000aaaaf7f3253c X05=0000ffffba0451d4 X06=00000000c0016900 X07=000000000000000e X08=0000000000000014 X09=00000000000000ff X10=0000aaaaf7f32500 X11=0000aaaaf7e4d028 X12=0000aaaaf7edbcb0 X13=0000000000000001 X14=000000000000000c X15=0000000000007718 X16=0000ffffb93601f0 X17=0000ffffb9aa1dc0 X18=00000000000076f0 X19=0000aaaaf7f31330 X20=0000aaaaf7f323f0 X21=0000aaaaf7f235e0 X22=000000000000004c X23=0000aaaaf7f2b5e0 X24=0000aaaaf7ee0cb0 X25=00000000000000ff X26=0000000000000076 X27=0000ffffcd2b18a8 X28=0000aaaaf7ee0cb0 X29=0000ffffcd2b0bd0 X30=0000ffffb86c8b98 SP=0000ffffcd2b0bd0 PSTATE=20001000 --C- EL0t QEMU 9.2.50 monitor - type 'help' for more information (qemu) quit Which looks very much like the PFN locking failure. However booting up with venus=on instead works. Could there be any differences in the way device memory is mapped in the two cases? > - Intel (i915), merge requests are opened > - Asahi (Apple SoC GPUs), WIP status > <snip> -- Alex Bennée Virtualisation Tech Lead @ Linaro ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 0/8] Support virtio-gpu DRM native context 2025-01-22 17:00 ` Alex Bennée @ 2025-01-23 11:23 ` Dmitry Osipenko 2025-01-23 11:58 ` Alex Bennée 0 siblings, 1 reply; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-23 11:23 UTC (permalink / raw) To: Alex Bennée Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 1/22/25 20:00, Alex Bennée wrote: > Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > >> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >> >> Contarary to Virgl and Venus contexts that mediates high level GFX APIs, >> DRM native context [1] mediates lower level kernel driver UAPI, which >> reflects in a less CPU overhead and less/simpler code needed to support it. >> DRM context consists of a host and guest parts that have to be implemented >> for each GPU driver. On a guest side, DRM context presents a virtual GPU as >> a real/native host GPU device for GL/VK applications. >> >> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ >> >> Today there are four known DRM native context drivers existing in a wild: >> >> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >> - AMDGPU, mostly merged into upstreams > > I tried my AMD system today with: > > Host: > Aarch64 AVA system > Trixie > virglrenderer @ v1.1.0/99557f5aa130930d11f04ffeb07f3a9aa5963182 > -display sdl,gl=on (gtk,gl=on also came up but handled window resizing > poorly) > > KVM Guest > > Aarch64 > Trixie > mesa @ main/d27748a76f7dd9236bfcf9ef172dc13b8c0e170f > -Dvulkan-drivers=virtio,amd -Dgallium-drivers=virgl,radeonsi -Damdgpu-virtio=true > > However when I ran vulkan-info --summary KVM faulted with: > > debian-trixie login: error: kvm run failed Bad address > PC=0000ffffb9aa1eb0 X00=0000ffffba0450a4 X01=0000aaaaf7f32400 > X02=000000000000013c X03=0000ffffba045098 X04=0000aaaaf7f3253c > X05=0000ffffba0451d4 X06=00000000c0016900 X07=000000000000000e > X08=0000000000000014 X09=00000000000000ff X10=0000aaaaf7f32500 > X11=0000aaaaf7e4d028 X12=0000aaaaf7edbcb0 X13=0000000000000001 > X14=000000000000000c X15=0000000000007718 X16=0000ffffb93601f0 > X17=0000ffffb9aa1dc0 X18=00000000000076f0 X19=0000aaaaf7f31330 > X20=0000aaaaf7f323f0 X21=0000aaaaf7f235e0 X22=000000000000004c > X23=0000aaaaf7f2b5e0 X24=0000aaaaf7ee0cb0 X25=00000000000000ff > X26=0000000000000076 X27=0000ffffcd2b18a8 X28=0000aaaaf7ee0cb0 > X29=0000ffffcd2b0bd0 X30=0000ffffb86c8b98 SP=0000ffffcd2b0bd0 > PSTATE=20001000 --C- EL0t > QEMU 9.2.50 monitor - type 'help' for more information > (qemu) quit > > Which looks very much like the PFN locking failure. However booting up > with venus=on instead works. Could there be any differences in the way > device memory is mapped in the two cases? Memory mapping works exactly the same for nctx and venus. Are you on 6.13 host kernel? -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 0/8] Support virtio-gpu DRM native context 2025-01-23 11:23 ` Dmitry Osipenko @ 2025-01-23 11:58 ` Alex Bennée 2025-01-23 12:37 ` Dmitry Osipenko 0 siblings, 1 reply; 28+ messages in thread From: Alex Bennée @ 2025-01-23 11:58 UTC (permalink / raw) To: Dmitry Osipenko Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > On 1/22/25 20:00, Alex Bennée wrote: >> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: >> >>> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >>> >>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs, >>> DRM native context [1] mediates lower level kernel driver UAPI, which >>> reflects in a less CPU overhead and less/simpler code needed to support it. >>> DRM context consists of a host and guest parts that have to be implemented >>> for each GPU driver. On a guest side, DRM context presents a virtual GPU as >>> a real/native host GPU device for GL/VK applications. >>> >>> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ >>> >>> Today there are four known DRM native context drivers existing in a wild: >>> >>> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >>> - AMDGPU, mostly merged into upstreams >> >> I tried my AMD system today with: >> >> Host: >> Aarch64 AVA system >> Trixie >> virglrenderer @ v1.1.0/99557f5aa130930d11f04ffeb07f3a9aa5963182 >> -display sdl,gl=on (gtk,gl=on also came up but handled window resizing >> poorly) >> >> KVM Guest >> >> Aarch64 >> Trixie >> mesa @ main/d27748a76f7dd9236bfcf9ef172dc13b8c0e170f >> -Dvulkan-drivers=virtio,amd -Dgallium-drivers=virgl,radeonsi -Damdgpu-virtio=true >> >> However when I ran vulkan-info --summary KVM faulted with: >> >> debian-trixie login: error: kvm run failed Bad address >> PC=0000ffffb9aa1eb0 X00=0000ffffba0450a4 X01=0000aaaaf7f32400 >> X02=000000000000013c X03=0000ffffba045098 X04=0000aaaaf7f3253c >> X05=0000ffffba0451d4 X06=00000000c0016900 X07=000000000000000e >> X08=0000000000000014 X09=00000000000000ff X10=0000aaaaf7f32500 >> X11=0000aaaaf7e4d028 X12=0000aaaaf7edbcb0 X13=0000000000000001 >> X14=000000000000000c X15=0000000000007718 X16=0000ffffb93601f0 >> X17=0000ffffb9aa1dc0 X18=00000000000076f0 X19=0000aaaaf7f31330 >> X20=0000aaaaf7f323f0 X21=0000aaaaf7f235e0 X22=000000000000004c >> X23=0000aaaaf7f2b5e0 X24=0000aaaaf7ee0cb0 X25=00000000000000ff >> X26=0000000000000076 X27=0000ffffcd2b18a8 X28=0000aaaaf7ee0cb0 >> X29=0000ffffcd2b0bd0 X30=0000ffffb86c8b98 SP=0000ffffcd2b0bd0 >> PSTATE=20001000 --C- EL0t >> QEMU 9.2.50 monitor - type 'help' for more information >> (qemu) quit >> >> Which looks very much like the PFN locking failure. However booting up >> with venus=on instead works. Could there be any differences in the way >> device memory is mapped in the two cases? > > Memory mapping works exactly the same for nctx and venus. Are you on > 6.13 host kernel? Yes - with the Altra PCI workaround patches on both host and guest kernel. Is there anyway to trace the sharing of device memory on the host so I can verify its an attempt at device access? The PC looks like its in user-space but once this fails the guest is suspended so I can't poke around in its environment. -- Alex Bennée Virtualisation Tech Lead @ Linaro ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 0/8] Support virtio-gpu DRM native context 2025-01-23 11:58 ` Alex Bennée @ 2025-01-23 12:37 ` Dmitry Osipenko 2025-01-27 14:50 ` Alex Bennée 0 siblings, 1 reply; 28+ messages in thread From: Dmitry Osipenko @ 2025-01-23 12:37 UTC (permalink / raw) To: Alex Bennée Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual On 1/23/25 14:58, Alex Bennée wrote: > Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > >> On 1/22/25 20:00, Alex Bennée wrote: >>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: >>> >>>> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >>>> >>>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs, >>>> DRM native context [1] mediates lower level kernel driver UAPI, which >>>> reflects in a less CPU overhead and less/simpler code needed to support it. >>>> DRM context consists of a host and guest parts that have to be implemented >>>> for each GPU driver. On a guest side, DRM context presents a virtual GPU as >>>> a real/native host GPU device for GL/VK applications. >>>> >>>> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ >>>> >>>> Today there are four known DRM native context drivers existing in a wild: >>>> >>>> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >>>> - AMDGPU, mostly merged into upstreams >>> >>> I tried my AMD system today with: >>> >>> Host: >>> Aarch64 AVA system >>> Trixie >>> virglrenderer @ v1.1.0/99557f5aa130930d11f04ffeb07f3a9aa5963182 >>> -display sdl,gl=on (gtk,gl=on also came up but handled window resizing >>> poorly) >>> >>> KVM Guest >>> >>> Aarch64 >>> Trixie >>> mesa @ main/d27748a76f7dd9236bfcf9ef172dc13b8c0e170f >>> -Dvulkan-drivers=virtio,amd -Dgallium-drivers=virgl,radeonsi -Damdgpu-virtio=true >>> >>> However when I ran vulkan-info --summary KVM faulted with: >>> >>> debian-trixie login: error: kvm run failed Bad address >>> PC=0000ffffb9aa1eb0 X00=0000ffffba0450a4 X01=0000aaaaf7f32400 >>> X02=000000000000013c X03=0000ffffba045098 X04=0000aaaaf7f3253c >>> X05=0000ffffba0451d4 X06=00000000c0016900 X07=000000000000000e >>> X08=0000000000000014 X09=00000000000000ff X10=0000aaaaf7f32500 >>> X11=0000aaaaf7e4d028 X12=0000aaaaf7edbcb0 X13=0000000000000001 >>> X14=000000000000000c X15=0000000000007718 X16=0000ffffb93601f0 >>> X17=0000ffffb9aa1dc0 X18=00000000000076f0 X19=0000aaaaf7f31330 >>> X20=0000aaaaf7f323f0 X21=0000aaaaf7f235e0 X22=000000000000004c >>> X23=0000aaaaf7f2b5e0 X24=0000aaaaf7ee0cb0 X25=00000000000000ff >>> X26=0000000000000076 X27=0000ffffcd2b18a8 X28=0000aaaaf7ee0cb0 >>> X29=0000ffffcd2b0bd0 X30=0000ffffb86c8b98 SP=0000ffffcd2b0bd0 >>> PSTATE=20001000 --C- EL0t >>> QEMU 9.2.50 monitor - type 'help' for more information >>> (qemu) quit >>> >>> Which looks very much like the PFN locking failure. However booting up >>> with venus=on instead works. Could there be any differences in the way >>> device memory is mapped in the two cases? >> >> Memory mapping works exactly the same for nctx and venus. Are you on >> 6.13 host kernel? > > Yes - with the Altra PCI workaround patches on both host and guest > kernel. > > Is there anyway to trace the sharing of device memory on the host so I > can verify its an attempt at device access? The PC looks like its in > user-space but once this fails the guest is suspended so I can't poke > around in its environment. I'm adding printk's to kernel in a such cases. Likely there is no other better way to find why it fails. Does your ARM VM and host both use 4k page size? Well, if it's a page refcounting bug on ARM/KMV, then applying [1] to the host driver will make it work and we will know where the problem is. Please try. [1] https://patchwork.kernel.org/project/kvm/patch/20220815095423.11131-1-dmitry.osipenko@collabora.com/ -- Best regards, Dmitry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 0/8] Support virtio-gpu DRM native context 2025-01-23 12:37 ` Dmitry Osipenko @ 2025-01-27 14:50 ` Alex Bennée 0 siblings, 0 replies; 28+ messages in thread From: Alex Bennée @ 2025-01-27 14:50 UTC (permalink / raw) To: Dmitry Osipenko Cc: Akihiko Odaki, Huang Rui, Marc-André Lureau, Philippe Mathieu-Daudé, Gerd Hoffmann, Michael S . Tsirkin, Paolo Bonzini, Gert Wollny, qemu-devel, Gurchetan Singh, Alyssa Ross, Roger Pau Monné, Alex Deucher, Stefano Stabellini, Christian König, Xenia Ragiadakou, Pierre-Eric Pelloux-Prayer, Honglei Huang, Julia Zhang, Chen Jiqian, Rob Clark, Yiwei Zhang, Sergio Lopez Pascual Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > On 1/23/25 14:58, Alex Bennée wrote: >> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: >> >>> On 1/22/25 20:00, Alex Bennée wrote: >>>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: >>>> >>>>> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >>>>> >>>>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs, >>>>> DRM native context [1] mediates lower level kernel driver UAPI, which >>>>> reflects in a less CPU overhead and less/simpler code needed to support it. >>>>> DRM context consists of a host and guest parts that have to be implemented >>>>> for each GPU driver. On a guest side, DRM context presents a virtual GPU as >>>>> a real/native host GPU device for GL/VK applications. >>>>> >>>>> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ >>>>> >>>>> Today there are four known DRM native context drivers existing in a wild: >>>>> >>>>> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >>>>> - AMDGPU, mostly merged into upstreams >>>> >>>> I tried my AMD system today with: >>>> >>>> Host: >>>> Aarch64 AVA system >>>> Trixie >>>> virglrenderer @ v1.1.0/99557f5aa130930d11f04ffeb07f3a9aa5963182 >>>> -display sdl,gl=on (gtk,gl=on also came up but handled window resizing >>>> poorly) >>>> >>>> KVM Guest >>>> >>>> Aarch64 >>>> Trixie >>>> mesa @ main/d27748a76f7dd9236bfcf9ef172dc13b8c0e170f >>>> -Dvulkan-drivers=virtio,amd -Dgallium-drivers=virgl,radeonsi -Damdgpu-virtio=true >>>> >>>> However when I ran vulkan-info --summary KVM faulted with: >>>> >>>> debian-trixie login: error: kvm run failed Bad address >>>> PC=0000ffffb9aa1eb0 X00=0000ffffba0450a4 X01=0000aaaaf7f32400 >>>> X02=000000000000013c X03=0000ffffba045098 X04=0000aaaaf7f3253c >>>> X05=0000ffffba0451d4 X06=00000000c0016900 X07=000000000000000e >>>> X08=0000000000000014 X09=00000000000000ff X10=0000aaaaf7f32500 >>>> X11=0000aaaaf7e4d028 X12=0000aaaaf7edbcb0 X13=0000000000000001 >>>> X14=000000000000000c X15=0000000000007718 X16=0000ffffb93601f0 >>>> X17=0000ffffb9aa1dc0 X18=00000000000076f0 X19=0000aaaaf7f31330 >>>> X20=0000aaaaf7f323f0 X21=0000aaaaf7f235e0 X22=000000000000004c >>>> X23=0000aaaaf7f2b5e0 X24=0000aaaaf7ee0cb0 X25=00000000000000ff >>>> X26=0000000000000076 X27=0000ffffcd2b18a8 X28=0000aaaaf7ee0cb0 >>>> X29=0000ffffcd2b0bd0 X30=0000ffffb86c8b98 SP=0000ffffcd2b0bd0 >>>> PSTATE=20001000 --C- EL0t >>>> QEMU 9.2.50 monitor - type 'help' for more information >>>> (qemu) quit >>>> >>>> Which looks very much like the PFN locking failure. However booting up >>>> with venus=on instead works. Could there be any differences in the way >>>> device memory is mapped in the two cases? >>> >>> Memory mapping works exactly the same for nctx and venus. Are you on >>> 6.13 host kernel? >> >> Yes - with the Altra PCI workaround patches on both host and guest >> kernel. >> >> Is there anyway to trace the sharing of device memory on the host so I >> can verify its an attempt at device access? The PC looks like its in >> user-space but once this fails the guest is suspended so I can't poke >> around in its environment. > > I'm adding printk's to kernel in a such cases. Likely there is no other > better way to find why it fails. > > Does your ARM VM and host both use 4k page size? > > Well, if it's a page refcounting bug on ARM/KMV, then applying [1] to > the host driver will make it work and we will know where the problem is. > Please try. > > [1] > https://patchwork.kernel.org/project/kvm/patch/20220815095423.11131-1-dmitry.osipenko@collabora.com/ That makes no difference. AFAICT the fault is triggered in userspace: error: kvm run failed Bad address PC=0000ffffb1911eb0 X00=0000ffffb1eb60a4 X01=0000aaaaeb1f5400 X02=000000000000013c X03=0000ffffb1eb6098 X04=0000aaaaeb1f553c X05=0000ffffb1eb61d4 X06=00000000c0016900 X07=000000000000000e X08=0000000000000014 X09=00000000000000ff X10=0000aaaaeb1f5500 X11=0000aaaaeb110028 X12=0000aaaaeb19ecb0 X13=0000000000000001 X14=000000000000000c X15=0000000000007718 X16=0000ffffb11d01f0 X17=0000ffffb1911dc0 X18=00000000000076f0 X19=0000aaaaeb1f4330 X20=0000aaaaeb1f53f0 X21=0000aaaaeb1e65e0 X22=000000000000004c X23=0000aaaaeb1ee5e0 X24=0000aaaaeb1a3cb0 X25=00000000000000ff X26=0000000000000076 X27=0000ffffc7db4e58 X28=0000aaaaeb1a3cb0 X29=0000ffffc7db4180 X30=0000ffffb0538b98 SP=0000ffffc7db4180 PSTATE=20001000 --C- EL0t QEMU 9.2.50 monitor - type 'help' for more information (qemu) quit Thread 4 received signal SIGABRT, Aborted. [Switching to Thread 1.4] cpu_do_idle () at /home/alex/lsrc/linux.git/arch/arm64/kernel/idle.c:32 32 arm_cpuidle_restore_irq_context(&context); (gdb) alex Undefined command: "alex". Try "help". (gdb) bt #0 cpu_do_idle () at /home/alex/lsrc/linux.git/arch/arm64/kernel/idle.c:32 #1 0xffff800081962180 in arch_cpu_idle () at /home/alex/lsrc/linux.git/arch/arm64/kernel/idle.c:44 #2 0xffff8000819622c4 in default_idle_call () at /home/alex/lsrc/linux.git/kernel/sched/idle.c:117 #3 0xffff80008013af8c in cpuidle_idle_call () at /home/alex/lsrc/linux.git/kernel/sched/idle.c:185 #4 do_idle () at /home/alex/lsrc/linux.git/kernel/sched/idle.c:325 #5 0xffff80008013b208 in cpu_startup_entry (state=state@entry=CPUHP_AP_ONLINE_IDLE) at /home/alex/lsrc/linux.git/kernel/sched/idle.c:423 #6 0xffff800080043668 in secondary_start_kernel () at /home/alex/lsrc/linux.git/arch/arm64/kernel/smp.c:279 #7 0xffff800080051f78 in __secondary_switched () at /home/alex/lsrc/linux.git/arch/arm64/kernel/head.S:420 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) info threads Id Target Id Frame 1 Thread 1.1 (CPU#0 [running]) cpu_do_idle () at /home/alex/lsrc/linux.git/arch/arm64/kernel/idle.c:32 2 Thread 1.2 (CPU#1 [halted ]) 0x0000ffffb1911eb0 in ?? () 3 Thread 1.3 (CPU#2 [halted ]) cpu_do_idle () at /home/alex/lsrc/linux.git/arch/arm64/kernel/idle.c:32 * 4 Thread 1.4 (CPU#3 [halted ]) cpu_do_idle () at /home/alex/lsrc/linux.git/arch/arm64/kernel/idle.c:32 (gdb) thread 2 [Switching to thread 2 (Thread 1.2)] #0 0x0000ffffb1911eb0 in ?? () (gdb) bt #0 0x0000ffffb1911eb0 in ?? () #1 0x0000aaaaeb1ea5e0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) frame 0 #0 0x0000ffffb1911eb0 in ?? () (gdb) x/5i $pc => 0xffffb1911eb0: str q3, [x0] 0xffffb1911eb4: ldp q2, q3, [x1, #48] 0xffffb1911eb8: subs x2, x2, #0x90 0xffffb1911ebc: b.ls 0xffffb1911ee0 // b.plast 0xffffb1911ec0: stp q0, q1, [x3, #16] (gdb) p/x $x0 $1 = 0xffffb1eb60a4 I suspect that is memcpy again but I'll try and track it down. The only other note is: [ 411.509647] kvm [7713]: Unsupported FSC: EC=0x24 xFSC=0x21 ESR_EL2=0x92000061 Which is: EC 0x24 - Data Abort from lower EL DFSC 0x21 - Alignment fault WnR 1 - Caused by write -- Alex Bennée Virtualisation Tech Lead @ Linaro ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2025-02-27 6:41 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-01-19 22:00 [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 1/8] ui/sdl2: Restore original context after new context creation Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 2/8] ui/sdl2: Implement dpy dmabuf functions Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 3/8] virtio-gpu: Handle virgl fence creation errors Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 4/8] virtio-gpu: Support asynchronous fencing Dmitry Osipenko [not found] ` <87cyghr3l2.fsf@draig.linaro.org> 2025-01-22 12:18 ` Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 5/8] virtio-gpu: Support DRM native context Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 6/8] ui/sdl2: Don't disable scanout when display is refreshed Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 7/8] ui/gtk: " Dmitry Osipenko 2025-01-19 22:00 ` [PATCH v5 8/8] docs/system: Expand the virtio-gpu documentation Dmitry Osipenko [not found] ` <c2e1c362-5d02-488e-b849-d0b14781a60f@daynix.com> [not found] ` <87ikq9r7wj.fsf@draig.linaro.org> 2025-01-21 4:26 ` Akihiko Odaki 2025-01-26 18:06 ` Dmitry Osipenko 2025-01-27 4:57 ` Akihiko Odaki 2025-02-02 22:08 ` Dmitry Osipenko 2025-02-03 5:31 ` Akihiko Odaki 2025-02-05 17:40 ` Dmitry Osipenko 2025-02-06 5:41 ` Akihiko Odaki 2025-02-09 21:03 ` Dmitry Osipenko 2025-02-13 4:32 ` Akihiko Odaki 2025-02-18 6:27 ` Dmitry Osipenko 2025-02-18 6:35 ` Dmitry Osipenko 2025-02-27 6:40 ` Akihiko Odaki [not found] ` <871pwxqyr3.fsf@draig.linaro.org> 2025-01-22 12:25 ` [PATCH v5 0/8] Support virtio-gpu DRM native context Dmitry Osipenko 2025-01-22 17:00 ` Alex Bennée 2025-01-23 11:23 ` Dmitry Osipenko 2025-01-23 11:58 ` Alex Bennée 2025-01-23 12:37 ` Dmitry Osipenko 2025-01-27 14:50 ` Alex Bennée
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).