Every store would always cause the tb_invalidate_phys_page_fast path to be invoked,
amounting to a 40x slowdown of stores compared to loads.
Change this code to only worry about TB invalidation for regions marked as
executable (i.e. emulated executable).
Even without uc_set_native_thunks, this change fixes most of the performance
issues seen with thunking to native calls.
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
Uses Copy on Write to make it posible to restore the memory state after a snapshot
was made. To restore all MemoryRegions created after the snapshot are removed.
1. Add cmake support in CMakeLists.txt according to https://developer.android.com/ndk/guides/other_build_systems
2. Resolve symbols errors
3. Backport fixes from 438ed42311
> QEMU relies on two optimization for ppc64 and arm:
>
> 1. if(0) /* optimized code */
> 2. assert(0); /* optimized code */
>
> But the assert on mingw32 doesn't have noreturn attribute which prevents
> the second optimization and some code is reverted to the original code
> to fit in the first optimization.
>
> The assert implementation is copied from glib as qemu did.
Unfortunately, NDK also doesn't have an assert implementation qemu prefers.
This commit fixes the following issues:
- Any unmapped/free'd memory regions (MemoryRegion instances) are not
removed from the object property linked list of its owner (which is
always qdev_get_machine(uc)). This issue makes adding new memory
mapping by calling mem_map() or mem_map_ptr() slower as more and more
memory pages are mapped and unmapped - yes, even if those memory pages
are unmapped, they still impact the speed of future memory page
mappings due to this issue.
- FlatView is not reconstructed after a memory region is freed during
unmapping, which leads to a use-after-free the next time a new memory
region is mapped in address_space_update_topology().
ARM and probably the rest of the arches have significant memory leaks as
they have no release interface.
Additionally, DrMemory does not have 64-bit support and thus I can't
test the 64-bit version under Windows. Under Linux valgrind supports
both 32-bit and 64-bit but there are different macros and code for Linux
and Windows.
mio