From: Dario Faggioli <dfaggioli@suse.com>
To: qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
anthony@xenproject.org, edgar.iglesias@gmail.com,
philmd@mailo.com, odaki@rsg.ci.i.u-tokyo.ac.jp,
Dario Faggioli <dfaggioli@suse.com>
Subject: [RFC PATCH 0/1] hw/display/xenfb: always register vfb and allocate console early
Date: Mon, 24 Aug 2026 09:11:15 +0200 [thread overview]
Message-ID: <20260824071116.935828-1-dfaggioli@suse.com> (raw)
Hello,
We've been having an issue with Xen PV and PVH guests' console since:
https://bugzilla.suse.com/show_bug.cgi?id=1232712
https://lists.nongnu.org/archive/html/qemu-devel/2024-12/msg02294.html
Back then, until our QEMU 11.0 package, I "solved" it locally by reverting
these two commits:
6ece1df966 hw/xen: Register framebuffer backend via xen_backend_init()
e99441a379 ui/curses: Do not use console_select()
For the 11.1 package, I decided it was enough and finally managed to find
the time to investigate a bit more (and, yes, I know I should have done
this earlier, but never could... Sorry :-( ).
From my debugging, these are the problems:
1. Commit 6ece1df966 restricted the vfb backend registration under an
'if (vga_interface_type == VGA_XENFB)'. However, it can happen that the
-vga parameter is just not provided (e.g., for PV and PVH guests) and the
backend is never initialized.
2. Once the backend is registered, xenfb defers the QemuConsole creation to
fb_initialise(). The VNC server, though, starts earlier, finds no active
consoles, and binds to the dummy surface (black screen showing the message
"This VM has no graphic display device"). Furthermore, since the removal
of console_select(), such surface is never dropped for switching to the
actual xenfb console.
I have drafted a patch to address both issues. It removes the
vga_interface_type check and moves qemu_graphic_console_create() to fb_init()
so the console is created "early enough".
I am sending this as an RFC because, although it fixes the problem in my
testing, I am no expert in the QEMU UI subsystem and I am not sure that these
are the correct and/or the best solutions.
I'm happy to try to come up and/or to test different approaches and/or patches.
Thanks and Regards,
Dario
Dario Faggioli (1):
hw/display/xenfb: always register vfb and allocate console early
hw/display/xenfb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--
2.55.0
next reply other threads:[~2026-08-24 7:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 7:11 Dario Faggioli [this message]
2026-08-24 7:11 ` [RFC PATCH 1/1] hw/display/xenfb: always register vfb and allocate console early Dario Faggioli
2026-08-24 13:59 ` Akihiko Odaki
2026-08-24 14:55 ` Akihiko Odaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260824071116.935828-1-dfaggioli@suse.com \
--to=dfaggioli@suse.com \
--cc=anthony@xenproject.org \
--cc=edgar.iglesias@gmail.com \
--cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
--cc=philmd@mailo.com \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.