On 2/4/25 03:12, Jason Gunthorpe wrote:
On Tue, Feb 18, 2025 at 10:10:01PM +1100, Alexey Kardashevskiy wrote:
When a TDISP-capable device is passed through, it is configured as
a shared device to begin with. Later on when a VM probes the device,
detects its TDISP capability (reported via the PCIe ExtCap bit
called "TEE-IO"), performs the device attestation and transitions it
to a secure state when the device can run encrypted DMA and respond
to encrypted MMIO accesses.
Since KVM is out of the TCB, secure enablement is done in the secure
firmware. The API requires PCI host/guest BDFns, a KVM id hence such
calls are routed via IOMMUFD, primarily because allowing secure DMA
is the major performance bottleneck and it is a function of IOMMU.
Add TDI bind to do the initial binding of a passed through PCI
function to a VM. Add a forwarder for TIO GUEST REQUEST. These two
call into the TSM which forwards the calls to the PSP.
Can you list here what the basic flow of iommufd calls is to create a
CC VM, with no vIOMMU, and a CC capable vPCI device?
I do this in QEMU in additional to the usual VFIO setup:
iommufd_cdev_autodomains_get() [1]:
1. iommufd_backend_alloc_viommu
2. iommufd_backend_alloc_vdev
kvm_handle_vmgexit_tio_req() in KVM [2]:
1. (IOMMUFD) tio_bind(pdev, kvm_vmfd(kvm_state))
2. (KVM) kvm_set_memory_attributes_private(mmio region)
3. (SEV) sev_ioctl(/dev/sev, KVM_SEV_SNP_MMIO_RMP_UPDATE)
4. (IOMMUFD) tio_guest_request() /* enable DMA/MMIO in secure world */
I'd like the other arches to review this list and see how their arches
fit
Well, I have it all here: https://github.com/aik/qemu/tree/tsm
Raw stuff so I did not post it even as RFC but may be it'd help if I
did? Thanks,
[1]
https://github.com/aik/qemu/commit/da86ba11e71f10d48dd40a8d71a2ff595f04bb2d
[2]
https://github.com/aik/qemu/commit/f804b65aff5b28f6f0430a5abca07cbac73f70bc
--
Alexey
