template <typename BuilderImpl>class WireTableBaseBuilder
Defined at line 621 of file fidling/gen/sdk/fidl/fuchsia.sysmem/fuchsia.sysmem/cpp/fidl/fuchsia.sysmem/cpp/wire_types.h
Public Methods
::fuchsia_sysmem::wire::SecureHeapProperties Build ()Build and return the table. The builder should not be used after this.
bool has_heap ()void clear_heap ()Clears the heap field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
::fuchsia_sysmem::wire::HeapType & heap ()The HeapType is repeated here for convenience.
BuilderImpl & heap (Wrapper_Ignore_Me_< ::fidl::ObjectView< ::fuchsia_sysmem::wire::HeapType>> elem)The HeapType is repeated here for convenience.
bool has_dynamic_protection_ranges ()void clear_dynamic_protection_ranges ()Clears the dynamic_protection_ranges field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
bool & dynamic_protection_ranges ()If true, more than one call to SetPhysicalSecureHeap() for the same
heap is allowed. If false, only one SetPhyscialSecureHeap() call is
allowed, and no calls to DeleteSecureHeapPhysicalRange() or
ModifySecureHeapPhysicalRange() are allowed. Even when this is false,
the SecureMem server (driver) is still responsible for de-protecting
just before warm reboot if protected ranges would not otherwise be
cleaned up during a warm reboot.
BuilderImpl & dynamic_protection_ranges (bool elem)If true, more than one call to SetPhysicalSecureHeap() for the same
heap is allowed. If false, only one SetPhyscialSecureHeap() call is
allowed, and no calls to DeleteSecureHeapPhysicalRange() or
ModifySecureHeapPhysicalRange() are allowed. Even when this is false,
the SecureMem server (driver) is still responsible for de-protecting
just before warm reboot if protected ranges would not otherwise be
cleaned up during a warm reboot.
bool has_protected_range_granularity ()void clear_protected_range_granularity ()Clears the protected_range_granularity field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
uint32_t & protected_range_granularity ()The granularity of protection ranges. If the granularity of start is
different than granularity of end or length, then this is the max
granularity value among those values.
This must be a power of 2. The client must not request ranges that
specify smaller granularity.
This must be at least zx_system_page_size() even if the HW can do
smaller granularity.
BuilderImpl & protected_range_granularity (uint32_t elem)The granularity of protection ranges. If the granularity of start is
different than granularity of end or length, then this is the max
granularity value among those values.
This must be a power of 2. The client must not request ranges that
specify smaller granularity.
This must be at least zx_system_page_size() even if the HW can do
smaller granularity.
bool has_max_protected_range_count ()void clear_max_protected_range_count ()Clears the max_protected_range_count field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
uint64_t & max_protected_range_count ()The SecureMem server should not count reserved ranges that the SecureMem
server uses internally to get from range set A to range set B, if the
SecureMem server needs to do any emulation of that sort. Normally such
emulation by the SecureMem server is unnecessary. If any ranges are
reserved by the SecureMem server, those reserved ranges are not
available for use by the SecureMem client.
If the number of ranges is limited only by available memory, it's ok for
the SecureMem server to report 0xFFFFFFFFFFFFFFFF for this value. The
field must still be set. As usual, the SecureMem server should ensure
that SetPhysicalSecureHeapRanges() succeeds or fails atomically (either
fully updates or rolls back before completing).
BuilderImpl & max_protected_range_count (Wrapper_Ignore_Me_< ::fidl::ObjectView<uint64_t>> elem)The SecureMem server should not count reserved ranges that the SecureMem
server uses internally to get from range set A to range set B, if the
SecureMem server needs to do any emulation of that sort. Normally such
emulation by the SecureMem server is unnecessary. If any ranges are
reserved by the SecureMem server, those reserved ranges are not
available for use by the SecureMem client.
If the number of ranges is limited only by available memory, it's ok for
the SecureMem server to report 0xFFFFFFFFFFFFFFFF for this value. The
field must still be set. As usual, the SecureMem server should ensure
that SetPhysicalSecureHeapRanges() succeeds or fails atomically (either
fully updates or rolls back before completing).
bool has_is_mod_protected_range_available ()void clear_is_mod_protected_range_available ()Clears the is_mod_protected_range_available field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
bool & is_mod_protected_range_available ()Iff true, ModifySecureHeapPhysicalRange() is implemented. Calling
ModifySecureHeapPhysicalRange() when is_mod_protected_range_available
is false is prohibited. Don't attempt to detect availability of
ModifySecureHeapPhysicalRange() by calling it to see if it fails; it
may ZX_PANIC().
BuilderImpl & is_mod_protected_range_available (bool elem)Iff true, ModifySecureHeapPhysicalRange() is implemented. Calling
ModifySecureHeapPhysicalRange() when is_mod_protected_range_available
is false is prohibited. Don't attempt to detect availability of
ModifySecureHeapPhysicalRange() by calling it to see if it fails; it
may ZX_PANIC().
Protected Methods
void WireTableBaseBuilder< ::fuchsia_sysmem::wire::SecureHeapProperties, BuilderImpl> (::fidl::ObjectView< ::fidl::WireTableFrame< ::fuchsia_sysmem::wire::SecureHeapProperties>> && frame)