Hi,
I'm okay with the cut-and-paste. But, another option would be to use the iretw at the end of the existing irqentry_extrastack to implement the ljmpw into the main vgabios. Something like (totally untested):
entry_10_hooked: pushfw // Setup for iretw in irqentry_arg pushl %cs:sercon_int10_hook_resume
pushl $handle_10#if CONFIG_ENTRY_EXTRASTACK jmp irqentry_arg_extrastack #else jmp irqentry_arg #endif
Good idea, I'll try it.
Separately, have you considered choosing a separate entry point for entry_10_hooked. That is, changing the above pushl to $handle_sercon_hooked and introducing that function in sercon.c. It seems it would reduce a number of "if (!sercon_splitmode())" checks in the main code, as handle_sercon_hooked() could just use a smaller switch statement and ignore requests it doesn't need to support.
Makes sense indeed. All functions which only return information are not needed in the splitmode case.
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.
/me places the item on the todo list.
Also a serial console for windows guests isn't that useful, so I wouldn't worry too much about windows emulator issues.
cheers, Gerd