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

[Liav Albani]

On 9/21/22 09:14, Gerd Hoffmann wrote:
> Nope.  Even if you fix the framebuffer address conflict you still have
> the io address conflict.
Yeah, that is why I explicitly said that this is needed to be fixed as 
well in later patches.
> Yep.  That's why isa-pc is pretty much unused these days.

Well, I can't say I use it frequently, but I do test it with the 
SerenityOS kernel and it works pretty well.
The SerenityOS kernel is able to drive an isa-vga device just fine after 
my patches were merged yesterday (in the GitHub pull request I provided 
a link to), so I do see that machine type as a valuable test platform.

> When you want build a sysbus variant of the bochs-display device and
> make that discoverable by the guest somehow (dt or acpi) you can expose
> both io ports and framebuffer address that way.  No need to touch the
> bochs dispi interface for that.
This is an interesting idea. A sysbus-bochs-display device might work 
well as you suggested,
instead of using an isa-vga 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.
> Why not just use virtio-gpu?

Trying to run this command:
qemu-system-x86_64 -M microvm -m 2048 -device virtio-gpu

Results in:
qemu-system-x86_64: -device virtio-gpu: No 'PCI' bus found for device 
'virtio-gpu-pci'

The idea was to not use PCI at all but still to have multiple 
framebuffer devices. So clearly virtio-gpu
is not usable in this situation.

> > 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.
> Yea, fully agree, but why continue to use non-discoverable isa bus
> devices then?

On the ISA-PC machine, I still want to be able to boot into a graphical 
environment with the SerenityOS kernel. The only option is
to use the isa-vga device, which works OK.
On the microvm machine, it is really not that important if I use the 
isa-vga device or a sysbus-bochs-display device (when I implement that
device).
I just want to support as many x86 platform configurations as possible - 
modern non-PCI machines, ISA-PC machines and regular i440fx/Q35 machines.

> > 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.
> Touching isa-vga at this point doesn't make sense at all.  We simply
> can't move around the framebuffer without screwing up users.
That's an issue I didn't consider, but this is not a real problem on the 
microvm machine
if you use the device tree approach to expose the resources of the 
device, which in some sense makes it unnecessary
to use the bochs dispi interface to expose the framebuffer physical address.
> Also I don't see any actual value in this.  Even considering the
> multiple devices case the patch is a partial solution only (handles
> the framebuffer but not the ioports) which is pointless.
Considering the possibility of exposing the framebuffer address within 
the device tree blob, it is indeed not making more value
to go with this approach. I'm still fond of the idea to create a sysbus 
variant of the bochs-display device, so I might work on that instead :)

Best regards,
Liav