[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB527649907D241347BCB540528C149@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Sat, 19 Mar 2022 07:51:31 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Robin Murphy <robin.murphy@....com>,
Matthew Rosato <mjrosato@...ux.ibm.com>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"david@...hat.com" <david@...hat.com>,
"farman@...ux.ibm.com" <farman@...ux.ibm.com>,
"oberpar@...ux.ibm.com" <oberpar@...ux.ibm.com>,
"vneethv@...ux.ibm.com" <vneethv@...ux.ibm.com>,
"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
"imbrenda@...ux.ibm.com" <imbrenda@...ux.ibm.com>,
"will@...nel.org" <will@...nel.org>,
Jean-Philippe Brucker <jean-philippe@...aro.org>,
"frankja@...ux.ibm.com" <frankja@...ux.ibm.com>,
"corbet@....net" <corbet@....net>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"pasic@...ux.ibm.com" <pasic@...ux.ibm.com>,
"gerald.schaefer@...ux.ibm.com" <gerald.schaefer@...ux.ibm.com>,
"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
"thuth@...hat.com" <thuth@...hat.com>,
"gor@...ux.ibm.com" <gor@...ux.ibm.com>,
"schnelle@...ux.ibm.com" <schnelle@...ux.ibm.com>,
"hca@...ux.ibm.com" <hca@...ux.ibm.com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"freude@...ux.ibm.com" <freude@...ux.ibm.com>,
"pmorel@...ux.ibm.com" <pmorel@...ux.ibm.com>,
"cohuck@...hat.com" <cohuck@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"svens@...ux.ibm.com" <svens@...ux.ibm.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Zhao, Yan Y" <yan.y.zhao@...el.com>
Subject: RE: [PATCH v4 14/32] iommu: introduce iommu_domain_alloc_type and the
KVM type
> From: Jason Gunthorpe <jgg@...dia.com>
> 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.
Thanks
Kevin
Powered by blists - more mailing lists