On 20 September 2017 at 18:05, John Reiser <address@hidden> 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?