LWN: Comments on "The Android ION memory allocator"

The Android ION memory allocator

vkkashyap — 2013-01-04T13:29:09+00:00

Thanks for nice article.

- What type of security risks do you foresee?
- Any other reason(s) you see for limiting physical addresses api to kernel space?

The Android ION memory allocator

zengtm — 2012-03-14T17:01:31+00:00

You cannot get physical address from user space: not secure if you think about it.

The Android ION memory allocator

cliveb — 2012-02-29T20:43:05+00:00

How can I get a physical address for the allocated memory from user space?

Integration with dma_buf

zengtm — 2012-02-22T01:44:47+00:00

"the design of ion is that you always have to know in advance how to allocate your buffer": the answer is yes, based on the ION implementations that I have the chance to study in the current Android 4.0.x release.

The Android ION memory allocator

zengtm — 2012-02-22T01:42:18+00:00

In the article it does say that map/unmap is the place to handle cache coherency and buffer synchronization. Did I have wording to indicate attach/detach is for synchronization?

And I agree that the persistent device mappings seem to be the more common smart phone use cases.

Integration with dma_buf

arnd — 2012-02-11T16:24:49+00:00

It should not be too hard to modify the ion code so it becomes a provider of dma_buf file descriptors and integrates into that framework.

When we discussed the design for dma_buf, it was intentionally made possible to have arbitrary subsystems provide interfaces that hand out dma_buf file descriptors to user space, although the focus so far was on having drm provide descriptors for buffers that it already manages. If I understand the article correctly, the design of ion is that you always have to know in advance how to allocate your buffer through the ion ioctl but then can pass it into any driver using it.

We should probably look into unifying the in-kernel interfaces for the two, because they are already very similar. and make ION_IOC_SHARE return a dma_buf descriptor that can be passed into any dma_buf enabled driver. The ion_import_fd function can then be replaced with the more abstract dma_buf equivalent.

The Android ION memory allocator

blackwood — 2012-02-09T09:31:14+00:00

Small correction on the dma_buf attach/detach functions: They're just used to reconfigure the pipeline - the exporter is allowed to delay the allocation up to map time and needs to because only by then all devices will be attached. Similarly it's map/unmap that should enforce cache coherency and synchronization and not attach/detach. We'll likely add an extension to allow streaming dma with persistent device mappings.

Also note that map/unmap doesn't synchronize hw access in the sense of gl sync objects. Imo that's an orthogonal issue to buffer sharing and dma buffer allocation. But something we might need to support in the kernel, too, because some SoC have hw-based semaphores and mailboxes to sync up different blocks without the cpu being woken up.