RE: [PATCH v4 14/32] iommu: introduce iommu_domain_alloc_type and the KVM type

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Thursday, March 17, 2022 9:53 PM
> 
> On Thu, Mar 17, 2022 at 05:47:36AM +0000, Tian, Kevin wrote:
> > > From: Robin Murphy
> > > Sent: Tuesday, March 15, 2022 6:49 PM
> > >
> > > On 2022-03-14 19:44, Matthew Rosato wrote:
> > > > s390x will introduce an additional domain type that is used for
> > > > managing IOMMU owned by KVM.  Define the type here and add an
> > > > interface for allocating a specified type vs the default type.
> > >
> > > I'm also not a huge fan of adding a new domain_alloc interface like
> > > this, however if it is justifiable, then please make it take struct
> > > device rather than struct bus_type as an argument.
> > >
> > > It also sounds like there may be a degree of conceptual overlap here
> > > with what Jean-Philippe is working on for sharing pagetables between
> KVM
> > > and SMMU for Android pKVM, so it's probably worth some thought over
> > > whether there's any scope for common interfaces in terms of actual
> > > implementation.
> >
> > Same here. Yan Zhao is working on page table sharing between KVM
> > and VT-d. This is one important usage to build atop iommufd and
> > a set of common interfaces are definitely necessary here. 😊
> 
> I always thought 'page table sharing with KVM' is SVA - ie it requires
> PRI in the IOMMU driver as the KVM page table is fully unpinned and
> dynamic. This S390 case is not doing SVA/PRI
> 
> Are people working on teaching KVM to DMA pin every page and avoid
> having a dynamic page table? I'm surprised, a lot of stuff won't work,
> eg write protect..
> 

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.

Imagine many threads (dirty tracking, nested, KVM page table sharing,
etc.) will run in parallel soon after the new iommufd RFC is out. lots of
fun ahead. 😊

Thanks
Kevin