On Tue, Jun 10, 2025 at 02:47:32PM +1000, Alexey Kardashevskiy wrote: > > > On 3/6/25 14:05, Xu Yilun wrote: > > On Mon, Jun 02, 2025 at 01:48:57PM -0300, Jason Gunthorpe wrote: > > > On Tue, Jun 03, 2025 at 12:25:21AM +0800, Xu Yilun wrote: > > > > > > > > Looking at your patch series, I understand the reason you need a vfio > > > > > ioctl is to call pci_request_regions_exclusive—is that correct? > > > > > > > > The immediate reason is to unbind the TDI before unmapping the BAR. > > > > > > Maybe you should just do this directly, require the TSM layer to issue > > > an unbind if it gets any requests to change the secure EPT? > > > > The TSM layer won't touch S-EPT, KVM manages S-EPT. > > Is not it the TDX fw which manages _S_-EPT? TDX fw writes the S-EPT entries, but to "manage" S-EPT, there are more works for VMM. The S-EPT related TDX fwcalls are verbose, it is not a fwcall like "TDX_SEPT_MAP/UNMAP(gfn_range, pfn_range)" then the tree is there. I wanna briefly describe the S-EPT fwcalls - A SEPT_ADD fwcall links a page-table page to a specifc S-EPT non-leaf entry. - A PAGE_AUG fwcall links a guest memory page to a specific leaf entry. - The MEM_TRACK fwcall tracks if VMM kicks all VCPUs out of guest mode, to ensure TLB for S-EPT are flushed/synced for every VCPU. - A PAGE_REMOVE fwcall clears a specific leaf entry, only when TLB flush are all done. So it is KVM's job to orchestrate what a S-EPT tree should look like, and request TDX fw to add/remove each S-EPT node one by one. TDX fw is responsible for the security check for each adding/removing request, if the check passed, TDX fw writes the actual S-EPT entry. These TDX base implementations are already in linux-next. > And the TDX host driver (what is it called btw? Intel's "CCP") registers itself as TSM in the TSM core so it is somewhere near S-EPT logic? Thanks, Currently kvm_intel is near S-EPT for private memory, just as kvm_amd is near RMP for private memory. I see in AMD's solution, CCP TSM driver could directly operate RMP for MMIO. I was trying to figure out if TDX TSM driver could also operate MMIO part of S-EPT, but I didn't see the chance. Kicking VCPUs is not what TSM driver could do. Another thing is the existing KVM mirror page table mechenism (allow me to keep simple). Thanks, Yilun > > > > > Similarly IOMMUFD/IOMMU driver manages IOMMUPT. When p2p is > > involved, still need to unbind the TDI first then unmap the BAR for > > IOMMUPT. > > > > Thanks, > > Yilun > > > > > > > > Jason > > -- > Alexey >
