(I tried decommitting the vmo with mx_vmo_op_range() hoping it would fault on access, but I guess since the vmar knows which vmo is mapped into it, it just recommits the vmo again, so that doesn't help.)


Here's my current plan for the 4 main functions of base/allocator/partition_allocator/page_allocator.h. It seems a bit icky implementation-wise, so please let me know if I'm horribly confused on the use of these APIs.


AllocPages(address, length, align, page_accessibility):
- vmo_create() and vmar_map() both of size length, mapping SPECIFIC at hinted |address|
- save the vmo with into a side-data structure keyed by address and length
- if page_accessibility == PageInaccessible, SetSystemPagesInaccessible() on the whole range

FreePages(address, length):
- unmap the whole range (we know it corresponds to a previous AllocPages call)
- close the vmo handle we know is unused as a result
- remove vmo mapping entry from side-data

SetSystemPagesInaccessible(address, length):
- vmar_unmap() out the range

SetSystemPagesAccessible(address, length):
- find the vmo where this range would fall into in the side-data
- vmar_map the part of the vmo back into the vmar, using SPECIFIC to control the subchunk that was presumably previously unmap()d by SetSystemPagesInaccessible().


The side-data being maintained is a list of <vmo handle, base address, length>, which is necessary to go from the address being marked accessible, or being decommitted, or being committed, back to the vmo object. This is obviously a bit awkward as compared with POSIX or Windows, which let you use the address directly.


For the others:
- DecommitSystemPages() and RecommitSystemPages(): look up the vmo in side-data and vmo_op_range() on them
- DisardSystemPages(): ignore


Super-hacky code doing this if that was all totally unclear: https://chromium-review.googlesource.com/590958 

This approach also only works because PartitionAlloc is (I think? Maybe?) fairly nicely-behaved, in that it doesn't try to mark accessible things that are already accessible, or mark vmo-spanning chunks accessible, and so on. If it did that, I think I'd have to have a lot more bookkeeping on the side. This worries me for implementing V8's more general class, https://cs.chromium.org/chromium/src/v8/src/base/platform/platform-fuchsia.cc?type=cs&q=v8+fuchsia+virtualmemory&sq=package:chromium&l=38. as I'm less confident that it won't e.g. guard/unguard overlapping or intersecting blocks of memory.

I guess my instinct would be to implement PROT_NONE (which I guess Fuchsia would call MX_VM_FLAG_PERM_NONE?). I think guard pages are in large part what it's for. And Partition Alloc might not be the only caller that will want to have guard pages, going forward. But I don't understand everything yet, so maybe I'm wrong.

The VMAR/VMO distinction is attempting to separate address space allocation (VMARs) from memory allocation (VMOs).  So far, the typical way of implementing guard pages has been to create an over-sized VMAR to reserve address space, and then leave the parts of the VMAR you want to act as guards unmapped.

The behavior that we didn't anticipate being desirable was being able to transition regions back-and-forth to being reserved-and-unmapped.  I think a PROT_NONE analog is a reasonable way to meet this use case, since it is desirable for us to 1) reduce the amount of error-prone bookkeeping that API consumers need to write, and 2) minimize the memory overhead of bookkeeping in the kernel.

MG-426 tracks the PROT_NONE feature on the Magenta side