Hi,
Ok folks, here is a experimental patch series for a legacy free boot
framebuffer. If you want play with it I recommend getting the bits from
https://www.kraxel.org/cgit/qemu/log/?h=sirius/ramfb
because they come with an updated seabios and a new vgabios rom and an
experimental OVMF build.
Functional overview
-------------------
The boot framebuffer is expected to be configured by the firmware, so it
uses fw_cfg as interface. Initialization goes as follows:
(1) Check whenever etc/ramfb is present.
(2) Allocate framebuffer from RAM.
(3) Fill struct RAMFBCfg, write it to etc/ramfb.
Done. You can write stuff to the framebuffer now, and it should appear
automagically on the screen.
Note that this isn't very efficient because it does a full display
update on each refresh. No dirty tracking. Dirty tracking would have
to be active for the whole ram slot, so that wouldn't be very efficient
either. So it is *really* intended to be only active for a short time
at boot, before the guest loaded the drivers for the real display
hardware.
Firmware support -- seabios
---------------------------
seavgabios is able to emulate vga text mode on top of a framebuffer, for
coreboot native graphics initialialization. Which works fine for
everything which writes text using the vgabios interface (basically
everyhing which works with sgabios).
So I hacked that up to work with ramfb. Right now it's proof-of-concept
code with too much cut+paste, so it will clearly need a bunch of
cleanups if this approach turns out to be workable. Look here:
https://www.kraxe.org/cgit/seabios/log/?h=ramfb
Firmware support -- edk2
------------------------
There is a EFI driver too. Likewise a hackish proof-of-concept thing,
clearly not in a mergeable state, but good enough for playing. Note
that the build disables QemuVideoDxe and VirtoGpu drivers, so ramfb is
the only supported display. Code is here:
https://github.com/kraxel/edk2/commits/ramfb
Firmware blob is in pc-bios/OVMF-ramfb.fd, to be used with -bios.
So, how to play?
----------------
There is ramfb-testdev. Standalone device, for testing purposes. Also
can listen on vga ports and logs any access, so we can see the bad boys.
Use "qemu -vga none -device ramfb-testdev". Add "vgalog=on" to watch
guests accessing vga registers.
There is virtio-ramfb. Simliar to virtio-vga, but using ramfb instead of
adding vga compatibility. Shows how you can wire up ramfb support to
some display device. Unlike virtio-vga it should work fine on arm. Use
"qemu -vga none -device virtio-ramfb" for this one.
Tried to add qxl-ramfb, for windows guest tests, but that doesn't work
yet. Don't use, unless you want help debugging ;)
There is virtio-pci-ramfb, which provides boot display support to vgpu
devices.
In general using UEFI works better than BIOS, because guests don't
expect legacy vga being present then.
What works?
-----------
Both windows and linux UEFI guests handle the ramfb GOP just fine.
BIOS boot loaders for linux all use vgabios calls for text mode, so they
show up just fine. Also ipxe, seabios itself of course. So you can
boot up your linux guest. vesafb works too.
What doesn't work?
------------------
vgacon (direct vga hardware access). Linux boots just fine
nevertheless, the only effect is that you don't see any boot messages
until the drm driver loads.
Windows in BIOS mode. Boot logo shows up just fine. But at some point
windows does lots of vga register accesses (even though it sets the
video mode via vesa bios interface) and appears to be unhappy that
things don't work as expected because there is no vga hardware
emulation.
Known issues
------------
Handover from ramfb-backed efifb to the native linux driver is tricky.
Usually efifb gets kicked out when the native driver loads because of
overlapping ressources. With efifb being in RAM instead of using a GPU
PCI bar this doesn't happen though, so you'll end up with two
framebuffer devices.
In case vgaarb classifies the GPU as primary display device fbcon will
switch all VTs over to the framebuffer device of the real GPU, so there
isn't a noticable difference. Otherwise you'll end up with a
non-visible fbcon, because it continues to run on ramfb whereas qemu
switched over to the GPU because the native linux driver initialized the
display.
xorg/wayland will show up on the GPU in any case because they prefer drm
over fbdev, so they wouldn't run on efifb.
Not tested yet
--------------
ARM.
ramfb -> gpu handover with windows guests (only ramfb-testdev so far).
enjoy,
Gerd
Gerd Hoffmann (7):
[testing] update bios, add vgabios-ramfb
[testing] add ovmf build with ramfb support
hw/display: add ramfb, a simple boot framebuffer living in guest ram
hw/display: add ramfb-testdev
hw/display: add virtio-ramfb
hw/vfio/display: add ramfb support
[wip] hw/display: add qxl-ramfb
hw/display/qxl.h | 2 +
include/hw/display/ramfb.h | 8 +++
include/hw/vfio/vfio-common.h | 2 +
hw/display/qxl.c | 47 +++++++++++--
hw/display/ramfb-testdev.c | 96 +++++++++++++++++++++++++++
hw/display/ramfb.c | 95 +++++++++++++++++++++++++++
hw/display/virtio-ramfb.c | 149 ++++++++++++++++++++++++++++++++++++++++++
hw/vfio/display.c | 10 +++
hw/vfio/pci.c | 15 +++++
ui/spice-display.c | 6 ++
hw/display/Makefile.objs | 5 +-
pc-bios/OVMF-ramfb.fd | Bin 0 -> 2097152 bytes
pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes
pc-bios/bios.bin | Bin 131072 -> 131072 bytes
pc-bios/vgabios-ramfb.bin | Bin 0 -> 28160 bytes
15 files changed, 430 insertions(+), 5 deletions(-)
create mode 100644 include/hw/display/ramfb.h
create mode 100644 hw/display/ramfb-testdev.c
create mode 100644 hw/display/ramfb.c
create mode 100644 hw/display/virtio-ramfb.c
create mode 100644 pc-bios/OVMF-ramfb.fd
create mode 100644 pc-bios/vgabios-ramfb.bin
--
2.9.3
