Another quickie... After playing around with different ways to pass info between the user and monitor spaces, I finally settled on a more simple one for now. The two spaces can pass IO and memory information, interrupts, contexts, etc. I ripped kernel/emulation.c up, and started rebuilding it. Emulation of instructions is now done in a microcode fashion. This is ultimately a more compact way to emulate instructions, and is state oriented, so execution of an instruction can resume at any point. Being state oriented is necessary to handle several odd cases I mentioned before. I believe the new architecture can ultimately handle any of them now. OK, now that I have a base to work with, let me crunch on a new emulation.c for several days and then generate a tarball so you can see what I'm up to. BTW, I'm coding with host-pageable guest physical memory in mind. I start with no guest phy mem mapped to the memory we allocate in the kernel driver, and map it to that memory on-demand. This way, we can never assume a guest phy page is mapped in (same as for a page marked as host-pageable). Also, the guest code serves IO request, interrupts, etc, but does not play a role in emulation of instructions now. Before it would fill in register values (like eax) as part of emulation of IO instructions. This is not necessary in the new code. -Kevin
