hlide
commented
7 years ago After some thoughts about it, it seems what I'm looking for is mostly how to reroute FS and GS segments in a safe way. Having a virtual memory different from a Windows process is a goal neither desirable nor necessary.
When running the generated code with its own ABI, FS and GS will respectively point upon a 4GB guest data cache and a 4GB host basic block cache. When exiting the generated code for executing external code, FS and GS must be restored to their Windows values. And should external events like interrupts happen, FS and GS should also be restored to their Windows values. I'm not fluent enough with the hypervisor to determine whether it is possible and how to implement it efficiently with, say, SimpleVisor.
The reasons why FS and GS may be perfect for emulating guest mapping are:
1) guest architectures I plan to work with - whether they use 32-bit or 64-bit registers, use a 32-bit pointer, which means the 32 upper bits are ignored in most case. See void* good_pointer = ...; void* still_good_pointer = 0x5AF89C7C00000000 ^ good_pointer;. good_pointerand still_good_pointer will point at the same place in memory.
If I want to address this issue, I need to use an intermediate register to compute the 32-bit effective address (EA) before accessing memory: MOV RDX, [RSI + ofs_GPRbase]; ...; MOV ECX, EDX; MOVBE RAX, [RBX + RCX + imm] where RBX is the base of the guest data memory, RCX an intermediate register to hold EA, RAX the allocated register to hold the read value, RDX another allocated register to hold the guest register base for a load and RSI a persistent register to hold the guest registers context address.
Now imagine there are several pointers in the basic block, the chance to optimize registers usage are compromised.
In fact, x86-64 can deal with 32-bit EA itself by using prefix 0x67. You can issue the same sequence without the need of intermediate register: MOV RDX, [RSI + ofs_GPRbase]; ...; MOVBE RAX, FS:[EDX + imm] where we replace RBXwith FS for the base of the guest data memory. The computation of EA directly takes EDX as a base and do a 32-bit zero extension at the end. That sounds exactly how the guest processor would do : ignore the 32 upper bits. And RDX can still contain random upper bits without any consequence when using it as a base/index for load and store operations.
2) the same situation may happen for the host basic block cache. To chain basic blocks in the case of a guest indirect jump instruction: MOV RDX, [RSI + ofs_GPRtarget]; ...; MOV EBP, EDX; JMP [RDI + RBP] where RDI is the base of the host basic block cache, RDX an allocated register to hold the guest register target for an indirect jump, RBP a special register to contain the target jump register and RSI a persistent register to hold the guest registers context address. RBP is also used by the recompiler code when a basic block must be generated so it may know the guest address to recompile.
If we map that cache into GS segment, we obtain: MOV RDX, [RSI + ofs_GPRtarget]; ...; MOV EBP,EDX; JMP GS:DWORD PTR[EBP] where we replace RDI with GS. We need to keep EBP so recompiler function can still get the guest address to recompile from it. If the target GPR is only used for an indirect jump in the basic block, a simpler version is done: MOV EBP, [RSI + ofs_GPRtarget]; JMP GS:DWORD PTR[EBP].
Now some questions:
1) If an external event occurs, could SimpleVisor catch it and assure FS and GS are set properly so the event can be handled by Windows properly?
2) What is the best solution to alter FS and GS in a safe way where FS and GS point on the huge memory blocks only when executing generated code?
3) Can SimpleVisor handle several virtual CPUs? Suppose we have 8 guest processors, do we need to make 8 virtual CPUs?
4) When using a win32 thread to create a guest thread (remember emulator only emulate the user-land guest code), is there a chance for all the guest threads to run in parallel according to the number of true logical processors of the Intel processor?
Best regards.
ionescu007
buraktamturk
rianquinn
I see no other way for discussing how it may be possible for SimpleVisor to run dynamic recompiled code emulating non-x86-64 code.
I have written an emulator which runs some PSP programs (based on a customized MIPS32 ISA) and I would like to extend some of my realizations to other guest ISAs.
The emulator is using an HLE (High Level Emulation) principle: dynamically recompiling a user-land guest code into a native host code; kernel and hardware relative guest code are directly compiled from native host source so there is no need to emulate any functionality or hardware at lower level. Basically, a syscall will call a native host function instead of trying to emulate guest instructions step by step inside the syscall.
The dynamic compiler emits x86-64 instructions and uses its own ABI if I can say this way: up to 12 GPR registers are available for the integer register allocator. By not trying to comply with the usual Windows 64-bit ABI, I can allow faster emulation. The key is the chains of basic blocks is totally built by the dynarec so the usual ABI is not needed to be saved and restored between host basic blocks (only when calling a syscall). Some details can be found here and there.
I have different fields I would like to address with a hypervisor like yours and check if it is possible:
1) To execute the chains of the generated code inside a dedicated logical processor. A call to a guest syscall will exit to native Windows code to execute a functionality or recompile a new guest code. Idealistically I want that generated code being inside the first virtual 4GB address range to keep the ICache array with 32-bit function pointers as entries since most ISAs I want to emulate have 32-bit pointers. I sometimes wonder if this logical processor may need its own memory mapping or not. Is that possible with SimpleVisor or would it be better to keep the same memory mapping as the running Windows program?
2) To get a perfect memory emulation which mimics the guest memory mapping. I used some Windows specific tricks to be able to have a very fast memory access. While it may be enough for emulating PSP , it may not for other architectures. Another possibility I can see is to use fs segment when running generated code in its logical processor (no sure if gs can also be used for another purpose as long as logical processor doesn't exit, or can it ?). This way, fs segment may map the whole 4GB of the guest memory (also called dcache), and a simple MOV or MOVBE can be done with a FS prefix to access this guest memory. If gs can also be used, it could also map the huge icache (for each guest address, it maps a potential recompiled basic block to jump into, or to recompiler code to create a new basic block) and would allow very fast execution of chains of host basic blocks.
For those two points, do you think SimpleVisor may help?
Best regards.