[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB5276DE2C3D0CBCBB380570348CE79@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Wed, 6 Apr 2022 00:08:45 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>,
Alex Williamson <alex.williamson@...hat.com>,
Lu Baolu <baolu.lu@...ux.intel.com>
CC: Christian Benvenuti <benve@...co.com>,
Cornelia Huck <cohuck@...hat.com>,
David Woodhouse <dwmw2@...radead.org>,
Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
Jason Wang <jasowang@...hat.com>,
"Joerg Roedel" <joro@...tes.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
Matthew Rosato <mjrosato@...ux.ibm.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Nelson Escobar <neescoba@...co.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Rob Clark <robdclark@...il.com>,
Robin Murphy <robin.murphy@....com>,
"Suravee Suthikulpanit" <suravee.suthikulpanit@....com>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
Will Deacon <will@...nel.org>, Christoph Hellwig <hch@....de>
Subject: RE: [PATCH 3/5] iommu: Introduce the domain op
enforce_cache_coherency()
> From: Tian, Kevin
> Sent: Wednesday, April 6, 2022 7:32 AM
>
> > From: Jason Gunthorpe <jgg@...dia.com>
> > Sent: Wednesday, April 6, 2022 6:58 AM
> >
> > On Tue, Apr 05, 2022 at 01:50:36PM -0600, Alex Williamson wrote:
> > > >
> > > > +static bool intel_iommu_enforce_cache_coherency(struct
> > iommu_domain *domain)
> > > > +{
> > > > + struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> > > > +
> > > > + if (!dmar_domain->iommu_snooping)
> > > > + return false;
> > > > + dmar_domain->enforce_no_snoop = true;
> > > > + return true;
> > > > +}
> > >
> > > Don't we have issues if we try to set DMA_PTE_SNP on DMARs that don't
> > > support it, ie. reserved register bit set in pte faults?
> >
> > The way the Intel driver is setup that is not possible. Currently it
> > does:
> >
> > static bool intel_iommu_capable(enum iommu_cap cap)
> > {
> > if (cap == IOMMU_CAP_CACHE_COHERENCY)
> > return domain_update_iommu_snooping(NULL);
> >
> > Which is a global property unrelated to any device.
> >
> > Thus either all devices and all domains support iommu_snooping, or
> > none do.
> >
> > It is unclear because for some reason the driver recalculates this
> > almost constant value on every device attach..
>
> The reason is simply because iommu capability is a global flag 😉
...and intel iommu driver supports hotplug-ed iommu. But in reality this
recalculation is almost a no-op because the only iommu that doesn't
support force snoop is for Intel GPU and built-in in the platform.
>
> when the cap is removed by this series I don't think we need keep that
> global recalculation thing.
>
> Thanks
> Kevin
Powered by blists - more mailing lists