[PATCH v11 00/10] Support virtio-gpu DRM native context

[PATCH v11 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

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 DRM native context drivers existing in a wild:

  - Freedreno (Qualcomm SoC GPUs), completely upstreamed
  - AMDGPU, completely upstreamed
  - Intel (i915), merge requests are opened
  - Asahi (Apple SoC GPUs), partially merged upstream

# How to try out DRM context:

1. DRM context uses host blobs and on host requires latest 6.13 version
of Linux kernel that contains necessary KVM fixes.

2. Use latest Mesa (both guest and host) and libvirglrenderer versions.
 Use build flags documented in tha patch #10 of this series.

3. On guest, use latest Linux kernel v6.14-rc or newer.

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. We will need to optimize hostmem
unmapping that currently happens in a deffered RCU work, blocking
GPU for a substantial time [2].

[2] https://lore.kernel.org/qemu-devel/f58d250d-3831-4ff1-a018-f62f9aeb2527@collabora.com/T/#m17ac72336d28a64c793d4e4e0c87fc7dff9aa847

Changelog:

v11:- Added column for libvirglrenderer host requrements versions and 
      corrected Asahi kernel link. Suggested by Akihiko Odaki.

v10:- Added links to Asahi and i915 virglrenderer MRs, link to Asahi host
      kernel. Suggested by Akihiko Odaki.

    - Renamed gfxstream guest requrements table's colum to match the host
      requirements table. Suggested by Akihiko Odaki.

v9: - Updated doc patch by addresing review comments from Akihiko Odaki.
      Made kernel requirements section specific to guest kernel and
      removed reference to host requirements. Removed examples of
      external projects' build flags.

    - Added guest kernel minimum versions to the guest requirements table.

v8: - Addressed review comments from Akihiko Odaki on the doc patch.

    - Added r-bs from Akihiko Odaki on the doc patches.

    - Extended vrend doc with info about hostmem requirement for GL 4.6

v7: - Added r-b from Alex Bennée to the async fencing patch.

    - Updated virtio-gpu doc patch with addressed review comments
      from Akihiko Odaki.

v6: - Fixed compilation warning using older version of virglrenderer,
      which wasn't fixed properly in v5.

    - Added t-bs from Alex Bennée.

    - Added patches to improve virgl/venus doc by adding links
      to the Mesa doc as was suggested by Akihiko Odaki.

    - Updated patch that documents guest/host requirements. Added
      links to Asahi nctx and reworked the doc structure by adding
      requirements to each context-type section instead of having
      one big blob or requirements, which was objected by Akihiko Odaki.

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: virtio-gpu: Document host/guest requirements

Dmitry Osipenko (8):
  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
  docs/system: virtio-gpu: Add link to Mesa VirGL doc
  docs/system: virtio-gpu: Update Venus link

Pierre-Eric Pelloux-Prayer (1):
  ui/sdl2: Implement dpy dmabuf functions

 docs/system/devices/virtio-gpu.rst | 117 +++++++++++++++++++-
 hw/display/virtio-gpu-gl.c         |   5 +
 hw/display/virtio-gpu-virgl.c      | 164 ++++++++++++++++++++++++++++-
 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, 429 insertions(+), 13 deletions(-)

-- 
2.48.1

[PATCH v11 01/10] ui/sdl2: Restore original context after new context creation

[Dmitry Osipenko]

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>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
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.48.1

[PATCH v11 02/10] ui/sdl2: Implement dpy dmabuf functions

[Dmitry Osipenko]

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>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
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 8b9fda4d95e6..c0b5f1ccc026 100644
--- a/meson.build
+++ b/meson.build
@@ -1966,10 +1966,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 cda4293a53e6..943974544343 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -35,6 +35,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;
 
@@ -120,6 +124,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);
 }
 
@@ -798,6 +805,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
@@ -825,6 +836,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;
@@ -852,6 +892,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);
@@ -898,6 +939,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.48.1

[PATCH v11 03/10] virtio-gpu: Handle virgl fence creation errors

[Dmitry Osipenko]

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>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
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.48.1

[PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Dmitry Osipenko]

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>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 hw/display/virtio-gpu-gl.c     |   3 +
 hw/display/virtio-gpu-virgl.c  | 147 +++++++++++++++++++++++++++++++--
 include/hw/virtio/virtio-gpu.h |  13 +++
 3 files changed, 154 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..ee896eced67c 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,34 @@ 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)) {
+#if VIRGL_VERSION_MAJOR >= 1
+        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
+        /* gl->context_fence_enabled cannot be set with older virglrenderer */
+        g_assert_not_reached();
+#endif
+    } 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 +1028,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 +1211,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 +1230,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 +1270,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.48.1

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Cong Liu]

I discovered that on an ARM64 environment, the 'virtio-gpu: Support asynchronous fencing' patch causes the virtual machine GUI to fail to display. Rolling back this patch and using virgl allows the virtual machine to start normally. When the VM screen is black, I can see some errors in QEMU. I used QEMU's -serial stdio to enter the virtual machine's command line console but didn't see any errors inside the VM - the graphical interface seems to be stuck. I would greatly appreciate any suggestions regarding effective troubleshooting methods or specific areas I should investigate to resolve this issue.

Here's my software and hardware environment:
- host and guest are ubuntu 24.04
- QEMU: https://gitlab.freedesktop.org/digetx/qemu.git native-context-v11 branch
- virglrender: latest main branch 08eb12d00711370002e8f8fa6d620df9b79f9e27
- Mesa: Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 noble-oibaf-ppa)
- Kernel: Linux d3000 6.14.1-061401-generic #202504071048
- GPU: Radeon RX 6600/6600 XT/6600M
- CPU: phytium D3000 aarch64

Here's the command I'm using to run the virtual machine, which displays a black frame with "Display output is not active" and fails to start the graphical interface normally:

    phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display gtk,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0

    (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
    (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
    (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
    (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
    (qemu:46029): Gdk-WARNING **: 16:43:53.716: eglMakeCurrent failed

When using SDL, the error messages are slightly different:

    phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0

    vrend_renderer_fill_caps: Entering with stale GL error: 1286

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Dmitry Osipenko]

10.04.2025 12:54, Cong Liu пишет:
> I discovered that on an ARM64 environment, the 'virtio-gpu: Support asynchronous fencing' patch causes the virtual machine GUI to fail to display. Rolling back this patch and using virgl allows the virtual machine to start normally. When the VM screen is black, I can see some errors in QEMU. I used QEMU's -serial stdio to enter the virtual machine's command line console but didn't see any errors inside the VM - the graphical interface seems to be stuck. I would greatly appreciate any suggestions regarding effective troubleshooting methods or specific areas I should investigate to resolve this issue.
> 
> Here's my software and hardware environment:
> - host and guest are ubuntu 24.04
> - QEMU: https://gitlab.freedesktop.org/digetx/qemu.git native-context-v11 branch
> - virglrender: latest main branch 08eb12d00711370002e8f8fa6d620df9b79f9e27
> - Mesa: Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 noble-oibaf-ppa)
> - Kernel: Linux d3000 6.14.1-061401-generic #202504071048
> - GPU: Radeon RX 6600/6600 XT/6600M
> - CPU: phytium D3000 aarch64
> 
> Here's the command I'm using to run the virtual machine, which displays a black frame with "Display output is not active" and fails to start the graphical interface normally:
> 
>     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display gtk,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> 
>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>     (qemu:46029): Gdk-WARNING **: 16:43:53.716: eglMakeCurrent failed
> 
> When using SDL, the error messages are slightly different:
> 
>     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> 
>     vrend_renderer_fill_caps: Entering with stale GL error: 1286
> 

Hi,

1. Please make sure that you're not only building QEMU against your
virglrenderer version, but also setting LD_LIBRARY_PATH properly at
runtime. Best to remove system version of virglrenderer if unsure,

2. Can you reproduce this problem using tcg instead of kvm?

-- 
Best regards,
Dmitry

Re: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[刘聪]

> -----Original Messages-----
> From: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>
> Send time:Friday, 04/11/2025 05:59:11
> To: "Cong Liu" <liucong2565@phytium.com.cn>
> Cc: Jiqian.Chen@amd.com, akihiko.odaki@daynix.com, alex.bennee@linaro.org, alexander.deucher@amd.com, christian.koenig@amd.com, gert.wollny@collabora.com, gurchetansingh@chromium.org, hi@alyssa.is, honglei1.huang@amd.com, julia.zhang@amd.com, kraxel@redhat.com, marcandre.lureau@redhat.com, mst@redhat.com, pbonzini@redhat.com, philmd@linaro.org, pierre-eric.pelloux-prayer@amd.com, qemu-devel@nongnu.org, ray.huang@amd.com, robdclark@gmail.com, roger.pau@citrix.com, slp@redhat.com, stefano.stabellini@amd.com, xenia.ragiadakou@amd.com, zzyiwei@chromium.org
> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing
> 
> 10.04.2025 12:54, Cong Liu пишет:
> > I discovered that on an ARM64 environment, the 'virtio-gpu: Support asynchronous fencing' patch causes the virtual machine GUI to fail to display. Rolling back this patch and using virgl allows the virtual machine to start normally. When the VM screen is black, I can see some errors in QEMU. I used QEMU's -serial stdio to enter the virtual machine's command line console but didn't see any errors inside the VM - the graphical interface seems to be stuck. I would greatly appreciate any suggestions regarding effective troubleshooting methods or specific areas I should investigate to resolve this issue.
> > 
> > Here's my software and hardware environment:
> > - host and guest are ubuntu 24.04
> > - QEMU: https://gitlab.freedesktop.org/digetx/qemu.git native-context-v11 branch
> > - virglrender: latest main branch 08eb12d00711370002e8f8fa6d620df9b79f9e27
> > - Mesa: Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 noble-oibaf-ppa)
> > - Kernel: Linux d3000 6.14.1-061401-generic #202504071048
> > - GPU: Radeon RX 6600/6600 XT/6600M
> > - CPU: phytium D3000 aarch64
> > 
> > Here's the command I'm using to run the virtual machine, which displays a black frame with "Display output is not active" and fails to start the graphical interface normally:
> > 
> >     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display gtk,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> > 
> >     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
> >     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
> >     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
> >     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
> >     (qemu:46029): Gdk-WARNING **: 16:43:53.716: eglMakeCurrent failed
> > 
> > When using SDL, the error messages are slightly different:
> > 
> >     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> > 
> >     vrend_renderer_fill_caps: Entering with stale GL error: 1286
> > 
> 
> Hi,
> 
> 1. Please make sure that you're not only building QEMU against your
> virglrenderer version, but also setting LD_LIBRARY_PATH properly at
> runtime. Best to remove system version of virglrenderer if unsure,

I built and installed virglrenderer with the --prefix=/usr option, so
 it replaces the system version as expected.

> 
> 2. Can you reproduce this problem using tcg instead of kvm?
> 

 yes, change qemu command '--machine virt,accel=kvm -cpu host' to
'--machine virt -cpu max' can reproduce this problem. 
> -- 
> Best regards,
> Dmitry

diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
index f6df9dcb..f6e06842 100644
--- a/src/vrend_renderer.c
+++ b/src/vrend_renderer.c
@@ -12808,7 +12808,7 @@ void vrend_renderer_fill_caps(uint32_t set, uint32_t version,
                               union virgl_caps *caps)
 {
    int gl_ver, gles_ver;
-   GLenum err;
+   GLenum err = GL_NO_ERROR;
    bool fill_capset2 = false;
 
    if (!caps)

phytium@d3000:~/working/qemu$ git log --oneline  -n 10
e0286f56c8 (HEAD -> native-context-v11, origin/native-context-v11) Revert "amd_iommu: Add support for pass though mode"
d6e9eb0f0d docs/system: virtio-gpu: Document host/guest requirements
55db821ea5 docs/system: virtio-gpu: Update Venus link
003940db9a docs/system: virtio-gpu: Add link to Mesa VirGL doc
7674e82755 ui/gtk: Don't disable scanout when display is refreshed
712fd024e3 ui/sdl2: Don't disable scanout when display is refreshed
9003da356f virtio-gpu: Support DRM native context
e2ff4f4a48 virtio-gpu: Support asynchronous fencing
25458c7625 virtio-gpu: Handle virgl fence creation errors

I tried initializing GLenum err = GL_NO_ERROR in vrend_renderer_fill_caps, but it doesn’t seem to resolve the “Entering with stale GL error: 1286” message. However, this error might not be directly related to the VM black screen issue. I noticed that even when the VM was working correctly—specifically when I reset to commit 25458c7625—the same GL error still appeared.

Best regards,
liucong


信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Dmitry Osipenko]

On 4/11/25 04:42, 刘聪 wrote:
> 
> 
> 
>> -----Original Messages-----
>> From: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>
>> Send time:Friday, 04/11/2025 05:59:11
>> To: "Cong Liu" <liucong2565@phytium.com.cn>
>> Cc: Jiqian.Chen@amd.com, akihiko.odaki@daynix.com, alex.bennee@linaro.org, alexander.deucher@amd.com, christian.koenig@amd.com, gert.wollny@collabora.com, gurchetansingh@chromium.org, hi@alyssa.is, honglei1.huang@amd.com, julia.zhang@amd.com, kraxel@redhat.com, marcandre.lureau@redhat.com, mst@redhat.com, pbonzini@redhat.com, philmd@linaro.org, pierre-eric.pelloux-prayer@amd.com, qemu-devel@nongnu.org, ray.huang@amd.com, robdclark@gmail.com, roger.pau@citrix.com, slp@redhat.com, stefano.stabellini@amd.com, xenia.ragiadakou@amd.com, zzyiwei@chromium.org
>> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing
>>
>> 10.04.2025 12:54, Cong Liu пишет:
>>> I discovered that on an ARM64 environment, the 'virtio-gpu: Support asynchronous fencing' patch causes the virtual machine GUI to fail to display. Rolling back this patch and using virgl allows the virtual machine to start normally. When the VM screen is black, I can see some errors in QEMU. I used QEMU's -serial stdio to enter the virtual machine's command line console but didn't see any errors inside the VM - the graphical interface seems to be stuck. I would greatly appreciate any suggestions regarding effective troubleshooting methods or specific areas I should investigate to resolve this issue.
>>>
>>> Here's my software and hardware environment:
>>> - host and guest are ubuntu 24.04
>>> - QEMU: https://gitlab.freedesktop.org/digetx/qemu.git native-context-v11 branch
>>> - virglrender: latest main branch 08eb12d00711370002e8f8fa6d620df9b79f9e27
>>> - Mesa: Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 noble-oibaf-ppa)
>>> - Kernel: Linux d3000 6.14.1-061401-generic #202504071048
>>> - GPU: Radeon RX 6600/6600 XT/6600M
>>> - CPU: phytium D3000 aarch64
>>>
>>> Here's the command I'm using to run the virtual machine, which displays a black frame with "Display output is not active" and fails to start the graphical interface normally:
>>>
>>>     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display gtk,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
>>>
>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.716: eglMakeCurrent failed
>>>
>>> When using SDL, the error messages are slightly different:
>>>
>>>     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
>>>
>>>     vrend_renderer_fill_caps: Entering with stale GL error: 1286
>>>
>>
>> Hi,
>>
>> 1. Please make sure that you're not only building QEMU against your
>> virglrenderer version, but also setting LD_LIBRARY_PATH properly at
>> runtime. Best to remove system version of virglrenderer if unsure,
> 
> I built and installed virglrenderer with the --prefix=/usr option, so
>  it replaces the system version as expected.
> 
>>
>> 2. Can you reproduce this problem using tcg instead of kvm?
>>
> 
>  yes, change qemu command '--machine virt,accel=kvm -cpu host' to
> '--machine virt -cpu max' can reproduce this problem. 
>> -- 
>> Best regards,
>> Dmitry
> 
> diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
> index f6df9dcb..f6e06842 100644
> --- a/src/vrend_renderer.c
> +++ b/src/vrend_renderer.c
> @@ -12808,7 +12808,7 @@ void vrend_renderer_fill_caps(uint32_t set, uint32_t version,
>                                union virgl_caps *caps)
>  {
>     int gl_ver, gles_ver;
> -   GLenum err;
> +   GLenum err = GL_NO_ERROR;
>     bool fill_capset2 = false;
>  
>     if (!caps)
> 
> phytium@d3000:~/working/qemu$ git log --oneline  -n 10
> e0286f56c8 (HEAD -> native-context-v11, origin/native-context-v11) Revert "amd_iommu: Add support for pass though mode"
> d6e9eb0f0d docs/system: virtio-gpu: Document host/guest requirements
> 55db821ea5 docs/system: virtio-gpu: Update Venus link
> 003940db9a docs/system: virtio-gpu: Add link to Mesa VirGL doc
> 7674e82755 ui/gtk: Don't disable scanout when display is refreshed
> 712fd024e3 ui/sdl2: Don't disable scanout when display is refreshed
> 9003da356f virtio-gpu: Support DRM native context
> e2ff4f4a48 virtio-gpu: Support asynchronous fencing
> 25458c7625 virtio-gpu: Handle virgl fence creation errors
> 
> I tried initializing GLenum err = GL_NO_ERROR in vrend_renderer_fill_caps, but it doesn’t seem to resolve the “Entering with stale GL error: 1286” message. However, this error might not be directly related to the VM black screen issue. I noticed that even when the VM was working correctly—specifically when I reset to commit 25458c7625—the same GL error still appeared.

Thanks for the report. I confirm that something is wrong with virgl when
async fencing is used. Don't have this GL 1286 error, but getting a
lockup on ARM VM and with one of my new x64 VM setups. Will investigate
further and report back here.

-- 
Best regards,
Dmitry

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Dmitry Osipenko]

On 4/14/25 17:47, Dmitry Osipenko wrote:
> On 4/11/25 04:42, 刘聪 wrote:
>>
>>
>>
>>> -----Original Messages-----
>>> From: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>
>>> Send time:Friday, 04/11/2025 05:59:11
>>> To: "Cong Liu" <liucong2565@phytium.com.cn>
>>> Cc: Jiqian.Chen@amd.com, akihiko.odaki@daynix.com, alex.bennee@linaro.org, alexander.deucher@amd.com, christian.koenig@amd.com, gert.wollny@collabora.com, gurchetansingh@chromium.org, hi@alyssa.is, honglei1.huang@amd.com, julia.zhang@amd.com, kraxel@redhat.com, marcandre.lureau@redhat.com, mst@redhat.com, pbonzini@redhat.com, philmd@linaro.org, pierre-eric.pelloux-prayer@amd.com, qemu-devel@nongnu.org, ray.huang@amd.com, robdclark@gmail.com, roger.pau@citrix.com, slp@redhat.com, stefano.stabellini@amd.com, xenia.ragiadakou@amd.com, zzyiwei@chromium.org
>>> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing
>>>
>>> 10.04.2025 12:54, Cong Liu пишет:
>>>> I discovered that on an ARM64 environment, the 'virtio-gpu: Support asynchronous fencing' patch causes the virtual machine GUI to fail to display. Rolling back this patch and using virgl allows the virtual machine to start normally. When the VM screen is black, I can see some errors in QEMU. I used QEMU's -serial stdio to enter the virtual machine's command line console but didn't see any errors inside the VM - the graphical interface seems to be stuck. I would greatly appreciate any suggestions regarding effective troubleshooting methods or specific areas I should investigate to resolve this issue.
>>>>
>>>> Here's my software and hardware environment:
>>>> - host and guest are ubuntu 24.04
>>>> - QEMU: https://gitlab.freedesktop.org/digetx/qemu.git native-context-v11 branch
>>>> - virglrender: latest main branch 08eb12d00711370002e8f8fa6d620df9b79f9e27
>>>> - Mesa: Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 noble-oibaf-ppa)
>>>> - Kernel: Linux d3000 6.14.1-061401-generic #202504071048
>>>> - GPU: Radeon RX 6600/6600 XT/6600M
>>>> - CPU: phytium D3000 aarch64
>>>>
>>>> Here's the command I'm using to run the virtual machine, which displays a black frame with "Display output is not active" and fails to start the graphical interface normally:
>>>>
>>>>     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display gtk,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
>>>>
>>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.716: eglMakeCurrent failed
>>>>
>>>> When using SDL, the error messages are slightly different:
>>>>
>>>>     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
>>>>
>>>>     vrend_renderer_fill_caps: Entering with stale GL error: 1286
>>>>
>>>
>>> Hi,
>>>
>>> 1. Please make sure that you're not only building QEMU against your
>>> virglrenderer version, but also setting LD_LIBRARY_PATH properly at
>>> runtime. Best to remove system version of virglrenderer if unsure,
>>
>> I built and installed virglrenderer with the --prefix=/usr option, so
>>  it replaces the system version as expected.
>>
>>>
>>> 2. Can you reproduce this problem using tcg instead of kvm?
>>>
>>
>>  yes, change qemu command '--machine virt,accel=kvm -cpu host' to
>> '--machine virt -cpu max' can reproduce this problem. 
>>> -- 
>>> Best regards,
>>> Dmitry
>>
>> diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
>> index f6df9dcb..f6e06842 100644
>> --- a/src/vrend_renderer.c
>> +++ b/src/vrend_renderer.c
>> @@ -12808,7 +12808,7 @@ void vrend_renderer_fill_caps(uint32_t set, uint32_t version,
>>                                union virgl_caps *caps)
>>  {
>>     int gl_ver, gles_ver;
>> -   GLenum err;
>> +   GLenum err = GL_NO_ERROR;
>>     bool fill_capset2 = false;
>>  
>>     if (!caps)
>>
>> phytium@d3000:~/working/qemu$ git log --oneline  -n 10
>> e0286f56c8 (HEAD -> native-context-v11, origin/native-context-v11) Revert "amd_iommu: Add support for pass though mode"
>> d6e9eb0f0d docs/system: virtio-gpu: Document host/guest requirements
>> 55db821ea5 docs/system: virtio-gpu: Update Venus link
>> 003940db9a docs/system: virtio-gpu: Add link to Mesa VirGL doc
>> 7674e82755 ui/gtk: Don't disable scanout when display is refreshed
>> 712fd024e3 ui/sdl2: Don't disable scanout when display is refreshed
>> 9003da356f virtio-gpu: Support DRM native context
>> e2ff4f4a48 virtio-gpu: Support asynchronous fencing
>> 25458c7625 virtio-gpu: Handle virgl fence creation errors
>>
>> I tried initializing GLenum err = GL_NO_ERROR in vrend_renderer_fill_caps, but it doesn’t seem to resolve the “Entering with stale GL error: 1286” message. However, this error might not be directly related to the VM black screen issue. I noticed that even when the VM was working correctly—specifically when I reset to commit 25458c7625—the same GL error still appeared.
> 
> Thanks for the report. I confirm that something is wrong with virgl when
> async fencing is used. Don't have this GL 1286 error, but getting a
> lockup on ARM VM and with one of my new x64 VM setups. Will investigate
> further and report back here.

Hi, Cong. Please give a test to [1]. It fixes the problem for me.

[1] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1518

-- 
Best regards,
Dmitry

Re: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[刘聪]

Hi Dmitry,

The virglrender patch can fix the virgl issue, but the native context still fails to run on my machine.
I'm not sure if anyone has successfully run it on an ARM64 machine before.

When running with Venus, the virtual machine can successfully run vkcube. However, when using the native context, a KVM error is triggered. Both my guest and host kernels are already updated to version 6.14.

Here are the commands and error messages I encountered:

```
phytium@ubuntu:~/working/virglrenderer$ /opt/native-context-v11/bin/qemu-system-aarch64 --machine virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl,hostmem=4G,blob=on,venus=on -object memory-backend-memfd,id=mem1,size=4G  -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
phytium@ubuntu:~/working/virglrenderer$ 
phytium@ubuntu:~/working/virglrenderer$ /opt/native-context-v11/bin/qemu-system-aarch64 --machine virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl,hostmem=4G,blob=on,drm_native_context=on -object memory-backend-memfd,id=mem1,size=4G  -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
error: kvm run failed Bad address
 PC=0000e2bcbbf31ab0 X00=0000e2bc9c3ae060 X01=0000e2bc7c02af00
X02=0000000000000014 X03=0000e2bc9c3ae000 X04=0000e2bc7c02af14
X05=0000e2bc9c3ae074 X06=0000000000000200 X07=0000e2bc7c02a8f8
X08=00000000000000de X09=0000000000000200 X10=0000000000001000
X11=0000000000000004 X12=0000e2bc7c0000b0 X13=0000000000000001
X14=0000000000000020 X15=0000e2bc9e465f93 X16=0000e2bcad6a01f0
X17=0000e2bcbbf31a80 X18=0000000000000093 X19=0000000000000060
X20=0000000000000074 X21=0000e2bc9e46c5f0 X22=0000e2bc9c3ae000
X23=0000000000000074 X24=0000c02241da83b0 X25=0000c02241da85a0
X26=0000c02241da85a0 X27=0000000000000014 X28=0000e2bc9e46c5f0
X29=0000e2bc9e46c610 X30=0000e2bcac809c38  SP=0000e2bc9e46c510
PSTATE=20001000 --C- EL0t
phytium@ubuntu:~/working/virglrenderer$ uname -a
Linux ubuntu 6.14.1-061401-generic #202504071048 SMP PREEMPT_DYNAMIC Mon Apr  7 11:34:37 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
```

Best regards,
Cong

> -----Original Messages-----
> From: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>
> Send time:Sunday, 04/27/2025 06:27:39
> To: 刘聪 <liucong2565@phytium.com.cn>
> Cc: Jiqian.Chen@amd.com, akihiko.odaki@daynix.com, alex.bennee@linaro.org, alexander.deucher@amd.com, christian.koenig@amd.com, gert.wollny@collabora.com, gurchetansingh@chromium.org, hi@alyssa.is, honglei1.huang@amd.com, julia.zhang@amd.com, kraxel@redhat.com, marcandre.lureau@redhat.com, mst@redhat.com, pbonzini@redhat.com, philmd@linaro.org, pierre-eric.pelloux-prayer@amd.com, qemu-devel@nongnu.org, ray.huang@amd.com, robdclark@gmail.com, roger.pau@citrix.com, slp@redhat.com, stefano.stabellini@amd.com, xenia.ragiadakou@amd.com, zzyiwei@chromium.org
> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing
> 
> On 4/14/25 17:47, Dmitry Osipenko wrote:
> > On 4/11/25 04:42, 刘聪 wrote:
> >>
> >>
> >>
> >>> -----Original Messages-----
> >>> From: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>
> >>> Send time:Friday, 04/11/2025 05:59:11
> >>> To: "Cong Liu" <liucong2565@phytium.com.cn>
> >>> Cc: Jiqian.Chen@amd.com, akihiko.odaki@daynix.com, alex.bennee@linaro.org, alexander.deucher@amd.com, christian.koenig@amd.com, gert.wollny@collabora.com, gurchetansingh@chromium.org, hi@alyssa.is, honglei1.huang@amd.com, julia.zhang@amd.com, kraxel@redhat.com, marcandre.lureau@redhat.com, mst@redhat.com, pbonzini@redhat.com, philmd@linaro.org, pierre-eric.pelloux-prayer@amd.com, qemu-devel@nongnu.org, ray.huang@amd.com, robdclark@gmail.com, roger.pau@citrix.com, slp@redhat.com, stefano.stabellini@amd.com, xenia.ragiadakou@amd.com, zzyiwei@chromium.org
> >>> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing
> >>>
> >>> 10.04.2025 12:54, Cong Liu пишет:
> >>>> I discovered that on an ARM64 environment, the 'virtio-gpu: Support asynchronous fencing' patch causes the virtual machine GUI to fail to display. Rolling back this patch and using virgl allows the virtual machine to start normally. When the VM screen is black, I can see some errors in QEMU. I used QEMU's -serial stdio to enter the virtual machine's command line console but didn't see any errors inside the VM - the graphical interface seems to be stuck. I would greatly appreciate any suggestions regarding effective troubleshooting methods or specific areas I should investigate to resolve this issue.
> >>>>
> >>>> Here's my software and hardware environment:
> >>>> - host and guest are ubuntu 24.04
> >>>> - QEMU: https://gitlab.freedesktop.org/digetx/qemu.git native-context-v11 branch
> >>>> - virglrender: latest main branch 08eb12d00711370002e8f8fa6d620df9b79f9e27
> >>>> - Mesa: Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 noble-oibaf-ppa)
> >>>> - Kernel: Linux d3000 6.14.1-061401-generic #202504071048
> >>>> - GPU: Radeon RX 6600/6600 XT/6600M
> >>>> - CPU: phytium D3000 aarch64
> >>>>
> >>>> Here's the command I'm using to run the virtual machine, which displays a black frame with "Display output is not active" and fails to start the graphical interface normally:
> >>>>
> >>>>     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display gtk,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> >>>>
> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.716: eglMakeCurrent failed
> >>>>
> >>>> When using SDL, the error messages are slightly different:
> >>>>
> >>>>     phytium@d3000:~/working/qemu$ /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> >>>>
> >>>>     vrend_renderer_fill_caps: Entering with stale GL error: 1286
> >>>>
> >>>
> >>> Hi,
> >>>
> >>> 1. Please make sure that you're not only building QEMU against your
> >>> virglrenderer version, but also setting LD_LIBRARY_PATH properly at
> >>> runtime. Best to remove system version of virglrenderer if unsure,
> >>
> >> I built and installed virglrenderer with the --prefix=/usr option, so
> >>  it replaces the system version as expected.
> >>
> >>>
> >>> 2. Can you reproduce this problem using tcg instead of kvm?
> >>>
> >>
> >>  yes, change qemu command '--machine virt,accel=kvm -cpu host' to
> >> '--machine virt -cpu max' can reproduce this problem. 
> >>> -- 
> >>> Best regards,
> >>> Dmitry
> >>
> >> diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
> >> index f6df9dcb..f6e06842 100644
> >> --- a/src/vrend_renderer.c
> >> +++ b/src/vrend_renderer.c
> >> @@ -12808,7 +12808,7 @@ void vrend_renderer_fill_caps(uint32_t set, uint32_t version,
> >>                                union virgl_caps *caps)
> >>  {
> >>     int gl_ver, gles_ver;
> >> -   GLenum err;
> >> +   GLenum err = GL_NO_ERROR;
> >>     bool fill_capset2 = false;
> >>  
> >>     if (!caps)
> >>
> >> phytium@d3000:~/working/qemu$ git log --oneline  -n 10
> >> e0286f56c8 (HEAD -> native-context-v11, origin/native-context-v11) Revert "amd_iommu: Add support for pass though mode"
> >> d6e9eb0f0d docs/system: virtio-gpu: Document host/guest requirements
> >> 55db821ea5 docs/system: virtio-gpu: Update Venus link
> >> 003940db9a docs/system: virtio-gpu: Add link to Mesa VirGL doc
> >> 7674e82755 ui/gtk: Don't disable scanout when display is refreshed
> >> 712fd024e3 ui/sdl2: Don't disable scanout when display is refreshed
> >> 9003da356f virtio-gpu: Support DRM native context
> >> e2ff4f4a48 virtio-gpu: Support asynchronous fencing
> >> 25458c7625 virtio-gpu: Handle virgl fence creation errors
> >>
> >> I tried initializing GLenum err = GL_NO_ERROR in vrend_renderer_fill_caps, but it doesn’t seem to resolve the “Entering with stale GL error: 1286” message. However, this error might not be directly related to the VM black screen issue. I noticed that even when the VM was working correctly—specifically when I reset to commit 25458c7625—the same GL error still appeared.
> > 
> > Thanks for the report. I confirm that something is wrong with virgl when
> > async fencing is used. Don't have this GL 1286 error, but getting a
> > lockup on ARM VM and with one of my new x64 VM setups. Will investigate
> > further and report back here.
> 
> Hi, Cong. Please give a test to [1]. It fixes the problem for me.
> 
> [1] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1518
> 
> -- 
> Best regards,
> Dmitry


信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Alex Bennée]

刘聪 <liucong2565@phytium.com.cn> writes:

> Hi Dmitry,
>
> The virglrender patch can fix the virgl issue, but the native context still fails to run on my machine.
> I'm not sure if anyone has successfully run it on an ARM64 machine before.
>
> When running with Venus, the virtual machine can successfully run vkcube. However, when using the native context, a KVM error is triggered. Both my guest and host kernels are already updated to version 6.14.
>
> Here are the commands and error messages I encountered:
>
> ```
> phytium@ubuntu:~/working/virglrenderer$
> /opt/native-context-v11/bin/qemu-system-aarch64 --machine
> virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
> virtio-net-pci,netdev=net0 -device
> virtio-gpu-gl,hostmem=4G,blob=on,venus=on -object
> memory-backend-memfd,id=mem1,size=4G -display sdl,gl=on,show-cursor=on
> -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device
> usb-kbd,bus=usb.0
> phytium@ubuntu:~/working/virglrenderer$ 
> phytium@ubuntu:~/working/virglrenderer$
> /opt/native-context-v11/bin/qemu-system-aarch64 --machine
> virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
> virtio-net-pci,netdev=net0 -device
> virtio-gpu-gl,hostmem=4G,blob=on,drm_native_context=on -object
> memory-backend-memfd,id=mem1,size=4G -display sdl,gl=on,show-cursor=on
> -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device
> usb-kbd,bus=usb.0
> error: kvm run failed Bad address

That very much looks like a page not being accessible when trying to do
something. Do we know the page address? Can we dump the current state of
the page table for that? Is the page locked?

>  PC=0000e2bcbbf31ab0 X00=0000e2bc9c3ae060 X01=0000e2bc7c02af00
> X02=0000000000000014 X03=0000e2bc9c3ae000 X04=0000e2bc7c02af14
> X05=0000e2bc9c3ae074 X06=0000000000000200 X07=0000e2bc7c02a8f8
> X08=00000000000000de X09=0000000000000200 X10=0000000000001000
> X11=0000000000000004 X12=0000e2bc7c0000b0 X13=0000000000000001
> X14=0000000000000020 X15=0000e2bc9e465f93 X16=0000e2bcad6a01f0
> X17=0000e2bcbbf31a80 X18=0000000000000093 X19=0000000000000060
> X20=0000000000000074 X21=0000e2bc9e46c5f0 X22=0000e2bc9c3ae000
> X23=0000000000000074 X24=0000c02241da83b0 X25=0000c02241da85a0
> X26=0000c02241da85a0 X27=0000000000000014 X28=0000e2bc9e46c5f0
> X29=0000e2bc9e46c610 X30=0000e2bcac809c38  SP=0000e2bc9e46c510
> PSTATE=20001000 --C- EL0t
> phytium@ubuntu:~/working/virglrenderer$ uname -a
> Linux ubuntu 6.14.1-061401-generic #202504071048 SMP PREEMPT_DYNAMIC Mon Apr  7 11:34:37 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
> ```
>
> Best regards,
> Cong
>
>> -----Original Messages-----
>> From: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>
>> Send time:Sunday, 04/27/2025 06:27:39
>> To: 刘聪 <liucong2565@phytium.com.cn>
>> Cc: Jiqian.Chen@amd.com, akihiko.odaki@daynix.com,
>> alex.bennee@linaro.org, alexander.deucher@amd.com,
>> christian.koenig@amd.com, gert.wollny@collabora.com,
>> gurchetansingh@chromium.org, hi@alyssa.is, honglei1.huang@amd.com,
>> julia.zhang@amd.com, kraxel@redhat.com, marcandre.lureau@redhat.com,
>> mst@redhat.com, pbonzini@redhat.com, philmd@linaro.org,
>> pierre-eric.pelloux-prayer@amd.com, qemu-devel@nongnu.org,
>> ray.huang@amd.com, robdclark@gmail.com, roger.pau@citrix.com,
>> slp@redhat.com, stefano.stabellini@amd.com,
>> xenia.ragiadakou@amd.com, zzyiwei@chromium.org
>> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing
>> 
>> On 4/14/25 17:47, Dmitry Osipenko wrote:
>> > On 4/11/25 04:42, 刘聪 wrote:
>> >>
>> >>
>> >>
>> >>> -----Original Messages-----
>> >>> From: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>
>> >>> Send time:Friday, 04/11/2025 05:59:11
>> >>> To: "Cong Liu" <liucong2565@phytium.com.cn>
>> >>> Cc: Jiqian.Chen@amd.com, akihiko.odaki@daynix.com,
>> >>> alex.bennee@linaro.org, alexander.deucher@amd.com,
>> >>> christian.koenig@amd.com, gert.wollny@collabora.com,
>> >>> gurchetansingh@chromium.org, hi@alyssa.is,
>> >>> honglei1.huang@amd.com, julia.zhang@amd.com, kraxel@redhat.com,
>> >>> marcandre.lureau@redhat.com, mst@redhat.com,
>> >>> pbonzini@redhat.com, philmd@linaro.org,
>> >>> pierre-eric.pelloux-prayer@amd.com, qemu-devel@nongnu.org,
>> >>> ray.huang@amd.com, robdclark@gmail.com, roger.pau@citrix.com,
>> >>> slp@redhat.com, stefano.stabellini@amd.com,
>> >>> xenia.ragiadakou@amd.com, zzyiwei@chromium.org
>> >>> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing
>> >>>
>> >>> 10.04.2025 12:54, Cong Liu пишет:
>> >>>> I discovered that on an ARM64 environment, the 'virtio-gpu:
>> >>>> Support asynchronous fencing' patch causes the virtual machine
>> >>>> GUI to fail to display. Rolling back this patch and using virgl
>> >>>> allows the virtual machine to start normally. When the VM
>> >>>> screen is black, I can see some errors in QEMU. I used QEMU's
>> >>>> -serial stdio to enter the virtual machine's command line
>> >>>> console but didn't see any errors inside the VM - the graphical
>> >>>> interface seems to be stuck. I would greatly appreciate any
>> >>>> suggestions regarding effective troubleshooting methods or
>> >>>> specific areas I should investigate to resolve this issue.
>> >>>>
>> >>>> Here's my software and hardware environment:
>> >>>> - host and guest are ubuntu 24.04
>> >>>> - QEMU: https://gitlab.freedesktop.org/digetx/qemu.git native-context-v11 branch
>> >>>> - virglrender: latest main branch 08eb12d00711370002e8f8fa6d620df9b79f9e27
>> >>>> - Mesa: Mesa 25.0~git2504031308.ff386e~oibaf~n (git-ff386eb 2025-04-03 noble-oibaf-ppa)
>> >>>> - Kernel: Linux d3000 6.14.1-061401-generic #202504071048
>> >>>> - GPU: Radeon RX 6600/6600 XT/6600M
>> >>>> - CPU: phytium D3000 aarch64
>> >>>>
>> >>>> Here's the command I'm using to run the virtual machine, which displays a black frame with "Display output is not active" and fails to start the graphical interface normally:
>> >>>>
>> >>>>     phytium@d3000:~/working/qemu$
>> >>>> /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm
>> >>>> -cpu host -smp 4 -m 4G -drive
>> >>>> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
>> >>>> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0
>> >>>> -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl
>> >>>> -display gtk,gl=on,show-cursor=on -device usb-ehci,id=usb
>> >>>> -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
>> >>>>
>> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.715: eglMakeCurrent failed
>> >>>>     (qemu:46029): Gdk-WARNING **: 16:43:53.716: eglMakeCurrent failed
>> >>>>
>> >>>> When using SDL, the error messages are slightly different:
>> >>>>
>> >>>>     phytium@d3000:~/working/qemu$
>> >>>> /usr/local/bin/qemu-system-aarch64 --machine virt,accel=kvm
>> >>>> -cpu host -smp 4 -m 4G -drive
>> >>>> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
>> >>>> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0
>> >>>> -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl
>> >>>> -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb
>> >>>> -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
>> >>>>
>> >>>>     vrend_renderer_fill_caps: Entering with stale GL error: 1286
>> >>>>
>> >>>
>> >>> Hi,
>> >>>
>> >>> 1. Please make sure that you're not only building QEMU against your
>> >>> virglrenderer version, but also setting LD_LIBRARY_PATH properly at
>> >>> runtime. Best to remove system version of virglrenderer if unsure,
>> >>
>> >> I built and installed virglrenderer with the --prefix=/usr option, so
>> >>  it replaces the system version as expected.
>> >>
>> >>>
>> >>> 2. Can you reproduce this problem using tcg instead of kvm?
>> >>>
>> >>
>> >>  yes, change qemu command '--machine virt,accel=kvm -cpu host' to
>> >> '--machine virt -cpu max' can reproduce this problem. 
>> >>> -- 
>> >>> Best regards,
>> >>> Dmitry
>> >>
>> >> diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
>> >> index f6df9dcb..f6e06842 100644
>> >> --- a/src/vrend_renderer.c
>> >> +++ b/src/vrend_renderer.c
>> >> @@ -12808,7 +12808,7 @@ void vrend_renderer_fill_caps(uint32_t set, uint32_t version,
>> >>                                union virgl_caps *caps)
>> >>  {
>> >>     int gl_ver, gles_ver;
>> >> -   GLenum err;
>> >> +   GLenum err = GL_NO_ERROR;
>> >>     bool fill_capset2 = false;
>> >>  
>> >>     if (!caps)
>> >>
>> >> phytium@d3000:~/working/qemu$ git log --oneline  -n 10
>> >> e0286f56c8 (HEAD -> native-context-v11, origin/native-context-v11) Revert "amd_iommu: Add support for pass though mode"
>> >> d6e9eb0f0d docs/system: virtio-gpu: Document host/guest requirements
>> >> 55db821ea5 docs/system: virtio-gpu: Update Venus link
>> >> 003940db9a docs/system: virtio-gpu: Add link to Mesa VirGL doc
>> >> 7674e82755 ui/gtk: Don't disable scanout when display is refreshed
>> >> 712fd024e3 ui/sdl2: Don't disable scanout when display is refreshed
>> >> 9003da356f virtio-gpu: Support DRM native context
>> >> e2ff4f4a48 virtio-gpu: Support asynchronous fencing
>> >> 25458c7625 virtio-gpu: Handle virgl fence creation errors
>> >>
>> >> I tried initializing GLenum err = GL_NO_ERROR in vrend_renderer_fill_caps, but it doesn’t seem to resolve the “Entering with stale GL error: 1286” message. However, this error might not be directly related to the VM black screen issue. I noticed that even when the VM was working correctly—specifically when I reset to commit 25458c7625—the same GL error still appeared.
>> > 
>> > Thanks for the report. I confirm that something is wrong with virgl when
>> > async fencing is used. Don't have this GL 1286 error, but getting a
>> > lockup on ARM VM and with one of my new x64 VM setups. Will investigate
>> > further and report back here.
>> 
>> Hi, Cong. Please give a test to [1]. It fixes the problem for me.
>> 
>> [1] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1518
>> 
>> -- 
>> Best regards,
>> Dmitry
>
>
> 信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮
> 件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组
> 织和个人透露本邮件所含信息。Information Security Notice: The
> information contained in this mail is solely property of the sender's
> organization.This mail communication is confidential.Recipients named
> above are obligated to maintain secrecy and are not permitted to
> disclose the contents of this communication to others.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Sean Christopherson]

On Sun, Apr 27, 2025, Alex Bennée wrote:
> 刘聪 <liucong2565@phytium.com.cn> writes:
> 
> > Hi Dmitry,
> >
> > The virglrender patch can fix the virgl issue, but the native context still
> > fails to run on my machine.  I'm not sure if anyone has successfully run it
> > on an ARM64 machine before.
> >
> > When running with Venus, the virtual machine can successfully run vkcube.
> > However, when using the native context, a KVM error is triggered. Both my
> > guest and host kernels are already updated to version 6.14.
> >
> > Here are the commands and error messages I encountered:
> >
> > ```
> > phytium@ubuntu:~/working/virglrenderer$
> > /opt/native-context-v11/bin/qemu-system-aarch64 --machine
> > virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
> > file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
> > -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
> > virtio-net-pci,netdev=net0 -device
> > virtio-gpu-gl,hostmem=4G,blob=on,venus=on -object
> > memory-backend-memfd,id=mem1,size=4G -display sdl,gl=on,show-cursor=on
> > -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device
> > usb-kbd,bus=usb.0
> > phytium@ubuntu:~/working/virglrenderer$ 
> > phytium@ubuntu:~/working/virglrenderer$
> > /opt/native-context-v11/bin/qemu-system-aarch64 --machine
> > virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
> > file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
> > -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
> > virtio-net-pci,netdev=net0 -device
> > virtio-gpu-gl,hostmem=4G,blob=on,drm_native_context=on -object
> > memory-backend-memfd,id=mem1,size=4G -display sdl,gl=on,show-cursor=on
> > -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device
> > usb-kbd,bus=usb.0
> > error: kvm run failed Bad address
> 
> That very much looks like a page not being accessible when trying to do
> something.

Yep.  The most likely scenario where KVM_RUN returns -EFAULT is when KVM can't
obtain a PFN for the faulting GPA.  Odds are good it's this code:

	pfn = __kvm_faultin_pfn(memslot, gfn, write_fault ? FOLL_WRITE : 0,
				&writable, &page);
	if (pfn == KVM_PFN_ERR_HWPOISON) {
		kvm_send_hwpoison_signal(hva, vma_shift);
		return 0;
	}
	if (is_error_noslot_pfn(pfn))   <==========
		return -EFAULT;

where under the hood, __kvm_faultin_pfn() is a wrapper to gup() and
follow_pfnmap_start() (and some other things).

If you can figure out which GPA is failing, then it's "just" a matter of figuring
out why KVM doesn't find a valid mapping.

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Dmitry Osipenko]

On 4/27/25 14:53, 刘聪 wrote:
> Hi Dmitry,
> 
> The virglrender patch can fix the virgl issue, but the native context still fails to run on my machine.
> I'm not sure if anyone has successfully run it on an ARM64 machine before.

Thanks for the testing!

> When running with Venus, the virtual machine can successfully run vkcube. However, when using the native context, a KVM error is triggered. Both my guest and host kernels are already updated to version 6.14.
> 
> Here are the commands and error messages I encountered:
> 
> ```
> phytium@ubuntu:~/working/virglrenderer$ /opt/native-context-v11/bin/qemu-system-aarch64 --machine virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl,hostmem=4G,blob=on,venus=on -object memory-backend-memfd,id=mem1,size=4G  -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> phytium@ubuntu:~/working/virglrenderer$ 
> phytium@ubuntu:~/working/virglrenderer$ /opt/native-context-v11/bin/qemu-system-aarch64 --machine virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -device virtio-gpu-gl,hostmem=4G,blob=on,drm_native_context=on -object memory-backend-memfd,id=mem1,size=4G  -display sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> error: kvm run failed Bad address
>  PC=0000e2bcbbf31ab0 X00=0000e2bc9c3ae060 X01=0000e2bc7c02af00
> X02=0000000000000014 X03=0000e2bc9c3ae000 X04=0000e2bc7c02af14
> X05=0000e2bc9c3ae074 X06=0000000000000200 X07=0000e2bc7c02a8f8
> X08=00000000000000de X09=0000000000000200 X10=0000000000001000
> X11=0000000000000004 X12=0000e2bc7c0000b0 X13=0000000000000001
> X14=0000000000000020 X15=0000e2bc9e465f93 X16=0000e2bcad6a01f0
> X17=0000e2bcbbf31a80 X18=0000000000000093 X19=0000000000000060
> X20=0000000000000074 X21=0000e2bc9e46c5f0 X22=0000e2bc9c3ae000
> X23=0000000000000074 X24=0000c02241da83b0 X25=0000c02241da85a0
> X26=0000c02241da85a0 X27=0000000000000014 X28=0000e2bc9e46c5f0
> X29=0000e2bc9e46c610 X30=0000e2bcac809c38  SP=0000e2bc9e46c510
> PSTATE=20001000 --C- EL0t
> phytium@ubuntu:~/working/virglrenderer$ uname -a
> Linux ubuntu 6.14.1-061401-generic #202504071048 SMP PREEMPT_DYNAMIC Mon Apr  7 11:34:37 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
> ```

Alex Bennée reported the very same problem with KVM on ARM + native ctx
AMD dGPU in the past. You may try to add error messages to
virt/kvm/kvm_main.c of host Linux kernel to find from where KVM error
originates. Sounds like page refcounting may be not working properly on ARM.

+CC: Sean Christopherson

-- 
Best regards,
Dmitry

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> On 4/27/25 14:53, 刘聪 wrote:
>> Hi Dmitry,
>> 
>> The virglrender patch can fix the virgl issue, but the native context still fails to run on my machine.
>> I'm not sure if anyone has successfully run it on an ARM64 machine before.
>
> Thanks for the testing!
>
>> When running with Venus, the virtual machine can successfully run vkcube. However, when using the native context, a KVM error is triggered. Both my guest and host kernels are already updated to version 6.14.
>> 
>> Here are the commands and error messages I encountered:
>> 
>> ```
>> phytium@ubuntu:~/working/virglrenderer$
>> /opt/native-context-v11/bin/qemu-system-aarch64 --machine
>> virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
>> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
>> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
>> virtio-net-pci,netdev=net0 -device
>> virtio-gpu-gl,hostmem=4G,blob=on,venus=on -object
>> memory-backend-memfd,id=mem1,size=4G -display
>> sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device
>> usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
>> phytium@ubuntu:~/working/virglrenderer$ 
>> phytium@ubuntu:~/working/virglrenderer$
>> /opt/native-context-v11/bin/qemu-system-aarch64 --machine
>> virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
>> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
>> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
>> virtio-net-pci,netdev=net0 -device
>> virtio-gpu-gl,hostmem=4G,blob=on,drm_native_context=on -object
>> memory-backend-memfd,id=mem1,size=4G -display
>> sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device
>> usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
>> error: kvm run failed Bad address
>>  PC=0000e2bcbbf31ab0 X00=0000e2bc9c3ae060 X01=0000e2bc7c02af00
>> X02=0000000000000014 X03=0000e2bc9c3ae000 X04=0000e2bc7c02af14
>> X05=0000e2bc9c3ae074 X06=0000000000000200 X07=0000e2bc7c02a8f8
>> X08=00000000000000de X09=0000000000000200 X10=0000000000001000
>> X11=0000000000000004 X12=0000e2bc7c0000b0 X13=0000000000000001
>> X14=0000000000000020 X15=0000e2bc9e465f93 X16=0000e2bcad6a01f0
>> X17=0000e2bcbbf31a80 X18=0000000000000093 X19=0000000000000060
>> X20=0000000000000074 X21=0000e2bc9e46c5f0 X22=0000e2bc9c3ae000
>> X23=0000000000000074 X24=0000c02241da83b0 X25=0000c02241da85a0
>> X26=0000c02241da85a0 X27=0000000000000014 X28=0000e2bc9e46c5f0
>> X29=0000e2bc9e46c610 X30=0000e2bcac809c38  SP=0000e2bc9e46c510
>> PSTATE=20001000 --C- EL0t
>> phytium@ubuntu:~/working/virglrenderer$ uname -a
>> Linux ubuntu 6.14.1-061401-generic #202504071048 SMP PREEMPT_DYNAMIC Mon Apr  7 11:34:37 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
>> ```
>
> Alex Bennée reported the very same problem with KVM on ARM + native ctx
> AMD dGPU in the past. You may try to add error messages to
> virt/kvm/kvm_main.c of host Linux kernel to find from where KVM error
> originates. Sounds like page refcounting may be not working properly
> on ARM.

Also what hardware is the machine? The AVA (and most things with the
same chipset) have a broken PCI which needs a workaround for unaligned
SIMD access:

  https://github.com/stsquad/linux/tree/testing/altra-tweaks-for-gpu

>
> +CC: Sean Christopherson

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[liucong2565]

I user Phytium D3000 8 Core, and I am not sure if it has a broken PCI.

https://www.cpubenchmark.net/cpu.php?cpu=ARM+Phytium+D3000+8+Core+2500+MHz


Regards,
cong


> -----Original Messages-----
> From: "Alex Bennée" <alex.bennee@linaro.org>
> Send time:Monday, 04/28/2025 18:07:11
> To: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>
> Cc: 刘聪 <liucong2565@phytium.com.cn>, "Sean Christopherson" <seanjc@google.com>, Jiqian.Chen@amd.com, akihiko.odaki@daynix.com, alexander.deucher@amd.com, christian.koenig@amd.com, gert.wollny@collabora.com, gurchetansingh@chromium.org, hi@alyssa.is, honglei1.huang@amd.com, julia.zhang@amd.com, kraxel@redhat.com, marcandre.lureau@redhat.com, mst@redhat.com, pbonzini@redhat.com, philmd@linaro.org, pierre-eric.pelloux-prayer@amd.com, qemu-devel@nongnu.org, ray.huang@amd.com, robdclark@gmail.com, roger.pau@citrix.com, slp@redhat.com, stefano.stabellini@amd.com, xenia.ragiadakou@amd.com, zzyiwei@chromium.org
> Subject: Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing
> 
> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> 
> > On 4/27/25 14:53, 刘聪 wrote:
> >> Hi Dmitry,
> >> 
> >> The virglrender patch can fix the virgl issue, but the native context still fails to run on my machine.
> >> I'm not sure if anyone has successfully run it on an ARM64 machine before.
> >
> > Thanks for the testing!
> >
> >> When running with Venus, the virtual machine can successfully run vkcube. However, when using the native context, a KVM error is triggered. Both my guest and host kernels are already updated to version 6.14.
> >> 
> >> Here are the commands and error messages I encountered:
> >> 
> >> ```
> >> phytium@ubuntu:~/working/virglrenderer$
> >> /opt/native-context-v11/bin/qemu-system-aarch64 --machine
> >> virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
> >> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
> >> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
> >> virtio-net-pci,netdev=net0 -device
> >> virtio-gpu-gl,hostmem=4G,blob=on,venus=on -object
> >> memory-backend-memfd,id=mem1,size=4G -display
> >> sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device
> >> usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> >> phytium@ubuntu:~/working/virglrenderer$ 
> >> phytium@ubuntu:~/working/virglrenderer$
> >> /opt/native-context-v11/bin/qemu-system-aarch64 --machine
> >> virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
> >> file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
> >> -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
> >> virtio-net-pci,netdev=net0 -device
> >> virtio-gpu-gl,hostmem=4G,blob=on,drm_native_context=on -object
> >> memory-backend-memfd,id=mem1,size=4G -display
> >> sdl,gl=on,show-cursor=on -device usb-ehci,id=usb -device
> >> usb-mouse,bus=usb.0 -device usb-kbd,bus=usb.0
> >> error: kvm run failed Bad address
> >>  PC=0000e2bcbbf31ab0 X00=0000e2bc9c3ae060 X01=0000e2bc7c02af00
> >> X02=0000000000000014 X03=0000e2bc9c3ae000 X04=0000e2bc7c02af14
> >> X05=0000e2bc9c3ae074 X06=0000000000000200 X07=0000e2bc7c02a8f8
> >> X08=00000000000000de X09=0000000000000200 X10=0000000000001000
> >> X11=0000000000000004 X12=0000e2bc7c0000b0 X13=0000000000000001
> >> X14=0000000000000020 X15=0000e2bc9e465f93 X16=0000e2bcad6a01f0
> >> X17=0000e2bcbbf31a80 X18=0000000000000093 X19=0000000000000060
> >> X20=0000000000000074 X21=0000e2bc9e46c5f0 X22=0000e2bc9c3ae000
> >> X23=0000000000000074 X24=0000c02241da83b0 X25=0000c02241da85a0
> >> X26=0000c02241da85a0 X27=0000000000000014 X28=0000e2bc9e46c5f0
> >> X29=0000e2bc9e46c610 X30=0000e2bcac809c38  SP=0000e2bc9e46c510
> >> PSTATE=20001000 --C- EL0t
> >> phytium@ubuntu:~/working/virglrenderer$ uname -a
> >> Linux ubuntu 6.14.1-061401-generic #202504071048 SMP PREEMPT_DYNAMIC Mon Apr  7 11:34:37 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
> >> ```
> >
> > Alex Bennée reported the very same problem with KVM on ARM + native ctx
> > AMD dGPU in the past. You may try to add error messages to
> > virt/kvm/kvm_main.c of host Linux kernel to find from where KVM error
> > originates. Sounds like page refcounting may be not working properly
> > on ARM.
> 
> Also what hardware is the machine? The AVA (and most things with the
> same chipset) have a broken PCI which needs a workaround for unaligned
> SIMD access:
> 
>   https://github.com/stsquad/linux/tree/testing/altra-tweaks-for-gpu
> 
> >
> > +CC: Sean Christopherson
> 
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro


信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.

Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Alex Bennée]

liucong2565@phytium.com.cn writes:

> I user Phytium D3000 8 Core, and I am not sure if it has a broken PCI.
>
> https://www.cpubenchmark.net/cpu.php?cpu=ARM+Phytium+D3000+8+Core+2500+MHz

Ahh - looks totally unrelated to the Altera platform so hopefully that
isn't an issue. Apparently a lot of the PCIe implementations are based
off the same underlying IP but without details its hard to check.

I assume everything runs fine directly when not virtualised? Without a
patched kernel on the AVA you would see corruption for X11 systems
(although not Wayland). e.g.:

  https://gitlab.freedesktop.org/mesa/mesa/-/issues/9100


If you are happy your Arm can drive the AMD GPU ok from the host system
you should focus on verifying the page locking is working as intended
for the guests.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

[PATCH v11 05/10] virtio-gpu: Support DRM native context

[Dmitry Osipenko]

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>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
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 ee896eced67c..184ad2c588f7 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -1248,6 +1248,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);
@@ -1310,5 +1323,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.48.1

[PATCH v11 06/10] ui/sdl2: Don't disable scanout when display is refreshed

[Dmitry Osipenko]

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>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
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.48.1

[PATCH v11 07/10] ui/gtk: Don't disable scanout when display is refreshed

[Dmitry Osipenko]

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>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
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.48.1

[PATCH v11 08/10] docs/system: virtio-gpu: Add link to Mesa VirGL doc

[Dmitry Osipenko]

Extend virtio-gpu documentation with a link to the Mesa VirGL
documentation.

Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 docs/system/devices/virtio-gpu.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst
index f20c60016376..f8963c1f13cf 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -59,7 +59,7 @@ on typical modern Linux distributions.
 virtio-gpu virglrenderer
 ------------------------
 
-When using virgl accelerated graphics mode in the guest, OpenGL API calls
+When using `virgl`_ accelerated graphics mode in the guest, OpenGL API calls
 are translated into an intermediate representation (see `Gallium3D`_). The
 intermediate representation is communicated to the host and the
 `virglrenderer`_ library on the host translates the intermediate
@@ -68,6 +68,7 @@ representation back to OpenGL API calls.
 .. parsed-literal::
     -device virtio-gpu-gl
 
+.. _virgl: https://docs.mesa3d.org/drivers/virgl.html
 .. _Gallium3D: https://www.freedesktop.org/wiki/Software/gallium/
 .. _virglrenderer: https://gitlab.freedesktop.org/virgl/virglrenderer/
 
-- 
2.48.1

[PATCH v11 09/10] docs/system: virtio-gpu: Update Venus link

[Dmitry Osipenko]

Change virtio-gpu Venus link, pointing it at the Mesa Venus
documentation instead of the protocol. The Mesa doc provides more
information and also has a link to the protocol.

Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 docs/system/devices/virtio-gpu.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst
index f8963c1f13cf..ea3eb052df3c 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -81,7 +81,7 @@ of virtio-gpu host memory window. This is typically between 256M and 8G.
 .. parsed-literal::
     -device virtio-gpu-gl,hostmem=8G,blob=true,venus=true
 
-.. _venus: https://gitlab.freedesktop.org/virgl/venus-protocol/
+.. _venus: https://docs.mesa3d.org/drivers/venus.html
 
 DRM native context is supported since release of `virglrenderer`_ v1.0.0
 using `drm`_ protocol.  ``DRM`` virtio-gpu capability set ("capset") requires
-- 
2.48.1

[PATCH v11 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Dmitry Osipenko]

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: 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 | 101 ++++++++++++++++++++++++++++-
 1 file changed, 98 insertions(+), 3 deletions(-)

diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst
index ea3eb052df3c..ed952468c331 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -5,14 +5,28 @@ virtio-gpu
 ==========
 
 This document explains the setup and usage of the virtio-gpu device.
-The virtio-gpu device paravirtualizes the GPU and display controller.
+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.
 
-Linux kernel support
---------------------
+Linux guest kernel support
+--------------------------
 
 virtio-gpu requires a guest Linux kernel built with the
 ``CONFIG_DRM_VIRTIO_GPU`` option.
 
+3D acceleration
+---------------
+
+3D acceleration of a virtualized GPU is still an evolving field.
+Depending on the 3D mode you are running you may need to override
+distribution supplied libraries with more recent versions or enable
+build options. There are a number of requirements the host must meet
+to be able to be able to support guests. QEMU must be able to access the
+host's GPU and for the best performance be able to reliably share GPU
+memory with the guest. Details of 3D acceleration requirements are
+described in a further sections.
+
 QEMU virtio-gpu variants
 ------------------------
 
@@ -65,8 +79,14 @@ intermediate representation is communicated to the host and the
 `virglrenderer`_ library on the host translates the intermediate
 representation back to OpenGL API calls.
 
+By default OpenGL version on guest is limited to 4.3. In order to enable
+OpenGL 4.6 support, virtio-gpu  host blobs feature (``hostmem`` and ``blob``
+fields) should be enabled.  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
+    -device virtio-gpu-gl,hostmem=8G,blob=true
 
 .. _virgl: https://docs.mesa3d.org/drivers/virgl.html
 .. _Gallium3D: https://www.freedesktop.org/wiki/Software/gallium/
@@ -94,6 +114,63 @@ of virtio-gpu host memory window. This is typically between 256M and 8G.
 
 .. _drm: https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm
 
+.. list-table:: Linux Host Requirements
+  :header-rows: 1
+
+  * - Capability
+    - Kernel Version
+    - Libvirglrenderer Version
+  * - OpenGL pass-through
+    - Any Linux version compatible with QEMU if not using host blobs feature,
+      Linux 6.13+ otherwise
+    - 0.8.2+
+  * - Vulkan pass-through
+    - Linux 6.13+
+    - 1.0.0+
+  * - AMDGPU DRM native context
+    - Linux 6.13+
+    - 1.1.0+
+  * - Freedreno DRM native context
+    - Linux 6.4+
+    - 1.0.0+
+  * - Intel i915 DRM native context
+    - Linux 6.13+
+    - `mr1384`_
+  * - Asahi DRM native context
+    - `Downstream version`_ of Asahi Linux kernel
+    - `mr1274`_
+
+.. _mr1384: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384
+.. _mr1274: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274
+.. _Downstream version: https://github.com/AsahiLinux/linux
+
+.. list-table:: Linux Guest Requirements
+  :header-rows: 1
+
+  * - Capability
+    - Kernel Version
+    - Mesa Version
+  * - OpenGL pass-through
+    - Any Linux version supporting virtio-gpu
+    - 16.0.0+
+  * - Vulkan pass-through
+    - Linux 5.16+
+    - 24.2.0+
+  * - AMDGPU DRM native context
+    - Linux 6.14+
+    - 25.0.0+
+  * - Freedreno DRM native context
+    - Linux 6.14+
+    - 23.1.0+
+  * - Intel i915 DRM native context
+    - Linux 6.14+
+    - `mr29870`_
+  * - Asahi DRM native context
+    - Linux 6.14+
+    - 24.2.0+
+
+.. _mr29870: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870
+
 virtio-gpu rutabaga
 -------------------
 
@@ -133,3 +210,21 @@ Surfaceless is the default if ``wsi`` is not specified.
 .. _Wayland display passthrough: https://www.youtube.com/watch?v=OZJiHMtIQ2M
 .. _gfxstream-enabled rutabaga: https://crosvm.dev/book/appendix/rutabaga_gfx.html
 .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html
+
+.. list-table:: Linux Host Requirements
+  :header-rows: 1
+
+  * - Capability
+    - Kernel Version
+  * - Vulkan+Wayland pass-through
+    - Linux 6.13+
+
+.. list-table:: Linux Guest Requirements
+  :header-rows: 1
+
+  * - Capability
+    - Kernel Version
+    - Mesa Version
+  * - Vulkan+Wayland pass-through
+    - Linux 5.16+
+    - 24.3.0+
-- 
2.48.1

Re: [PATCH v11 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Akihiko Odaki]

On 2025/03/10 21:05, 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: Sergio Lopez Pascual <slp@redhat.com>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> [dmitry.osipenko@collabora.com: Extended and corrected doc]

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>

Re: [PATCH v11 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Dmitry Osipenko]

On 3/10/25 15:25, Akihiko Odaki wrote:
> On 2025/03/10 21:05, 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: Sergio Lopez Pascual <slp@redhat.com>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> [dmitry.osipenko@collabora.com: Extended and corrected doc]
> 
> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>

Thanks a lot for the quick review!

-- 
Best regards,
Dmitry