On 20 September 2017 at 18:05, John Reiser <jrei...@bitwagon.com> wrote: > Yes, the SEGV occurs on the store, "long" before the re-written > instruction ever is executed
OK, I've identified the immediate cause for this SEGV. (1) when the guest initially mmap()s at 0xf7000000 and above we pass that through to the host as an mmap rwx (2) later, the guest wants to execute from some part of this region; QEMU marks those pages as non-writable so that we can catch guest writes and invalidate our translated code cache (we then mark the page writable and resume the guest code). This is a host page at a time, so it covers the memory we're trying to modify (3) when the translated guest code writes to the memory, we get a host SIGSEGV, which is expected. Unfortunately we then fail to recognize it as a case of a guest write to a page that QEMU marked non-writeable. (4) The reason we don't recognize the address is that our test for "is this valid" (h2g_valid()) checks that the guest address is within the chunk of the host address space that we've carved out for the guest, and the amount of space we carve out for that is 0xf7000000. So guest execution above that won't work properly (really we should probably fail the mmap() rather than letting it succeed but misbehave). I don't really know why we use 0xf7000000 as our reserved_va value here, though. Alex, you added that years ago, can you remember why you used that value? You can work around this by passing a different reserved-space value to QEMU with -R -- in theory 0xffff0000 would be the right answer (there's a kernel-page above that), but QEMU says it can't reserved that much space. -R 0xfffe0000 seems to get it past the immediate segv problem. thanks -- PMM
