class BufferMemoryConstraints
Defined at line 1991 of file fidling/gen/sdk/fidl/fuchsia.sysmem2/fuchsia.sysmem2/cpp/fidl/fuchsia.sysmem2/cpp/natural_types.h
Public Methods
void BufferMemoryConstraints (Storage_ storage)void BufferMemoryConstraints ()Defined at line 1996 of file fidling/gen/sdk/fidl/fuchsia.sysmem2/fuchsia.sysmem2/cpp/fidl/fuchsia.sysmem2/cpp/natural_types.h
void BufferMemoryConstraints (BufferMemoryConstraints && )Defined at line 1997 of file fidling/gen/sdk/fidl/fuchsia.sysmem2/fuchsia.sysmem2/cpp/fidl/fuchsia.sysmem2/cpp/natural_types.h
void BufferMemoryConstraints (const BufferMemoryConstraints & other)BufferMemoryConstraints & operator= (BufferMemoryConstraints && )Defined at line 1998 of file fidling/gen/sdk/fidl/fuchsia.sysmem2/fuchsia.sysmem2/cpp/fidl/fuchsia.sysmem2/cpp/natural_types.h
BufferMemoryConstraints & operator= (const BufferMemoryConstraints & other)bool operator== (const BufferMemoryConstraints & other)bool operator!= (const BufferMemoryConstraints & other)bool IsEmpty ()const std::optional<uint64_t> & min_size_bytes ()un-set is treated as 1
::std::optional<uint64_t> & min_size_bytes ()un-set is treated as 1
BufferMemoryConstraints & min_size_bytes (std::optional<uint64_t> value)un-set is treated as 1
const std::optional<uint64_t> & max_size_bytes ()un-set is treated as 0xFFFFFFFFFFFFFFFF.
::std::optional<uint64_t> & max_size_bytes ()un-set is treated as 0xFFFFFFFFFFFFFFFF.
BufferMemoryConstraints & max_size_bytes (std::optional<uint64_t> value)un-set is treated as 0xFFFFFFFFFFFFFFFF.
const std::optional<bool> & physically_contiguous_required ()When false, physical pages of a buffer VMO can be non-contiguous. When
true, physical pages of a buffer VMO must be sequentially contiguous. A
client that doesn't require physically contiguous VMOs must still accept
physically contiguous VMOs or "physical" VMOs.
::std::optional<bool> & physically_contiguous_required ()When false, physical pages of a buffer VMO can be non-contiguous. When
true, physical pages of a buffer VMO must be sequentially contiguous. A
client that doesn't require physically contiguous VMOs must still accept
physically contiguous VMOs or "physical" VMOs.
BufferMemoryConstraints & physically_contiguous_required (std::optional<bool> value)When false, physical pages of a buffer VMO can be non-contiguous. When
true, physical pages of a buffer VMO must be sequentially contiguous. A
client that doesn't require physically contiguous VMOs must still accept
physically contiguous VMOs or "physical" VMOs.
const std::optional<bool> & secure_required ()If true, the participant requires secure memory.
When aggregating `BufferCollectionConstraints`, these values boolean-OR.
::std::optional<bool> & secure_required ()If true, the participant requires secure memory.
When aggregating `BufferCollectionConstraints`, these values boolean-OR.
BufferMemoryConstraints & secure_required (std::optional<bool> value)If true, the participant requires secure memory.
When aggregating `BufferCollectionConstraints`, these values boolean-OR.
const std::optional<bool> & cpu_domain_supported ()When true (or when `BufferMemoryConstraints` is not present), the
participant is ok with sysmem selecting the CPU domain.
If the CPU domain is selected, participants must ensure the CPU can read
or write data to the buffer without cache operations outside of the
participant.
In other words, if a producer participant DMAs data directly to RAM on a
non-cache-coherent architecture such as arm, the producer must ensure
the CPU cache is clean wrt. the buffer before the DMA write, and
invalidate the CPU cache after the DMA write and before indicating that
the buffer is ready to any other participant. If a consumer participant
DMAs data directly from RAM on a non-cache-coherent architecture such as
arm, the consumer must flush the CPU cache wrt the buffer before the DMA
read.
CPU-only participants that don't do any DMA can just write and read the
buffers (when they should) without needing to do any CPU cache ops.
::std::optional<bool> & cpu_domain_supported ()When true (or when `BufferMemoryConstraints` is not present), the
participant is ok with sysmem selecting the CPU domain.
If the CPU domain is selected, participants must ensure the CPU can read
or write data to the buffer without cache operations outside of the
participant.
In other words, if a producer participant DMAs data directly to RAM on a
non-cache-coherent architecture such as arm, the producer must ensure
the CPU cache is clean wrt. the buffer before the DMA write, and
invalidate the CPU cache after the DMA write and before indicating that
the buffer is ready to any other participant. If a consumer participant
DMAs data directly from RAM on a non-cache-coherent architecture such as
arm, the consumer must flush the CPU cache wrt the buffer before the DMA
read.
CPU-only participants that don't do any DMA can just write and read the
buffers (when they should) without needing to do any CPU cache ops.
BufferMemoryConstraints & cpu_domain_supported (std::optional<bool> value)When true (or when `BufferMemoryConstraints` is not present), the
participant is ok with sysmem selecting the CPU domain.
If the CPU domain is selected, participants must ensure the CPU can read
or write data to the buffer without cache operations outside of the
participant.
In other words, if a producer participant DMAs data directly to RAM on a
non-cache-coherent architecture such as arm, the producer must ensure
the CPU cache is clean wrt. the buffer before the DMA write, and
invalidate the CPU cache after the DMA write and before indicating that
the buffer is ready to any other participant. If a consumer participant
DMAs data directly from RAM on a non-cache-coherent architecture such as
arm, the consumer must flush the CPU cache wrt the buffer before the DMA
read.
CPU-only participants that don't do any DMA can just write and read the
buffers (when they should) without needing to do any CPU cache ops.
const std::optional<bool> & ram_domain_supported ()When true, the participant is ok with sysmem selecting the RAM domain.
If the RAM domain is selected, producer data must be available in RAM
(with CPU cache state such that the RAM data won't get corrupted by a
dirty CPU cache line writing incorrect data to RAM), and a consumer
reading using the CPU must invalidate CPU cache before reading (the
producer doesn't guarantee zero stale "clean" cache lines).
In other words, if a producer participant uses the CPU to write data on
a non-cache-coherent architecture such as arm, the producer must flush
the data to RAM before indicating to another participant that the buffer
is ready. If a consumer participant uses the CPU to read data on a
non-cache-coherent architecture such as arm, the participant must
invalidate (typically flush+invalidate with knowledge that no cache
lines are dirty) the CPU cache before reading the buffer.
RAM-only participants that don't do any CPU accesses to a buffer can
just do DMA to/from the buffers (when they should) without needing to
do any CPU cache ops.
::std::optional<bool> & ram_domain_supported ()When true, the participant is ok with sysmem selecting the RAM domain.
If the RAM domain is selected, producer data must be available in RAM
(with CPU cache state such that the RAM data won't get corrupted by a
dirty CPU cache line writing incorrect data to RAM), and a consumer
reading using the CPU must invalidate CPU cache before reading (the
producer doesn't guarantee zero stale "clean" cache lines).
In other words, if a producer participant uses the CPU to write data on
a non-cache-coherent architecture such as arm, the producer must flush
the data to RAM before indicating to another participant that the buffer
is ready. If a consumer participant uses the CPU to read data on a
non-cache-coherent architecture such as arm, the participant must
invalidate (typically flush+invalidate with knowledge that no cache
lines are dirty) the CPU cache before reading the buffer.
RAM-only participants that don't do any CPU accesses to a buffer can
just do DMA to/from the buffers (when they should) without needing to
do any CPU cache ops.
BufferMemoryConstraints & ram_domain_supported (std::optional<bool> value)When true, the participant is ok with sysmem selecting the RAM domain.
If the RAM domain is selected, producer data must be available in RAM
(with CPU cache state such that the RAM data won't get corrupted by a
dirty CPU cache line writing incorrect data to RAM), and a consumer
reading using the CPU must invalidate CPU cache before reading (the
producer doesn't guarantee zero stale "clean" cache lines).
In other words, if a producer participant uses the CPU to write data on
a non-cache-coherent architecture such as arm, the producer must flush
the data to RAM before indicating to another participant that the buffer
is ready. If a consumer participant uses the CPU to read data on a
non-cache-coherent architecture such as arm, the participant must
invalidate (typically flush+invalidate with knowledge that no cache
lines are dirty) the CPU cache before reading the buffer.
RAM-only participants that don't do any CPU accesses to a buffer can
just do DMA to/from the buffers (when they should) without needing to
do any CPU cache ops.
const std::optional<bool> & inaccessible_domain_supported ()When true, the participant is ok with sysmem selecting the INACCESSIBLE
domain.
If the INACCESSIBLE domain is selected, CPU reads and writes of the data
are prevented. Attempts to read/write the data with the CPU may result
in UB and/or process termination.
If the INACCESSIBLE domain is selected, participants must only operate
on the data using DMAs performed by HW, or platform-specific DMA-like
requests to a secure environment (which will do the needed CPU cache ops
similar to how a RAM domain participant would operate).
Secure heaps only support INACCESSIBLE domain, and will fail allocation
if any participant with `BufferUsage` other than `NONE_USAGE` does not
set inaccessible_domain_supported to true.
When the INACCESSIBLE domain is selected, participants (outside of
secure/DRM environments) should not attempt to map buffers, and should
not attempt to perform any CPU cache ops. In this respect, this domain
is similar to RAM domain with all participants only doing DMA and no
participant(s) doing CPU accesses.
::std::optional<bool> & inaccessible_domain_supported ()When true, the participant is ok with sysmem selecting the INACCESSIBLE
domain.
If the INACCESSIBLE domain is selected, CPU reads and writes of the data
are prevented. Attempts to read/write the data with the CPU may result
in UB and/or process termination.
If the INACCESSIBLE domain is selected, participants must only operate
on the data using DMAs performed by HW, or platform-specific DMA-like
requests to a secure environment (which will do the needed CPU cache ops
similar to how a RAM domain participant would operate).
Secure heaps only support INACCESSIBLE domain, and will fail allocation
if any participant with `BufferUsage` other than `NONE_USAGE` does not
set inaccessible_domain_supported to true.
When the INACCESSIBLE domain is selected, participants (outside of
secure/DRM environments) should not attempt to map buffers, and should
not attempt to perform any CPU cache ops. In this respect, this domain
is similar to RAM domain with all participants only doing DMA and no
participant(s) doing CPU accesses.
BufferMemoryConstraints & inaccessible_domain_supported (std::optional<bool> value)When true, the participant is ok with sysmem selecting the INACCESSIBLE
domain.
If the INACCESSIBLE domain is selected, CPU reads and writes of the data
are prevented. Attempts to read/write the data with the CPU may result
in UB and/or process termination.
If the INACCESSIBLE domain is selected, participants must only operate
on the data using DMAs performed by HW, or platform-specific DMA-like
requests to a secure environment (which will do the needed CPU cache ops
similar to how a RAM domain participant would operate).
Secure heaps only support INACCESSIBLE domain, and will fail allocation
if any participant with `BufferUsage` other than `NONE_USAGE` does not
set inaccessible_domain_supported to true.
When the INACCESSIBLE domain is selected, participants (outside of
secure/DRM environments) should not attempt to map buffers, and should
not attempt to perform any CPU cache ops. In this respect, this domain
is similar to RAM domain with all participants only doing DMA and no
participant(s) doing CPU accesses.
const std::optional< ::std::vector< ::fuchsia_sysmem2::Heap>> & permitted_heaps ()Which heaps are acceptable to the participant. Participants that don't
care which heap memory is allocated on should leave this field un-set. A
secure heap is only selected if all participants explicitly indicate
that the secure heap is acceptable via `heap_permitted`, or specify
`NONE_USAGE`.
::std::optional< ::std::vector< ::fuchsia_sysmem2::Heap>> & permitted_heaps ()Which heaps are acceptable to the participant. Participants that don't
care which heap memory is allocated on should leave this field un-set. A
secure heap is only selected if all participants explicitly indicate
that the secure heap is acceptable via `heap_permitted`, or specify
`NONE_USAGE`.
BufferMemoryConstraints & permitted_heaps (std::optional< ::std::vector< ::fuchsia_sysmem2::Heap>> value)Which heaps are acceptable to the participant. Participants that don't
care which heap memory is allocated on should leave this field un-set. A
secure heap is only selected if all participants explicitly indicate
that the secure heap is acceptable via `heap_permitted`, or specify
`NONE_USAGE`.
void BufferMemoryConstraints (::fidl::internal::DefaultConstructPossiblyInvalidObjectTag )Friends
class MemberVisitorclass NaturalTableCodingTraits