probably should keep the discussion on github (USAGE.md was updated a bit more and merged into https://github.com/cubanismo/allocator so look there for the latest).. but briefly: 1) my expectation is if the user is implementing some use-case, it knows what devices and APIs are involved, otherwise it wouldn't be able to pass a buffer to that device/API.. 2) if assertion/usage/devices haven't changed, you can re-use the merged caps for however many buffer allocations BR, -R On Fri, Oct 7, 2016 at 9:54 AM, Benjamin Gaignard <benjamin.gaignard@xxxxxxxxxx> wrote: > Rob, > > how do you know which devices are concerned when listing the constraints ? > Does combine_capabilities is done from each allocation or can it be cached ? > > Regards, > Benjmain > > 2016-10-06 18:54 GMT+02:00 Rob Clark <robdclark@xxxxxxxxx>: >> so there is discussion about a "central userspace allocator" (ie. more >> like a common userspace API that could be implemented on top of >> various devices/APIs) to decide in a generic way which device could >> allocate. >> >> https://github.com/cubanismo/allocator >> >> and I wrote up some rough thoughts/proposal about how the usage might >> look.. just rough, so don't try to compile it or anything, and not >> consensus yet so it will probably change/evolve.. >> >> https://github.com/robclark/allocator/blob/master/USAGE.md >> >> I think ion could be just another device to share buffers with, which >> happens to not impose any specific constraints. How "liballoc-ion.so" >> backend figures out how to map constraints/usage to a heap is a bit >> hand-wavey at the moment. >> >> BR, >> -R >> >> On Wed, Oct 5, 2016 at 9:40 AM, Benjamin Gaignard >> <benjamin.gaignard@xxxxxxxxxx> wrote: >>> because with ion it is up to userland to decide which heap to use >>> and until now userland doesn't have any way to get device constraints... >>> >>> I will prefer let a central allocator (in kernel) decide from the >>> attached devices >>> which allocator is the best. It is what I have implemented in smaf. >>> >>> Benjamin >>> >>> >>> 2016-10-05 15:19 GMT+02:00 Daniel Vetter <daniel@xxxxxxxx>: >>>> On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote: >>>>> version 10 changes: >>>>> - rebased on kernel 4.8 tag >>>>> - minor typo fix >>>>> >>>>> version 9 changes: >>>>> - rebased on 4.8-rc5 >>>>> - struct dma_attrs doesn't exist anymore so update CMA allocator >>>>> to compile with new dma_*_attr functions >>>>> - add example SMAF use case in cover letter >>>>> >>>>> version 8 changes: >>>>> - rework of the structures used within ioctl >>>>> by adding a version field and padding to be futur proof >>>>> - rename fake secure moduel to test secure module >>>>> - fix the various remarks done on the previous patcheset >>>>> >>>>> version 7 changes: >>>>> - rebased on kernel 4.6-rc7 >>>>> - simplify secure module API >>>>> - add vma ops to be able to detect mmap/munmap calls >>>>> - add ioctl to get number and allocator names >>>>> - update libsmaf with adding tests >>>>> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git >>>>> - add debug log in fake secure module >>>>> >>>>> version 6 changes: >>>>> - rebased on kernel 4.5-rc4 >>>>> - fix mmapping bug while requested allocation size isn't a a multiple of >>>>> PAGE_SIZE (add a test for this in libsmaf) >>>>> >>>>> version 5 changes: >>>>> - rebased on kernel 4.3-rc6 >>>>> - rework locking schema and make handle status use an atomic_t >>>>> - add a fake secure module to allow performing tests without trusted >>>>> environment >>>>> >>>>> version 4 changes: >>>>> - rebased on kernel 4.3-rc3 >>>>> - fix missing EXPORT_SYMBOL for smaf_create_handle() >>>>> >>>>> version 3 changes: >>>>> - Remove ioctl for allocator selection instead provide the name of >>>>> the targeted allocator with allocation request. >>>>> Selecting allocator from userland isn't the prefered way of working >>>>> but is needed when the first user of the buffer is a software component. >>>>> - Fix issues in case of error while creating smaf handle. >>>>> - Fix module license. >>>>> - Update libsmaf and tests to care of the SMAF API evolution >>>>> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git >>>>> >>>>> version 2 changes: >>>>> - Add one ioctl to allow allocator selection from userspace. >>>>> This is required for the uses case where the first user of >>>>> the buffer is a software IP which can't perform dma_buf attachement. >>>>> - Add name and ranking to allocator structure to be able to sort them. >>>>> - Create a tiny library to test SMAF: >>>>> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git >>>>> - Fix one issue when try to secure buffer without secure module registered >>>>> >>>>> SMAF aim to solve two problems: allocating memory that fit with hardware IPs >>>>> constraints and secure those data from bus point of view. >>>>> >>>>> One example of SMAF usage is camera preview: on SoC you may use either an USB >>>>> webcam or the built-in camera interface and the frames could be send directly >>>>> to the dipslay Ip or handle by GPU. >>>>> Most of USB interfaces and GPU have mmu but almost all built-in camera >>>>> interace and display Ips don't have mmu so when selecting how allocate >>>>> buffer you need to be aware of each devices constraints (contiguous memroy, >>>>> stride, boundary, alignment ...). >>>>> ION has solve this problem by let userland decide which allocator (heap) to use >>>>> but this require to adapt userland for each platform and sometime for each >>>>> use case. >>>>> >>>>> To be sure to select the best allocation method for devices SMAF implement >>>>> deferred allocation mechanism: memory allocation is only done when the first >>>>> device effectively required it. >>>>> Allocator modules have to implement a match() to let SMAF know if they are >>>>> compatibles with devices needs. >>>>> This patch set provide an example of allocator module which use >>>>> dma_{alloc/free/mmap}_attrs() and check if at least one device have >>>>> coherent_dma_mask set to DMA_BIT_MASK(32) in match function. >>>>> >>>>> In the same camera preview use case, SMAF allow to protect the data from being >>>>> read by unauthorized IPs (i.e. a malware to dump camera stream). >>>>> Until now I have only see access rights protection at process/thread level >>>>> (PKeys/MPK) or on file (SELinux) but nothing allow to drive data bus firewalls. >>>>> SMAF propose an interface to control and implement those firewalls. >>>>> Like IOMMU, firewalls IPs can help to protect memory from malicious/faulty devices >>>>> that are attempting DMA attacks. >>>>> >>>>> Secure modules are responsibles of granting and revoking devices access rights >>>>> on the memory. Secure module is also called to check if CPU map memory into >>>>> kernel and user address spaces. >>>>> An example of secure module implementation can be found here: >>>>> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git >>>>> This code isn't yet part of the patch set because it depends on generic TEE >>>>> which is still under discussion (https://lwn.net/Articles/644646/) >>>>> >>>>> For allocation part of SMAF code I get inspirated by Sumit Semwal work about >>>>> constraint aware allocator. >>>> >>>> semi-random review comment, and a bit late: Why not implement smaf as a >>>> new heap in ion? I think consensus is pretty much that we'll be stuck with >>>> ion forever, and I think it's better to have 1 central buffer allocater >>>> than lots of them ... >>>> -Daniel >>>> >>>>> >>>>> Benjamin Gaignard (3): >>>>> create SMAF module >>>>> SMAF: add CMA allocator >>>>> SMAF: add test secure module >>>>> >>>>> drivers/Kconfig | 2 + >>>>> drivers/Makefile | 1 + >>>>> drivers/smaf/Kconfig | 17 + >>>>> drivers/smaf/Makefile | 3 + >>>>> drivers/smaf/smaf-cma.c | 186 ++++++++++ >>>>> drivers/smaf/smaf-core.c | 818 +++++++++++++++++++++++++++++++++++++++++ >>>>> drivers/smaf/smaf-testsecure.c | 90 +++++ >>>>> include/linux/smaf-allocator.h | 45 +++ >>>>> include/linux/smaf-secure.h | 65 ++++ >>>>> include/uapi/linux/smaf.h | 85 +++++ >>>>> 10 files changed, 1312 insertions(+) >>>>> create mode 100644 drivers/smaf/Kconfig >>>>> create mode 100644 drivers/smaf/Makefile >>>>> create mode 100644 drivers/smaf/smaf-cma.c >>>>> create mode 100644 drivers/smaf/smaf-core.c >>>>> create mode 100644 drivers/smaf/smaf-testsecure.c >>>>> create mode 100644 include/linux/smaf-allocator.h >>>>> create mode 100644 include/linux/smaf-secure.h >>>>> create mode 100644 include/uapi/linux/smaf.h >>>>> >>>>> -- >>>>> 1.9.1 >>>>> >>>>> _______________________________________________ >>>>> dri-devel mailing list >>>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>>> >>>> -- >>>> Daniel Vetter >>>> Software Engineer, Intel Corporation >>>> http://blog.ffwll.ch >>> >>> >>> >>> -- >>> Benjamin Gaignard >>> >>> Graphic Study Group >>> >>> Linaro.org │ Open source software for ARM SoCs >>> >>> Follow Linaro: Facebook | Twitter | Blog >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Benjamin Gaignard > > Graphic Study Group > > Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: Facebook | Twitter | Blog _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
