Support stand-alone memory mappings

[raphaelning]

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.

[acrnsi]

Can one of the admins verify this patch?

[krytarowski]

Is this going to help to #171 ?

[raphaelning]

Is this going to help to #171 ?

Sorry, no. This is to fix an issue specific to Android Emulator.