On Fr, 2016-07-15 at 10:35 -0400, Kevin O'Connor wrote:
On Fri, Jul 15, 2016 at 01:49:49PM +0200, Gerd Hoffmann wrote:
Finally, one high level observation is that we know there are a number of quirks in various vgabios emulators. For example, we know some emulators don't handle certain 32bit instructions when in 16bit mode (hence scripts/vgafixup.py), we know some versions of Windows use an emulator that doesn't like some stack relative instructions (hence the vgabios is compiled without -fomit-frame-pointer), and we know Windows Vista doesn't like the extra stack in high ram (the skifree bug). Any thoughts on what happens with these quirks if the main seabios code hooks int10?
Good question. Do the emulators (both win, xorg) use the int10 vector set by seabios in the first place? Or go they load the vgabios and run it, including the initialization, and use whatever entry point the init code sets up? I suspect it is the latter. But needs investigation and testing.
I think they just call the existing int10 handler. In general, it's not safe to rerun the vga init code. Also, if they did run the init it would lead to extra copies of the SeaVGABIOS version banners in the debug logs, which I don't recall seeing.
Finally found the time to continue with this and ran a bunch of tests. RHEL-5 (known to be affected by x86emu issue) continues to work fine. Xorg server log looks like it goes scan memory for the vgabios instead of depending on the int10 vector:
(II) VESA(0): initializing int10 (II) VESA(0): Primary V_BIOS segment is: 0xc000 (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 16384 kB (II) VESA(0): VESA VBE OEM: SeaBIOS VBE(C) 2011 (II) VESA(0): VESA VBE OEM Software Rev: 0.0 (II) VESA(0): VESA VBE OEM Vendor: SeaBIOS Developers (II) VESA(0): VESA VBE OEM Product: SeaBIOS VBE Adapter (II) VESA(0): VESA VBE OEM Product Rev: Rev. 1
Running tests with win7 doesn't show any problems too, so I suspect they are basically doing the same.
Given these results I think I'll stick to the current approach of integrating this directly into seabios (instead of creating a sgabios-like rom using the seavgabios sources).
cheers, Gerd