On Mon, Jan 12, 2015 at 02:53:58AM -0600, Richard Laager wrote:
Turning off CONFIG_VGA_ALLOCATE_EXTRA_STACK makes Skifree work on cirrus and vga.
I was able to reproduce this locally with 16bit skifree on Windows Vista. (Interestingly, the problem doesn't occur on winxp.)
The issue doesn't appear to be with the SeaVGABIOS stack switching, but with the fact that the SeaBIOS PMM code places the stack in the e-segment. Turning off MALLOC_UPPERMEMORY in SeaBIOS allows SeaVGABIOS to run even with CONFIG_VGA_ALLOCATE_EXTRA_STACK set.
My guess is that Windows is emulating the vgabios, but marking the 0xc0000-0x100000 region as read-only. Oddly, it doesn't appear as Windows actually lets the code talk to the VGA hardware, as the debug output (and presumably other in/out accesses) is suppressed. So, it's unclear what Windows is attempting to do with its emulation.
Not sure what the best way forward is here. It seems this is a choice between supporting some very old programs vs support for some other very old programs. Paolo and Gerd, maybe you have some ideas?
I can think of a few options:
1 - do nothing - let users use a modified seabios/seavgabios or the "lgpl vgabios" for this situation. Not great - specially considering how difficult it would be to know if one is in this situation or not.
2 - default SeaVGABIOS to CONFIG_VGA_ALLOCATE_EXTRA_STACK off. Known to break old programs - for example, DOS 1.0. SeaVGABIOS can use just under 300 bytes of stack space for some calls.
3 - default SeaBIOS to MALLOC_UPPERMEMORY off. Unfortunately, this wastes additional space below 640K and it's unclear what impact that would have on old programs.
4 - Change SeaVGABIOS to allocate its stack in the EBDA instead of via a PMM call. Unfortunately, I've seen at least one old DOS-era program that ignores the EBDA allocations and writes to the end of 640K memory. It's unclear how it would react to a SeaVBABIOS stack being there.
5 - Like 4, but know that SeaBIOS doesn't use the bottom half of the first 1K of EBDA and use that. Same problems as 4.
6 - Try to detect if the code is called in VM86 mode and don't use the extra stack then - see patch below. The patch does make skifree work, but I'm uncertain if it would catch other users (eg, kvm on some intel chipsets?, some old dos program if dos is using emm386 mode).
--- a/vgasrc/vgaentry.S +++ b/vgasrc/vgaentry.S @@ -8,6 +8,7 @@ #include "asm-offsets.h" // BREGS_* #include "config.h" // CONFIG_* #include "entryfuncs.S" // ENTRY_* +#include "x86.h" // CR0_PE
/**************************************************************** @@ -109,6 +110,13 @@ entry_10: entry_10_extrastack: cli cld + + push %ax // Don't use extra stack if in protected mode + smsww %ax + test $CR0_PE, %ax + pop %ax + jne entry_10 + pushw %ds // Set %ds:%eax to space on ExtraStack pushl %eax movw %cs:ExtraStackSeg, %ds