But that doesn't impact this concern. I actually think VFIO should
provide 'bind' uAPI to support these device side configuration things
rather than iommufd uAPI. IIUC iommufd should only do the setup on
IOMMU side.
The switching of TDISP state to LOCKED involves device side
differences that should be awared by the device owner, VFIO driver.
E.g. as we previously mentioned, to check if all MMIOs are never mapped.
Another E.g. invalidate MMIOs when device is to be LOCKED, some Pseudo
Code:
@@ -1494,7 +1494,15 @@ static int vfio_pci_ioctl_tsm_bind(struct vfio_pci_core_device *vdev,
if (!kvm)
return -ENOENT;
+ down_write(&vdev->memory_lock);
+ vfio_pci_dma_buf_move(vdev, true);
+
ret = pci_tsm_dev_bind(pdev, kvm, &bind.intf_id);
+
+ if (__vfio_pci_memory_enabled(vdev))
+ vfio_pci_dma_buf_move(vdev, false);
+ up_write(&vdev->memory_lock);
BTW, we may still need viommu/vdevice APIs during 'bind', if some IOMMU
side configurations are required by secure world. TDX does have some.
> without involving KVM or cVMs.
It may not be feasible for all vendors. I believe AMD would have one
firmware call that requires cVM handle *AND* move device into LOCKED
state. It really depends on firmware implementation.
So I'm expecting a coarse TSM verb pci_tsm_dev_bind() for vendors to do
any host side preparation and put device into LOCKED state.
>
> > Intel TDX connect implementation also needs a reference to the kvm
> > pointer to obtain the secure EPT information. This is crucial because
> > the CPU's page table must be shared with the iommu.
>
> I thought kvm folks were NAKing this sharing entirely? Or is the
I believe this is still Based on the general EPT sharing idea, is it?
There are several major reasons for the objection. In general, KVM now
has many "page non-present" tricks in EPT, which are not applicable to
IOPT. If shared, KVM has to take IOPT concerns into account, which is
quite a burden for KVM maintaining.
> secure EPT in the secure world and not directly managed by Linux?
Yes, the secure EPT is in the secure world and managed by TDX firmware.
Now a SW Mirror Secure EPT is introduced in KVM and managed by KVM
directly, and KVM will finally use firmware calls to propagate Mirror
Secure EPT changes to secure EPT.
Secure EPT are controlled by TDX module, basically KVM cannot play any
of the tricks. And TDX firmware should ensure any SEPT setting would be
applicable for Secure IOPT. I hope this could remove most of the
concerns.
I remember we've talked about SEPT sharing architechture for TDX TIO
before, but didn't get information back from KVM folks. Not sure how
things will go. Maybe will find out when we have some patches posted.
Thanks,
Yilun
>
> AFAIK AMD is going to mirror the iommu page table like today.
>
> ARM, I suspect, will not have an "EPT" under Linux control, so
> whatever happens will be hidden in their secure world.
>
> Jason
