VESA in Long Mode using interpretation

[Brendan]

Hi,

If a video card's ROM does switch to protected mode; then you don't have to support that video card's ROM.

Why not? Maybe the graphics card has memory-mapped registers in high memory.

If a video card's ROM does switch to protected mode; but you don't support that (and clearly state in your OS's documentation "This OS doesn't support video card ROMs that switch to protected mode"), what will happen? You won't be visited by ninjas in your sleep, or imprisoned or fined by government, or taken to court by consumers.

You might want to support these cards, but then you might want to support UEFI too.


Cheers,

Brendan

[Brendan]

Hi,

Also, which IRQs do I have to forward to the guest BIOS, if any?

Potentially, anything involving timing (e.g. PIT/IRQ0), IRQ13 (used by FPU errors), and anything that belongs to the video card itself (e.g. vertical retrace IRQ). Note that I'd expect that most video card ROMs don't need/use any IRQs (and don't use protected mode); it's just that there is no guarantee and nothing preventing a video card ROM from doing anything it likes.

@Brendan: why would I need to emulate PCI chips? I will simply allow the BIOS to in/out any port it wants to.

PIC chips (Programmable Interrupt Controllers).

If real mode code expects to handle an IRQ, then it will also send an EOI to the PIC chip/s. If the OS handles some IRQs and the guest handles others IRQs (and if the guest uses the typical "non-specific EOI") then it will cause problems due to the way the PIC chip's IRQ priorities work (e.g. the guest's EOI can end the host OS's IRQ and not the IRQ it thinks it's ending). You'd also have a problem if/when the OS is using IO APICs and not using PIC chips at all.

alternatively, is it possible to somehow switch to Real Mode from Long Mode? I know you can do it from Protected Mode, but when I once accidentally attempted to disable Long Mode, the WRMSR threw a #GP.

It's possible to switch from long mode back to real mode. The problem is that the BIOS will expect any/all hardware to remain in the state it expects, and this cripples the OS's ability to be an OS (rather than a "BIOS extender"). For example; if you start using IO APICs then you'd either have to disable IO APICs and enable PICs when switching to real mode or you'd have to implement a "clever" hack/work-around to trick the BIOS into thinking its using PIC when it isn't; if you change anything in PCI configuration space you'd have to reverse those changes; etc. The other problem is that (if it's done while an OS is running and not just during boot) you'll have other unrelated device drivers (e.g. disk, network, sound, serial, etc) trying to do their job at the same time and won't want them to be broken by video mode switches; so if (e.g.) network card sends an IRQ to network card driver while you're in real mode then somehow you're going to need to deal with that (e.g. have IRQ handlers in real mode that switch back to long mode and let the network card driver handle the IRQ; or keep track of all "missed" IRQs and handle them later on when you return to long mode).

It's easier and cleaner (especially when you start thinking about how you're going to support UEFI, now or in future) to assume the firmware owns all the hardware initially (and the OS shouldn't touch any hardware initially), and at some point during boot the OS takes ownership of hardware (and never uses firmware after that).


Cheers,

Brendan

[Octocontrabass]

Does any OS at all use VESA from long mode anymore? If it's really as problematic as described here, I will go with the native driver solution.

64-bit Windows does. Linux (with the appropriate packages) does too, and not just in long mode - any mode, any CPU, any PCI-based hardware.

A native driver is always the ideal solution, but VBE is not nearly as problematic as Brendan would have you believe. Really, the only issue that you might face is configuring the PCI bus to route the VGA address spaces to the video card. The PCI specifications say that the firmware must configure legacy VGA addresses for a VGA-compatible video card, but I don't know if anything outside legacy PC BIOSes follow this requirement (and it gets confusing when there's more than one video card installed).

You might want to support these cards, but then you might want to support UEFI too.

Running the legacy PCI option ROM is not mutually exclusive with UEFI.

This also brings up another interesting idea: run the EFI option ROM instead of the legacy option ROM. This has the added benefit of (probably) not requiring legacy VGA addressing.

Potentially, anything involving timing (e.g. PIT/IRQ0), IRQ13 (used by FPU errors), and anything that belongs to the video card itself (e.g. vertical retrace IRQ). Note that I'd expect that most video card ROMs don't need/use any IRQs (and don't use protected mode); it's just that there is no guarantee and nothing preventing a video card ROM from doing anything it likes.

Any video card requiring those things probably wouldn't work in Windows either. I wouldn't bother supporting such unlikely scenarios without seeing any hardware that needs it.

[Brendan]

Hi,

Does any OS at all use VESA from long mode anymore? If it's really as problematic as described here, I will go with the native driver solution.

64-bit Windows does. Linux (with the appropriate packages) does too, and not just in long mode - any mode, any CPU, any PCI-based hardware.

As far as I know, for all recent versions of Windows if there's no video driver it falls back to a "standard VGA driver", which uses VGA registers directly and only supports 640*480 and 800*600 video modes (and does not use VBE or firmware).

A native driver is always the ideal solution, but VBE is not nearly as problematic as Brendan would have you believe. Really, the only issue that you might face is configuring the PCI bus to route the VGA address spaces to the video card. The PCI specifications say that the firmware must configure legacy VGA addresses for a VGA-compatible video card, but I don't know if anything outside legacy PC BIOSes follow this requirement (and it gets confusing when there's more than one video card installed).

There may be 2 or more video cards. For onboard video, the video card's ROM may be built into the system's ROM (and maybe even compressed to save space) and not part of the PCI device at all (making it virtually impossible to find); and for UEFI systems that don't have a built-in "legacy BIOS compatibility" mode the video card's ROM may be a UEFI driver and there may be no VBE anywhere at all. But that is just now.

Time doesn't stand still and over the next 10 years or so things will get progressively worse. By the time an OS is actually ready to be released you can probably expect that BIOS will be long dead, VBE won't exist, the hideous "legacy hacks" (in PCI bridges, etc) that are needed to support "VGA emulation" may be gone, and VGA support in video cards may also be gone. I can't accurately predict the future, and maybe all this ancient crud will still be around in some form, but (if you care about the future at all) relying on the assumption that it will exist would be extremely short-sighted.

You might want to support these cards, but then you might want to support UEFI too.

Running the legacy PCI option ROM is not mutually exclusive with UEFI.

This also brings up another interesting idea: run the EFI option ROM instead of the legacy option ROM. This has the added benefit of (probably) not requiring legacy VGA addressing.

Yes; but that has the opposite problem - currently a lot of discrete video cards don't come with UEFI ROMs. This is changing quickly though (mostly because Windows expects secure boot, and secure boot needs digitally signed UEFI drivers).

Note that I am not saying that it's impossible to work around some/most of the problems (and not saying you can't support "video mode switches after boot while in limp mode without any native driver"). I'm only saying that at the end of the day the end user isn't going to care, and will complain that there's no native video drivers regardless of how much time you spend trying to work around all the problems; and because of this it's far more effective to setup a framebuffer during boot (when it's much much easier to do it reliably without insane hacks) and use the time you would've spent on something that actually does matter (like native video drivers).


Cheers,

Brendan

[Octocontrabass]

Time doesn't stand still and over the next 10 years or so things will get progressively worse. By the time an OS is actually ready to be released you can probably expect that BIOS will be long dead, VBE won't exist, the hideous "legacy hacks" (in PCI bridges, etc) that are needed to support "VGA emulation" may be gone, and VGA support in video cards may also be gone. I can't accurately predict the future, and maybe all this ancient crud will still be around in some form, but (if you care about the future at all) relying on the assumption that it will exist would be extremely short-sighted.

I can't accurately predict the future either, but I can see people using 10-year-old hardware today.

Yes; but that has the opposite problem - currently a lot of discrete video cards don't come with UEFI ROMs. This is changing quickly though (mostly because Windows expects secure boot, and secure boot needs digitally signed UEFI drivers).

Running EFI option ROMs is not mutually exclusive with running legacy option ROMs.

I'm only saying that at the end of the day the end user isn't going to care, and will complain that there's no native video drivers regardless of how much time you spend trying to work around all the problems; and because of this it's far more effective to setup a framebuffer during boot (when it's much much easier to do it reliably without insane hacks) and use the time you would've spent on something that actually does matter (like native video drivers).

Having fun matters. Working on an interpreter for option ROMs is fun. Therefore, working on an interpreter for option ROMs matters.

[mariuszp]

Basides, being capable of running VESA can help in figuring out how to switch modes on various cards, and therefore will also help in writing a native driver.