On 09/06/2025 07:10, Xu Yilun wrote:
On Thu, Jun 05, 2025 at 11:54:35AM -0300, Jason Gunthorpe wrote:
On Thu, Jun 05, 2025 at 11:25:29AM +0800, Xu Yilun wrote:
That's good point, thanks. S-EPT is controlled by TSM, but the fact is,
unlike RMP it needs too much help from VMM side, and now KVM is the
helper. I will continue to investigate if TDX TSM driver could opt in to
become another helper and how to coordinate with KVM.
I think it would be quite a simplification if the iommufd operation
would also cause the TSM to setup the secure MMIO directly from the
pPCI device and remove hypervisor access to it.
Then you don't need DMABUF to KVM at all.
I thought about this for sometime. It may be possible to trigger KVM
to populate/zap the S-EPT but cannot let TSM direct setup/remove S-EPT.
RMP could be updated by a single instruction, but S-EPT update involves
generic KVM MMU flow like Page Table Page management, TLB invalidation,
even mirror EPT management (specific to x86 KVM MMU).
To make KVM populate S-EPT, we need KVM memory slots and in turn need
DMABUF.
May be this is answered/discussed already, but why can't we use
(vfio->fd, offset) similar to the gmem_fd for KVM memory slot ? VFIO
could prevent mmap if the device is bound and also pervent bind, when
there is a mapping ?
Suzuki
Thanks,
Yilun
The create vPCI call would have to specify the base virtual addresses
of all the BARs from userspace, which is probably OK as I suspose you
also cannot disable or relocate the MMIO BAR while in T=1 mode.
Jason
