On Fri, May 09, 2025 at 07:12:46PM +0800, Xu Yilun wrote: > On Fri, May 09, 2025 at 01:04:58PM +1000, Alexey Kardashevskiy wrote: > > Ping? > > Sorry for late reply from vacation. > > > Also, since there is pushback on 01/12 "dma-buf: Introduce > > dma_buf_get_pfn_unlocked() kAPI", what is the plan now? Thanks, > > As disscussed in the thread, this kAPI is not well considered but IIUC > the concept of "importer mapping" is still valid. We need more > investigation about all the needs - P2P, CC memory, private bus > channel, and work out a formal API. > > However in last few months I'm focusing on high level TIO flow - TSM > framework, IOMMUFD based bind/unbind, so no much progress here and is > still using this temporary kAPI. But as long as "importer mapping" is > alive, the dmabuf fd for KVM is still valid and we could enable TIO > based on that.
Oh I forgot to mention I moved the dmabuf creation from VFIO to IOMMUFD recently, the IOCTL is against iommufd_device. According to Jason's opinion [1], TSM bind/unbind should be called against iommufd_device, then I need to do the same for dmabuf. This is because Intel TDX Connect enforces a specific operation sequence between TSM unbind & MMIO unmap: 1. STOP TDI via TDISP message STOP_INTERFACE 2. Private MMIO unmap from Secure EPT 3. Trusted Device Context Table cleanup for the TDI 4. TDI ownership reclaim and metadata free That makes TSM unbind & dmabuf closely correlated and should be managed by the same kernel component. IIUC, the suggested flow is VFIO receives a CC capable flag and propagate to IOMMUFD, which means VFIO hand over device's MMIO management & CC management to IOMMUFD. [1]: https://lore.kernel.org/all/20250306182614.gf354...@ziepe.ca/ Thanks, Yilun
