Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
drm/xen-zcopy: Add Xen zero-copy helper DRM driver
Introduce Xen zero-copy helper DRM driver, add user-space API of the driver: 1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS This will create a DRM dumb buffer from grant references provided by the frontend. The intended usage is: - Frontend - creates a dumb/display buffer and allocates memory - grants foreign access to the buffer pages - passes granted references to the backend - Backend - issues DRM_XEN_ZCOPY_DUMB_FROM_REFS ioctl to map granted references and create a dumb buffer - requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD - requests real HW driver/consumer to import the PRIME buffer with DRM_IOCTL_PRIME_FD_TO_HANDLE - uses handle returned by the real HW driver - at the end: o closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE o closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE o closes file descriptor of the exported buffer 2. DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS This will grant references to a dumb/display buffer's memory provided by the backend. The intended usage is: - Frontend - requests backend to allocate dumb/display buffer and grant references to its pages - Backend - requests real HW driver to create a dumb with DRM_IOCTL_MODE_CREATE_DUMB - requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD - requests zero-copy driver to import the PRIME buffer with DRM_IOCTL_PRIME_FD_TO_HANDLE - issues DRM_XEN_ZCOPY_DUMB_TO_REFS ioctl to grant references to the buffer's memory. - passes grant references to the frontend - at the end: - closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE - closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE - closes file descriptor of the imported buffer Implement GEM/IOCTL handling depending on driver mode of operation: - if GEM is created from grant references, then prepare to create a dumb from mapped pages - if GEM grant references are about to be provided for the imported PRIME buffer, then prepare for granting references and providing those to user-space Implement handling of display buffers from backend to/from front interaction point ov view: - when importing a buffer from the frontend: - allocate/free xen ballooned pages via Xen balloon driver or by manually allocating a DMA buffer - if DMA buffer is used, then increase/decrease its pages reservation accordingly - map/unmap foreign pages to the ballooned pages - when exporting a buffer to the frontend: - grant references for the pages of the imported PRIME buffer - pass the grants back to user-space, so those can be shared with the frontend Add an option to allocate DMA buffers as backing storage while importing a frontend's buffer into host's memory: for those use-cases when exported PRIME buffer will be used by a device expecting CMA buffers only, it is possible to map frontend's pages onto contiguous buffer, e.g. allocated via DMA API. Implement synchronous buffer deletion: for buffers, created from front's grant references, synchronization between backend and frontend is needed on buffer deletion as front expects us to unmap these references after XENDISPL_OP_DBUF_DESTROY response. For that reason introduce DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL: this will block until dumb buffer, with the wait handle provided, be freed. The rationale behind implementing own wait handle: - dumb buffer handle cannot be used as when the PRIME buffer gets exported there are at least 2 handles: one is for the backend and another one for the importing application, so when backend closes its handle and the other application still holds the buffer then there is no way for the backend to tell which buffer we want to wait for while calling xen_ioctl_wait_free - flink cannot be used as well as it is gone when DRM core calls .gem_free_object_unlocked Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
- Loading branch information