From: "Tian, Kevin" <kevin.tian@intel.com> To: Lu Baolu <baolu.lu@linux.intel.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org> Cc: "Raj, Ashok" <ashok.raj@intel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: RE: [PATCH 3/4] iommu/vt-d: Report page request faults for guest SVA Date: Tue, 30 Jun 2020 06:01:13 +0000 [thread overview] Message-ID: <MWHPR11MB16450BD48B3EF42A8E82E5698C6F0@MWHPR11MB1645.namprd11.prod.outlook.com> (raw) In-Reply-To: <20200628003332.5720-4-baolu.lu@linux.intel.com> > From: Lu Baolu <baolu.lu@linux.intel.com> > Sent: Sunday, June 28, 2020 8:34 AM > > A pasid might be bound to a page table from a VM guest via the iommu > ops.sva_bind_gpasid. In this case, when a DMA page fault is detected > on the physical IOMMU, we need to inject the page fault request into > the guest. After the guest completes handling the page fault, a page > response need to be sent back via the iommu ops.page_response(). > > This adds support to report a page request fault. Any external module > which is interested in handling this fault should regiester a notifier > callback. > > Co-developed-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > Co-developed-by: Liu Yi L <yi.l.liu@intel.com> > Signed-off-by: Liu Yi L <yi.l.liu@intel.com> > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > --- > drivers/iommu/intel/svm.c | 83 > +++++++++++++++++++++++++++++++++++++-- > 1 file changed, 80 insertions(+), 3 deletions(-) > > diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c > index c23167877b2b..4800bb6f8794 100644 > --- a/drivers/iommu/intel/svm.c > +++ b/drivers/iommu/intel/svm.c > @@ -815,6 +815,69 @@ static void intel_svm_drain_prq(struct device *dev, > int pasid) > } > } > > +static int prq_to_iommu_prot(struct page_req_dsc *req) > +{ > + int prot = 0; > + > + if (req->rd_req) > + prot |= IOMMU_FAULT_PERM_READ; > + if (req->wr_req) > + prot |= IOMMU_FAULT_PERM_WRITE; > + if (req->exe_req) > + prot |= IOMMU_FAULT_PERM_EXEC; > + if (req->pm_req) > + prot |= IOMMU_FAULT_PERM_PRIV; > + > + return prot; > +} > + > +static int > +intel_svm_prq_report(struct intel_iommu *iommu, struct page_req_dsc > *desc) > +{ > + struct iommu_fault_event event; > + struct pci_dev *pdev; > + u8 bus, devfn; > + int ret = 0; > + > + memset(&event, 0, sizeof(struct iommu_fault_event)); > + bus = PCI_BUS_NUM(desc->rid); > + devfn = desc->rid & 0xff; > + pdev = pci_get_domain_bus_and_slot(iommu->segment, bus, devfn); Is this step necessary? dev can be passed in (based on sdev), and more importantly iommu_report_device_fault already handles the ref counting e.g. get_device(dev) when fault handler is valid... > + > + if (!pdev) { > + pr_err("No PCI device found for PRQ [%02x:%02x.%d]\n", > + bus, PCI_SLOT(devfn), PCI_FUNC(devfn)); > + return -ENODEV; > + } > + > + /* Fill in event data for device specific processing */ > + event.fault.type = IOMMU_FAULT_PAGE_REQ; > + event.fault.prm.addr = desc->addr; > + event.fault.prm.pasid = desc->pasid; > + event.fault.prm.grpid = desc->prg_index; > + event.fault.prm.perm = prq_to_iommu_prot(desc); > + > + /* > + * Set last page in group bit if private data is present, > + * page response is required as it does for LPIG. > + */ > + if (desc->lpig) > + event.fault.prm.flags |= > IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE; > + if (desc->pasid_present) > + event.fault.prm.flags |= > IOMMU_FAULT_PAGE_REQUEST_PASID_VALID; > + if (desc->priv_data_present) { > + event.fault.prm.flags |= > IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE; why setting lpig under this condition? > + event.fault.prm.flags |= > IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA; > + memcpy(event.fault.prm.private_data, desc->priv_data, > + sizeof(desc->priv_data)); > + } > + > + ret = iommu_report_device_fault(&pdev->dev, &event); > + pci_dev_put(pdev); > + > + return ret; > +} > + > static irqreturn_t prq_event_thread(int irq, void *d) > { > struct intel_iommu *iommu = d; > @@ -874,6 +937,19 @@ static irqreturn_t prq_event_thread(int irq, void *d) > if (!is_canonical_address(address)) > goto bad_req; > > + /* > + * If prq is to be handled outside iommu driver via receiver of > + * the fault notifiers, we skip the page response here. > + */ > + if (svm->flags & SVM_FLAG_GUEST_MODE) { > + int res = intel_svm_prq_report(iommu, req); > + > + if (!res) > + goto prq_advance; > + else > + goto bad_req; > + } > + I noted in bad_req there is another reporting logic: if (sdev && sdev->ops && sdev->ops->fault_cb) { int rwxp = (req->rd_req << 3) | (req->wr_req << 2) | (req->exe_req << 1) | (req->pm_req); sdev->ops->fault_cb(sdev->dev, req->pasid, req->addr, req->priv_data, rwxp, result); } It was introduced in the 1st version of svm.c. It might be unrelated to this patch, but I wonder whether that one should be replaced with iommu_report_device_fault too? Thanks Kevin > /* If the mm is already defunct, don't handle faults. */ > if (!mmget_not_zero(svm->mm)) > goto bad_req; > @@ -892,10 +968,10 @@ static irqreturn_t prq_event_thread(int irq, void *d) > goto invalid; > > result = QI_RESP_SUCCESS; > - invalid: > +invalid: > mmap_read_unlock(svm->mm); > mmput(svm->mm); > - bad_req: > +bad_req: > /* Accounting for major/minor faults? */ > rcu_read_lock(); > list_for_each_entry_rcu(sdev, &svm->devs, list) { > @@ -920,7 +996,7 @@ static irqreturn_t prq_event_thread(int irq, void *d) > and these can be NULL. Do not use them below this point! > */ > sdev = NULL; > svm = NULL; > - no_pasid: > +no_pasid: > if (req->lpig || req->priv_data_present) { > /* > * Per VT-d spec. v3.0 ch7.7, system software must > @@ -945,6 +1021,7 @@ static irqreturn_t prq_event_thread(int irq, void *d) > resp.qw3 = 0; > qi_submit_sync(iommu, &resp, 1, 0); > } > +prq_advance: > head = (head + sizeof(*req)) & PRQ_RING_MASK; > } > > -- > 2.17.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-06-30 6:01 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-28 0:33 [PATCH 0/4] iommu/vt-d: Add prq report and response support Lu Baolu 2020-06-28 0:33 ` [PATCH 1/4] iommu/vt-d: Refactor device_to_iommu() helper Lu Baolu 2020-06-28 0:33 ` [PATCH 2/4] iommu/vt-d: Add a helper to get svm and sdev for pasid Lu Baolu 2020-06-28 0:33 ` [PATCH 3/4] iommu/vt-d: Report page request faults for guest SVA Lu Baolu 2020-06-30 6:01 ` Tian, Kevin [this message] 2020-07-01 2:27 ` Lu Baolu 2020-06-28 0:33 ` [PATCH 4/4] iommu/vt-d: Add page response ops support Lu Baolu 2020-06-30 6:19 ` Tian, Kevin 2020-07-01 2:44 ` Lu Baolu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=MWHPR11MB16450BD48B3EF42A8E82E5698C6F0@MWHPR11MB1645.namprd11.prod.outlook.com \ --to=kevin.tian@intel.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=iommu@lists.linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --subject='RE: [PATCH 3/4] iommu/vt-d: Report page request faults for guest SVA' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).