Quitting an Intel x86 Hypervisor
halobates.de
Quitting an Intel x86 Hypervisor
1–10 of 21 posts
Re: Quitting an Intel x86 Hypervisor
#2Re: Quitting an Intel x86 Hypervisor
#3This reminds me of DOS-based Windows which would need to get out of the V86 mode that EMM386 used before going into protected mode itself; a task which was done using the undocumented (at the time) GEMMIS interface.
Re: Quitting an Intel x86 Hypervisor
#4This reminds me of DOS-based Windows which would need to get out of the V86 mode that EMM386 used before going into protected mode itself; a task which was done using the undocumented (at the time) GEMMIS interface.
Similarly, Novell NetWare, which was its own OS with its own filesystem, used DOS as a preboot environment and allowed you to exit to DOS.
Re: Quitting an Intel x86 Hypervisor
#5Awful.
Fortunately, we won't have to suffer x86 much longer.
Re: Quitting an Intel x86 Hypervisor
#6Fun stuff. Reminds me of writing code to restore a state snapshot for a sound module with its own processor. It had four byte-wide shared I/O registers in a row. After restoring almost all memory, I put a two-byte infinite-loop branch instruction in the last two bytes and had the sound CPU jump to it, loaded a 1- or 2- byte instruction in the first two bytes, then modified the branch offset to execute this instruction as part of the loop, let it run a few times, then modified the offset to just be a single-instruction loop. I did this multiple times to execute each instruction needed to finish loading memory, restore all registers, and finally jump to the execution address with everything restored.
Re: Quitting an Intel x86 Hypervisor
#7This reminds me of DOS-based Windows which would need to get out of the V86 mode that EMM386 used before going into protected mode itself; a task which was done using the undocumented (at the time) GEMMIS interface.
The reason for the undocumented interface is not because Windows needs to go into protected mode itself (which would be a simple operation that later on came to be available through the more documented DPMI-alikes) , but rather because Windows wants to _replace_ EMM386 itself and "therefore" (usual troll MS logic of the era) needs access to its internals.
Re: Quitting an Intel x86 Hypervisor
#8Awful. Fortunately, we won't have to suffer x86 much longer.
Be carefull for what you wish for.
The design is basically an overextension of the 8008 processer, which assumed 64k of memory and manually programmed in assembly. We've expanded that design for 40 years, and the whole software design philosophy below it has changed. Every design will suffer in these conditions.
Meanwhile, almost all info about it is in the open. Culture has closed a lot, even including stuff like RISC V.
Re: Quitting an Intel x86 Hypervisor
#9Awful. Fortunately, we won't have to suffer x86 much longer.
there isn't much out there which is well known and completely open source other than risc-v. mayb urbit
Re: Quitting an Intel x86 Hypervisor
#10This reminds me of DOS-based Windows which would need to get out of the V86 mode that EMM386 used before going into protected mode itself; a task which was done using the undocumented (at the time) GEMMIS interface.
The reason for the undocumented interface is not because Windows needs to go into protected mode itself (which would be a simple operation that later on came to be available through the more documented DPMI-alikes) , but rather because Windows wants to _replace_ EMM386 itself and "therefore" (usual troll MS logic of the era) needs access to its internals.
I mean, enhanced windows wants to be running in protected mode with its kernel in ring 0. If you're running DOS in real mode, no problem, windows will switch.
But, if you've loaded Emm386, it already has the machine in protected mode with its kernel in ring 0.
GEMMIS allows switching out the kernel, and later switching back.