Please sign in to comment.
Support stand-alone memory mappings
Android Emulator may dynamically create and destroy temporary memory mappings at guest runtime for certain rendering tasks via hax_user_backed_ram_map() and hax_user_backed_ram_unmap() ($AOSP/external/qemu/target/i386/hax-mem.c), e.g.: hax_user_backed_ram_map() <1> 1.1) ADD_RAMBLOCK <1>: HVA 0x14e070000..0x16e070000 1.2) SET_RAM2 (map) <1>: GPA 0x7dffff000..0x7fffff000 => HVA 0x14e070000..0x16e070000 hax_user_backed_ram_unmap() <1> 1.3) SET_RAM2 (unmap) <1>: GPA 0x7dffff000..0x7fffff000 hax_user_backed_ram_map() <2> 2.1) ADD_RAMBLOCK <2>: HVA 0x14de70000..0x16de70000 The second ADD_RAMBLOCK call fails, because its HVA range overlaps with that of the first ADD_RAMBLOCK call. The problem is that the "map" step creates a RAM block, but the "unmap" step doesn't destroy it. Instead of adding a DEL_RAMBLOCK ioctl, simply exempt the caller from calling ADD_RAMBLOCK in the first place: - Introduce a new hax_memslot flag for "stand-alone" mappings, along with a new capability flag for this API change. - Remove the ADD_RAMBLOCK call from hax_user_backed_ram_map(). Instead, call SET_RAM2 with the new flag. (This will be done on the Android Emulator side.) - Internally, SET_RAM2 creates a stand-alone RAM block for each stand-alone mapping. - When the stand-alone mapping is unmapped, the reference count of the corresponding stand-alone RAM block will hit 0, which allows SET_RAM2 to destroy this temporary RAM block. + Replace HAX_RAM_INFO_xxx with HAX_MEMSLOT_xxx in code that is not directly in touch with user space. Signed-off-by: Yu Ning <email@example.com>
- Loading branch information...
Showing with 78 additions and 26 deletions.