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

[Ard Biesheuvel]

Hi all,

On 23 March 2018 at 13:27, Laszlo Ersek <address@hidden> wrote:
> Adding Ard and Marc, and keeping the context undisturbed for his sake.
> Comments at the bottom.
>
> On 03/23/18 13:25, 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 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.
>>

This exact issue occurs on actual hardware as well:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755304

so if anyone has a clue how to address it, I'm all ears.


>> 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
>>
>
> I believe the only point of this device model (and the associated guest
> fw driver) is Windows-on-KVM/aarch64.
>
> Would it be possible to make this stuff available for testing to the
> guy(s) who reported
> <https://bugzilla.tianocore.org/show_bug.cgi?id=785>? (Registration in
> the TianoCore bugzilla is open, and once you log in, you can read email
> addresses, and/or comment on BZs of course.)
>
> My earlier comments from
> <http://mid.mail-archive.com/address@hidden>
> apply, to the OVMF driver:
>
>> 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.
>
> For example, virtio-vga is already problematic like this (it could be
> driven by both Virtio10Dxe+VirtioGpuDxe, and QemuVideoDxe), and it had
> to be hacked around in Virtio10Dxe. So I'm strongly in favor of a device
> model that clearly looks like one device and one device only to the full
> set of edk2 drivers, without cross-driver hacks.
>
> (I'm not saying the "combined" device models should be removed, just
> that they should never be specified on the QEMU command line when the
> guest runs OVMF or ArmVirtQemu. Unless, of course, the combined device
> models had separate PCI-level identifiers from the original PCI display
> devices, so the fw would never be tempted to bind the PCI-based drivers
> to the combined devices.)
>
> If Ard agrees that this device model & matching edk2 driver are a good
> thing for Windows-on-KVM/aarch64, I can help clean up QemuRamfbDxe. (It
> should be a DXE driver; it should start the device path with a VenHw()
> node; the memory we allocate should be reserved memory, not runtime
> memory etc...)
>
> I vaguely remember that Ard argued against allocating (reserved) RAM for
> such purposes, because it is lost for the OS even after the OS switches
> to the native display driver.
>
> BTW I recently re-read Marc's presentation on this:
>
> http://mid.mail-archive.com/address@hidden
> http://events17.linuxfoundation.org/sites/events/files/slides/slides_10.pdf
>
> Has anyone tried the following idea from those: "perform cache
> maintenance from userspace in QEMU based on the dirty tracking bitmap
> that it uses for the VGA memory"?
>
>
> Anyway, again, personally I'm fine with this, and I'm willing to help
> clean up the edk2 driver, if:
> - Ard thinks it's a good thing for Windows-on-KVM/aarch64, and
> - the device model stays out of the way of the existing edk2 display
> drivers (if that is solved with QEMU cmdline restrictions spelled out in
> documentation, that's fine).
>
> Thanks
> Laszlo