On Sat, Mar 19, 2022 at 07:51:31AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Friday, March 18, 2022 10:13 PM > > > > On Fri, Mar 18, 2022 at 02:23:57AM +0000, Tian, Kevin wrote: > > > > > Yes, that is another major part work besides the iommufd work. And > > > it is not compatible with KVM features which rely on the dynamic > > > manner of EPT. Though It is a bit questionable whether it's worthy of > > > doing so just for saving memory footprint while losing other capabilities, > > > it is a requirement for some future security extension in Intel trusted > > > computing architecture. And KVM has been pinning pages for SEV/TDX/etc. > > > today thus some facilities can be reused. But I agree it is not a simple > > > task thus we need start discussion early to explore various gaps in > > > iommu and kvm. > > > > Yikes. IMHO this might work better going the other way, have KVM > > import the iommu_domain and use that as the KVM page table than vice > > versa. > > > > The semantics are a heck of a lot clearer, and it is really obvious > > that alot of KVM becomes disabled if you do this. > > > > This is an interesting angle to look at it. But given pinning is already > required in KVM to support SEV/TDX even w/o assigned device, those > restrictions have to be understood by KVM MMU code which makes > a KVM-managed page table under such restrictions closer to be > sharable with IOMMU. I thought the SEV/TDX stuff wasn't being done with pinning but via a memfd in a special mode that does sort of pin under the covers, but it is not necessarily a DMA pin. (it isn't even struct page memory, so I'm not even sure what pin means) Certainly, there is no inherent problem with SEV/TDX having movable memory and KVM could concievably handle this - but iommu cannot. I would not make an equivilance with SEV/TDX and iommu at least.. Jason
