Resource: LCA14 Name: LCA14-509: ION upstreaming status & next steps Date: 07-03-2014 Speaker: John Stultz and Sumit Semwal Video: https://www.youtube.com/watch?v=3ds_UJqX7mM Website: http://www.linaro.org/ Linaro Connect: http://connect.linaro.org/ Slide: https://www.slideshare.net/linaroorg/lca14-509-ionupstreamingstatusnextsteps

1. John Stultz and Sumit Semwal, LCA14-509, Macau
ION: Next Steps

2. Background: What is ION
• Constraint aware* memory allocator
• Different devices have different constraints on
what memory they can access
• ION manages and provides a method of
allocating from different pools or types of
memory, which will then be shared with various
devices (via dma-bufs).
* “Aware” is maybe not quite accurate, but we’ll talk about that later

3. History
• Introduced into Android for ICS 3.0+ kernels
• 32bit ARM only
• Problematic DMA API usage
• Very hardware-specific interface and implementations
• Summarized these and other issues on LWN
• https://lwn.net/Articles/565469/
• Thanks to Jesse and Arnd for help identifying these
problems
• Synced with Android developers at Linux
Plumbers

4. • ION interface mostly used with graphics, which
tend to be proprietary
• No access to drivers for testing with latest
upstream kernels
• ARMv8 architecture models don’t even have gpu
hardware available.
• Upstream graphics developers not fond of ION or
Android’s approach to graphics
Difficulties

5. Since Linux Plumbers
• Colin Cross addressed most of the issues we
pointed out, via heavy refactoring of the code.
• Colin also provided unit tests, which I’ve ported to
non-android Linux environments
• Rom Lemarchand implemented compat_ioctl
support
• Developed a dummy driver to allow for testing on
systems that don’t have ION enabled graphics
• Worked with Colin to get the code tested and
stabilized.
• Pushed the entire ION patchset upstream via
staging (115+ patches).

6. Current Status
• ION builds and runs on ARM, x86_64, ARM64,
etc.
• Thanks to Jesse Barker for validating ARMv8!
• Compat ioctl support for 32bit applications
running on 64bit kernels
• Working on getting ion unit tests integrated into
lava.

7. Remaining issues
• ION still assumes phys addresses and bus
addresses are the same.
• This is ok on the hardware they care about so far.
• ION’s API requires userspace to manage the
device-constraint to memory type mapping
• Requires hardware specific gralloc userspace
• The types and subtleties of constraints is not
easily enumerable, as they may be different
device to device
• ION uses heap-ids to specify memory types, but heap-ids
are often device specific.

8. Interface examples
fd = open(“/dev/ion”, O_RDONLY);
struct ion_allocation_data data = {
.len = len,
.align = align,
.heap_id_mask = heap_mask,
.flags = flags,
};
ret = ioctl(fd, ION_IOC_ALLOC, &data);
Returns a buffer reference via: data.handle
Also:
ION_IOC_FREE: Free allocated buffer
ION_IOC_MAP: Generates an fd that can be mmaped
ION_IOC_SHARE: Generates a dma-buf fd that can be
shared
ION_IOC_IMPORT: Imports a dma-buf fd
ION_IOC_SYNC: Syncs the buffer to memory (deprecated)
ION_IOC_CUSTOM: Heap specific ioctl multiplexer (ugh)

9. • dmabuf usage model:
dma_buf_export()
...
dma_buf_get()
dma_buf_attach()
dma_buf_map_attachment()
dma_buf_unmap_attachment()
dma_buf_detach()
dma_buf_put()
• dmabuf exporter doesn’t necessarily allocate backing buffer
until map_attachment() time.
• When attaching, add device constraints to dmabuf, then
when allocating at map time, use those constraints to allocate
the right type of memory
What upstream developers want

10. • All devices have to have attached before the first
map.
• This can have permissions limitations, since process
starting things may not have permissions to access all the
devices that may eventually use the buffer
• dmabuf exporters are all driver specific
• Current dmabuf exporters don’t all use delayed (map
time) allocation.
• Android developers unlikely to move from ION
• Don’t require generic solution, ok with device specific
userland
• They like the directness of their approach
Issues with this approach

11. • Create a set of constraint aware dmabuf
allocation helper functions
• Try to share code with ION by reusing the heaps
• On dma_buf_attach(), store compatible heap
flags for that device in dma_buf
• Provide helper functions that will look at heap
flags on dmabuf and allocate memory from the
compatible ION heap
• Once we have common infrastructure, ION can
be reduced to just a shim interface that provides
the Android preferred semantics.
Plan

12. • Start looking at how to share the backing heap
allocators with the map-time post-attach
allocation that the dma-buf developers want to
see.
• Initially, we’ll do a PoC to prove ‘things work’
• Two steps: Sharing constraints, and using allocator
helpers for dma-bufs
Next steps

13. Next steps
• Sharing constraints
• add access_constraints_mask to dev->dma_parms of
importers
• values for the mask are deliberately kept ‘open’ to allow use-
case / platform-driven definition
• Then at each dma_buf_attach() call, check this mask for
attaching device and add to the global mask for the given
dma_buf
• error out if the new constraint causes the mask to become
zero => new device’s constraints won’t work with other
devices in the use case
• At each dma_buf_detach() call, re-calculate global mask for the
currently attached importers - this could help in backing storage
migration if so desired by exporter.

14. • Allocation helpers for dma-buf
• Central allocation helpers tied to dma-bufs - relevant only
when buffers are being shared around.
• Used by dma-buf exporters to provide map-time backing-
storage allocation for each dma-buf
• In the PoC, we intend to reuse the most common ION
heap functions for fixed ION constraint masks (heap
masks); later, the design would be updated to allow
adding custom allocation with function pointers and
platform-specific constraint masks
Next steps

15. • New functionality in the usage sequence:
dma_buf_get()
- importer to set constraints in dev->dma_parms-
>access_constraints_mask
dma_buf_attach()
- adds constraint to dma-buf; will return error if new
device attachment doesn’t satisfy existing constraints
dma_buf_map_attachment()
- exporter looks at constraint mask, and (optionally) uses
allocation helpers to allocate
dma_buf_unmap_attachment()
dma_buf_detach()
- re-calculates dma-buf’s constraint mask
dma_buf_put()
Next steps

16. • Dynamic handling of device specific heaps and dynamic
heap priority
• Per-platform allocation policy
• Separate from the constraint
• Allows for preferring some dimms over others, contig memory in
special regions (secure playback), etc.
• Likely per-platform and will need heap specific function pointer for
policy allocator.
• Generic userland api
• Current dma-buf exporters are via per-device/subsystem ioctls (like
drm/gem or v4l2).
• May be use for generic dma-buf exporter chardev?
• Not yet handling some of the caching optimizations ION
uses, nor performance issues connected with proper
dma-api usage w/ things like IOMMUs
Issues still to address

17. Links/Questions?
• Constraints / allocator helper PoC current code:
https://git.linaro.org/people/sumit.semwal/linux-3.x.git
• Areas of concern?
• Does the constraint and policy split make sense?
• Thoughts on enumeration theory?
• Other possible consumers other than graphics?
• Networking?
• eMMC / storage?
• other?

18. More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/
Linaro members: www.linaro.org/members