qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 0/1] hw/display: expose linear framebuffer address in Bochs VBE r


From: Liav Albani
Subject: [PATCH 0/1] hw/display: expose linear framebuffer address in Bochs VBE registers
Date: Tue, 20 Sep 2022 18:49:21 +0300

Recently I submitted patches to the SerenityOS project in regard to
enhancing the overall abstractions of x86-specific hardware support
code in the SerenityOS kernel in preparation for aarch64 support.
Then, I moved on to submit another patch to introduce support of the
isa-vga device, as we currently allow people to run an ISA-PC machine
with SerenityOS without any GUI (see this link for more details -
https://github.com/SerenityOS/serenity/pull/15259).

This all worked pretty well and with the patches being applied it is
possible to boot into a graphical environment. However, not all things
are perfect (yet). To ensure we only create a driver instance for an
isa-vga device, I try to ensure that PCI was disabled due to failed
hardware test and not because of a user decision, to ensure that we do
not try to drive a PCI stdvga device with an ISA device-targeted HW
parameters. This worked well too, but one problem is left now - I still
had to hardcode the framebuffer address to 0xE0000000 in the driver.

Honestly, it's not a big issue of its own - many devices are assumed to
exist at well-defined physical memory addresses, especially when it is
related to plain old ISA devices. However, I still want to fix this,
for these reasons:
1. Although it is reasonable to assume no more than one isa-vga device
  will exist in one machine, this could be changed easily later on.
  As it stands now, on an ISA-PC machine with no PCI bus, there are
  basically zero methods to detect hardware - you have to assume the
  hardware is there, or just to probe for it and hope for the best.

  Relying on the BIOS to do hardware detection is also a possibility
  as it knows the best upon the platform it being used on.
  In the SerenityOS project we decided for the time being to not use
  the BIOS as that will require doing hacky stuff to use 16-bit code
  segments. Also, the BIOS is not perfect and of course it does not
  give you every little detail you might want, as long as we consider
  the standard services of an x86 BIOS these days.

  For an ISA-PC machine, the assumption of one isa-vga device at
  most is OK and will be true in the future as well.

  However, for other machines, and the one I am especially interested
  in, the microvm machine, this claim could be easily revoked as the
  microvm machine exposes a device tree - we could easily place many
  ISA-VGA devices on the "System bus" of a virtual machine, essentially
  having multiple framebuffer devices on such machine setup, with no PCI
  bus being involved at all. Of course, we will need to figure out how
  to make some sort of an ISA-VGA device that resembles a bochs-display
  device - it should not have VGA capabilities because otherwise the
  devices' resources will be in conflict for VGA control of the VGA IO
  space. The Bochs VBE registers will also need to be located in
  different IO ports too for each device.

  This idea is quite neat in my opinion, because it could speed up the
  boot of such VM while still providing sufficient display capabilities
  for those we need them. It could help developers to test their OSes
  on such hardware setups to ensure multi-monitor configuration works
  reliably when there's no PCI bus at all but many framebuffer devices
  being used in one VM.

2. This is more related to the SerenityOS project - I prefer to not 
  hardcode physical addresses at all wherever I can do so. This makes
  the code cleaner and more understandable as far as I observe this from
  the angle of the person which is not me, that tries to make sense from
  the code flow.

3. The costs of adding this feature are pretty negligible compared to
  the possible value of this, especially if we apply the idea of running
  multiple ISA-VGA devices on one microvm machine. Still, the only major
  "issue" that one can point to is the fact that I bump up the Bochs VBE
  version number, which could be questionable with how the feature might
  be insignificant for many guest OSes out there.

Liav Albani (1):
  hw/display: expose linear framebuffer address in Bochs VBE registers

 hw/display/bochs-display.c     | 10 +++++++++-
 hw/display/vga.c               | 13 +++++++++++--
 include/hw/display/bochs-vbe.h |  7 ++++++-
 3 files changed, 26 insertions(+), 4 deletions(-)

-- 
2.37.3




reply via email to

[Prev in Thread] Current Thread [Next in Thread]