|
From: Roland M. <ro...@re...> - 2004-12-04 02:46:39
|
> That could be tricky. It's generally pretty hard to do that kind switch > between real and virtual CPU, because the virtual CPU has a lot more > state than the real one. I don't think that matters, though I'm also not quite sure what it means. You don't have to handle "going real" in a general way. There are only a tiny number of ways a guest kernel can go into user mode, and in practice there is only one that you'll need to handle. It will be a block that pops every register off the stack and ends with an `iret' instruction. Incidentally, inside that block will be the only place you encounter an instruction in a xen/x86 guest kernel that sets a segment register. You just have to identify a block that does this, and translate it into a special thing that escapes valgrindland into the implementation glue code and provides it all the register values the translated block wanted to load. Those values are going into a black box, just as if they were copied into a buffer passed to a `write' system call in the userland valgrind's perspective. You check whether they are uninitialized data. But after that, you don't care what they are or whether they are going to be segment register values or whatever, because it's not happening in your world. The black box comes back at some point through some glue code that reenters valgrindland telling you that the virtual CPU's kernel-mode eip and esp have these here values and the other registers have just been filled in with random bits from the black box (again, as if loaded from the buffer filled by a `read' system call from the other side of the looking glass). Thanks, Roland |