Re: [Qemu-devel] [PATCH 0/4] ramfb: simple boot framebuffer, no legacy vga

[Laszlo Ersek]

CC Ard & Drew

Hi,

On 11/17/17 13:04, Gerd Hoffmann wrote:
>   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.
> 
> 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.

Please add documentation on the "fourcc" (pixel format?) and "flags"
fields. Also please document the endianness of the integer fields.

> 
> 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.
> 
> 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
> 
> So, how to play?
> 
> There is ramfb-testdev.  Standalone device, for testing purposes.  Also
> listens on vga ports and logs any access, so we can see the bad boys ;)
> Use "qemu -vga none -device ramfb-testdev".
> 
> There is virtio-ramfb.  Simlar 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.

(Side note: <https://bugzilla.tianocore.org/show_bug.cgi?id=785>.)

We should make sure that any device model that combines ramfb with
another PCI display device is not matched by the OVMF driver for that
PCI display device. IOW, we should use separate PCI IDs or subsystem IDs
(I don't recall the details off-hand). I'd like to avoid messing with
the current device probing code in OVMF. It just wouldn't be nice if two
independent drivers (e.g. VirtioGpuDxe and a supposed "RamFbDxe") bound
the two interfaces at the same time.

This device will take a DXE driver or UEFI driver that does not follow
the UEFI driver model because there's no "controller handle" to bind.
(The thing to probe is an fw_cfg file.)

> 
> What works?
> 
> Boot loaders 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).
> 
> Windows (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 actual vga hardware.
> 
> Future plans:
> 
> Try use that as vgpu boot display.  Requires solving that windows issue
> somehow, otherwise it's going to be a non-starter.
> 
> Trick László into writing a UEFI driver for that.

I cannot imagine when I'll get to this. :(

Feel free to file a BZ somewhere (TianoCore or RH Bugzilla) and/or poke
me occasionally. My TODO list is full of things than are *all* more
urgenterer than all the other things on the list.

I'm nearing TODO list bankruptcy (IRL too).

> Linux will use efifb
> not vgacon then, and hopefully Windows doesn't try access vga registers
> either.
> 
> Comments?
> Hints on the windows issue anyone?

We looked into those when we worked on the Int10h VBE shim in OVMF. We
decided the VGA register accesses were way too complicated and so we did
the shim for BOCHS VGA and QXL only. IIRC. (I could be conflating things.)

This looks like a great job, honestly; I'm sorry I can't say more
positive things about a GOP driver for it right now.

Thanks,
Laszlo

> 
> enjoy,
>   Gerd
> 
> Gerd Hoffmann (4):
>   [testing] update bios, add vgabios-ramfb
>   ramfb: simple boot framebuffer living in guest ram
>   add virtio-ramfb
>   add ramfb-testdev
> 
>  include/hw/display/ramfb.h |   8 +++
>  hw/display/ramfb-testdev.c |  87 ++++++++++++++++++++++++++
>  hw/display/ramfb.c         |  94 ++++++++++++++++++++++++++++
>  hw/display/virtio-ramfb.c  | 149 
> +++++++++++++++++++++++++++++++++++++++++++++
>  hw/display/Makefile.objs   |   5 +-
>  pc-bios/bios-256k.bin      | Bin 262144 -> 262144 bytes
>  pc-bios/vgabios-ramfb.bin  | Bin 0 -> 28160 bytes
>  7 files changed, 342 insertions(+), 1 deletion(-)
>  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/vgabios-ramfb.bin
>