class ProtectedRangesControl
Defined at line 360 of file ../../src/sysmem/server/protected_ranges.h
This is the virtual interface that (outside of tests) is a thin wrapper on top of
fuchsia.sysmem.SecureMem (ProtectedRangesCoreControl) and Zircon contiguous VMO + page loaning +
page reclaim (additional methods added by ProtectedRangesControl). The only method of this
interface that's allowed to fail is UseRange() since that can be expected to fail from Zircon
under severe-enough memory pressure. All other failures are treated as ZX_PANIC()-level fatal,
which will result in a hard reboot. Since any process including the sysmem driver can fail at
any time due to system-wide memory overcommit, this ZX_PANIC() isn't any worse than that, and
is only expected under similar circumstances. The thinking is that failing bigger is actually
better from the user's point of view once we've gotten to the point where something is using so
much memory that small allocations and faulting in a page start failing; a reboot is overall
better than getting stuck in that state.
TODO(https://fxbug.dev/42178137): When possible, configure sysmem to trigger reboot on driver
remove.
Public Methods
uint64_t GetBase ()Lowest begin() possible for any requested range.
uint64_t GetSize ()GetBase() + GetSize() is the highest end() posisble for any requested range.
bool UseRange (const Range & range)UseRange
This is called shortly before an offset becomes part of any range, and will not be called on a
given offset more than once without any intervening un_use_range that covers the same offset.
This information can be inferred by watching add_range and mod_range (including tracking of
temporarily overlapping ranges), but it's simpler overall to implement UseRange() and let
ProtectedRanges inform of all ranges that are changing from outside all ranges to inside at
least one range.
This is allowed to fail by returning false. This is so that Zircon can refuse to reclaim pages
if memory pressure is too severe. If this happens, the range is still considered un-used, and
will not be added.
void UnUseRange (const Range & range)UnUseRange
This can't fail. If the system is too broken to UnUseRange(), then ZX_PANIC() instead. A hard
reboot will result.
TODO(https://fxbug.dev/42178137): When possible, configure sysmem to trigger reboot on driver
remove.
This is called shortly after an offset stops being part of any protected range, and will not be
called on a given offset more than once without any intervening use_range that covers the same
offset.
This information can be inferred by watching del_range and mod_range (including tracking of
temporarily overlapping ranges), but it's simpler overall to implement UnUseRange() and let
ProtectedRanges inform of all ranges that are changing from inside at least one range to
outside all ranges.