On 14/5/25 13:20, Xu Yilun wrote:
On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
On 10/5/25 13:47, Xu Yilun wrote:
On Fri, May 09, 2025 at 03:43:18PM -0300, Jason Gunthorpe wrote:
On Sat, May 10, 2025 at 12:28:48AM +0800, Xu Yilun wrote:
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.
I'm surprised by this.. iommufd shouldn't be doing PCI stuff, it is
just about managing the translation control of the device.
I have a little difficulty to understand. Is TSM bind PCI stuff? To me
it is. Host sends PCI TDISP messages via PCI DOE to put the device in
TDISP LOCKED state, so that device behaves differently from before. Then
why put it in IOMMUFD?
"TSM bind" sets up the CPU side of it, it binds a VM to a piece of IOMMU on the
host CPU.
I didn't fully get your idea, are you defending for "TSM bind is NOT PCI
stuff"? To me it is not true.
It is more IOMMU stuff than PCI and for the PCI part VFIO has nothing to add to
this.
TSM bind also sets up the device side. From your patch, it calls
tsm_tdi_bind(), which in turn calls spdm_forward(), I assume it is doing
TDISP LOCK. And TDISP LOCK changes device a lot.
DMA runs, MMIO works, what is that "lot"? Config space access works a bit
different but it traps into QEMU anyway and QEMU already knows about all this binding
business and can act accordingly.
The device does not know about the VM, it just enables/disables encryption by a
request from the CPU (those start/stop interface commands).
And IOMMUFD won't be doing DOE, the platform driver (such as AMD CCP) will.
Nothing to do for VFIO here.
IOMMUFD calls tsm_tdi_bind(), which is an interface doing PCI stuff.
Only forwards messages, no state change in page tables or anywhere in the host
kernel really. Thanks,
ps. hard to follow a million of (sub)threads but I am trying, sorry for the
delays :)
Thanks,
Yilun
We probably should notify VFIO about the state transition but I do not know
VFIO would want to do in response.
--
Alexey
