> From: Jason Gunthorpe > Sent: Monday, March 21, 2022 10:07 PM > > 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.. > Currently SEV does use DMA pin i.e. pin_user_pages in sev_pin_memory(). I'm not sure whether it's a hardware limitation or just a software tradeoff for simplicity. But having that code does imply that KVM has absorbed certain restrictions with that pinning fact. But I agree they are not equivalent. e.g. suppose pinning is only applied to private/encrypted memory in SEV/TDX while iommu requires pinning the entire guest memory (if no IOPF support on device). btw no matter it's KVM to import iommu domain or it's iommufd to import KVM page table, in the end KVM mmu needs to explicitly mark out its page table as shared with IOMMU and enable all kinds of restrictions to support that sharing fact. Thanks Kevin
