[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB5276232DDAFC8041D5E795DE8C5F9@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 25 Jan 2022 01:11:01 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>,
Lu Baolu <baolu.lu@...ux.intel.com>
CC: "Raj, Ashok" <ashok.raj@...el.com>,
David Airlie <airlied@...ux.ie>,
Robin Murphy <robin.murphy@....com>,
Jonathan Hunter <jonathanh@...dia.com>,
Christoph Hellwig <hch@...radead.org>,
"Alex Williamson" <alex.williamson@...hat.com>,
Thierry Reding <thierry.reding@...il.com>,
Ben Skeggs <bskeggs@...hat.com>,
Daniel Vetter <daniel@...ll.ch>, Will Deacon <will@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Pan, Jacob jun" <jacob.jun.pan@...el.com>
Subject: RE: [PATCH 6/7] iommu: Use right way to retrieve iommu_ops
> From: Jason Gunthorpe via iommu
> Sent: Tuesday, January 25, 2022 1:37 AM
> > @@ -1295,7 +1298,7 @@ int iommu_page_response(struct device *dev,
> > msg->pasid = 0;
> > }
> >
> > - ret = domain->ops->page_response(dev, evt, msg);
> > + ret = ops->page_response(dev, evt, msg);
> > list_del(&evt->list);
> > kfree(evt);
> > break;
>
> Feels weird that page_response is not connected to a domain, the fault
> originated from a domain after all. I would say this op should be
> moved to the domain and the caller should provide the a pointer to the
> domain that originated the fault.
>
In concept yes.
But currently the entire sva path is not associated with domain. This was
one mistake as we discussed in the cover letter. Before extending iommu
domain to cover CPU page tables we may have to leave it in iommu_ops
given this series is just for cleanup...
Thanks
Kevin
Powered by blists - more mailing lists