From: Jacob Pan <jacob.jun.pan@linux.intel.com> To: Robin Murphy <robin.murphy@arm.com> Cc: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>, joro@8bytes.org, alex.williamson@redhat.com, yi.l.liu@linux.intel.com, iommu@lists.linux-foundation.org, ashok.raj@intel.com, linux-kernel@vger.kernel.org, jacob.jun.pan@linux.intel.com Subject: Re: [PATCH 3/4] iommu: Introduce device fault report API Date: Fri, 24 May 2019 11:00:05 -0700 [thread overview] Message-ID: <20190524110005.55c3eade@jacob-builder> (raw) In-Reply-To: <e56244fd-86fd-1fc9-17f7-d00179d586ac@arm.com> On Thu, 23 May 2019 19:56:54 +0100 Robin Murphy <robin.murphy@arm.com> wrote: > On 23/05/2019 19:06, Jean-Philippe Brucker wrote: > > From: Jacob Pan <jacob.jun.pan@linux.intel.com> > > > > Traditionally, device specific faults are detected and handled > > within their own device drivers. When IOMMU is enabled, faults such > > as DMA related transactions are detected by IOMMU. There is no > > generic reporting mechanism to report faults back to the in-kernel > > device driver or the guest OS in case of assigned devices. > > > > This patch introduces a registration API for device specific fault > > handlers. This differs from the existing iommu_set_fault_handler/ > > report_iommu_fault infrastructures in several ways: > > - it allows to report more sophisticated fault events (both > > unrecoverable faults and page request faults) due to the nature > > of the iommu_fault struct > > - it is device specific and not domain specific. > > > > The current iommu_report_device_fault() implementation only handles > > the "shoot and forget" unrecoverable fault case. Handling of page > > request faults or stalled faults will come later. > > > > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > > Signed-off-by: Ashok Raj <ashok.raj@intel.com> > > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> > > Signed-off-by: Eric Auger <eric.auger@redhat.com> > > --- > > drivers/iommu/iommu.c | 127 > > ++++++++++++++++++++++++++++++++++++++++++ include/linux/iommu.h | > > 29 ++++++++++ 2 files changed, 156 insertions(+) > > > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > > index 67ee6623f9b2..d546f7baa0d4 100644 > > --- a/drivers/iommu/iommu.c > > +++ b/drivers/iommu/iommu.c > > @@ -644,6 +644,13 @@ int iommu_group_add_device(struct iommu_group > > *group, struct device *dev) goto err_free_name; > > } > > > > + dev->iommu_param = kzalloc(sizeof(*dev->iommu_param), > > GFP_KERNEL); > > + if (!dev->iommu_param) { > > + ret = -ENOMEM; > > + goto err_free_name; > > + } > > + mutex_init(&dev->iommu_param->lock); > > + > > Note that this gets a bit tricky when we come to move to move the > fwspec/ops/etc. into iommu_param, since that data can have a longer > lifespan than the group association. I'd suggest moving this > management out to the iommu_{probe,release}_device() level from the > start, but maybe we're happy to come back and change things later as > necessary. > Agreed, I can't think of any downside of moving it earlier. > Robin. > > [...] > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu [Jacob Pan]
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com> To: Robin Murphy <robin.murphy@arm.com> Cc: yi.l.liu@linux.intel.com, ashok.raj@intel.com, Jean-Philippe Brucker <jean-philippe.brucker@arm.com>, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, alex.williamson@redhat.com Subject: Re: [PATCH 3/4] iommu: Introduce device fault report API Date: Fri, 24 May 2019 11:00:05 -0700 [thread overview] Message-ID: <20190524110005.55c3eade@jacob-builder> (raw) In-Reply-To: <e56244fd-86fd-1fc9-17f7-d00179d586ac@arm.com> On Thu, 23 May 2019 19:56:54 +0100 Robin Murphy <robin.murphy@arm.com> wrote: > On 23/05/2019 19:06, Jean-Philippe Brucker wrote: > > From: Jacob Pan <jacob.jun.pan@linux.intel.com> > > > > Traditionally, device specific faults are detected and handled > > within their own device drivers. When IOMMU is enabled, faults such > > as DMA related transactions are detected by IOMMU. There is no > > generic reporting mechanism to report faults back to the in-kernel > > device driver or the guest OS in case of assigned devices. > > > > This patch introduces a registration API for device specific fault > > handlers. This differs from the existing iommu_set_fault_handler/ > > report_iommu_fault infrastructures in several ways: > > - it allows to report more sophisticated fault events (both > > unrecoverable faults and page request faults) due to the nature > > of the iommu_fault struct > > - it is device specific and not domain specific. > > > > The current iommu_report_device_fault() implementation only handles > > the "shoot and forget" unrecoverable fault case. Handling of page > > request faults or stalled faults will come later. > > > > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > > Signed-off-by: Ashok Raj <ashok.raj@intel.com> > > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> > > Signed-off-by: Eric Auger <eric.auger@redhat.com> > > --- > > drivers/iommu/iommu.c | 127 > > ++++++++++++++++++++++++++++++++++++++++++ include/linux/iommu.h | > > 29 ++++++++++ 2 files changed, 156 insertions(+) > > > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > > index 67ee6623f9b2..d546f7baa0d4 100644 > > --- a/drivers/iommu/iommu.c > > +++ b/drivers/iommu/iommu.c > > @@ -644,6 +644,13 @@ int iommu_group_add_device(struct iommu_group > > *group, struct device *dev) goto err_free_name; > > } > > > > + dev->iommu_param = kzalloc(sizeof(*dev->iommu_param), > > GFP_KERNEL); > > + if (!dev->iommu_param) { > > + ret = -ENOMEM; > > + goto err_free_name; > > + } > > + mutex_init(&dev->iommu_param->lock); > > + > > Note that this gets a bit tricky when we come to move to move the > fwspec/ops/etc. into iommu_param, since that data can have a longer > lifespan than the group association. I'd suggest moving this > management out to the iommu_{probe,release}_device() level from the > start, but maybe we're happy to come back and change things later as > necessary. > Agreed, I can't think of any downside of moving it earlier. > Robin. > > [...] > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu [Jacob Pan] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-05-24 17:57 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-23 18:06 [PATCH 0/4] iommu: Add device fault reporting API Jean-Philippe Brucker 2019-05-23 18:06 ` Jean-Philippe Brucker 2019-05-23 18:06 ` [PATCH 1/4] driver core: Add per device iommu param Jean-Philippe Brucker 2019-05-23 18:06 ` Jean-Philippe Brucker 2019-05-23 18:06 ` [PATCH 2/4] iommu: Introduce device fault data Jean-Philippe Brucker 2019-05-23 18:06 ` Jean-Philippe Brucker 2019-05-23 18:43 ` Robin Murphy 2019-05-23 18:43 ` Robin Murphy 2019-05-24 13:49 ` Jacob Pan 2019-05-24 13:49 ` Jacob Pan 2019-05-24 16:14 ` Jean-Philippe Brucker 2019-05-24 16:14 ` Jean-Philippe Brucker 2019-05-24 17:44 ` Jacob Pan 2019-05-24 17:44 ` Jacob Pan 2019-05-23 18:06 ` [PATCH 3/4] iommu: Introduce device fault report API Jean-Philippe Brucker 2019-05-23 18:06 ` Jean-Philippe Brucker 2019-05-23 18:56 ` Robin Murphy 2019-05-23 18:56 ` Robin Murphy 2019-05-24 18:00 ` Jacob Pan [this message] 2019-05-24 18:00 ` Jacob Pan 2019-05-31 13:37 ` Jean-Philippe Brucker 2019-05-31 13:37 ` Jean-Philippe Brucker 2019-05-23 18:06 ` [PATCH 4/4] iommu: Add recoverable fault reporting Jean-Philippe Brucker 2019-05-23 18:06 ` Jean-Philippe Brucker 2019-05-24 18:14 ` Jacob Pan 2019-05-24 18:14 ` Jacob Pan 2019-05-31 11:05 ` Jean-Philippe Brucker 2019-05-31 11:05 ` Jean-Philippe Brucker
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=20190524110005.55c3eade@jacob-builder \ --to=jacob.jun.pan@linux.intel.com \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jean-philippe.brucker@arm.com \ --cc=joro@8bytes.org \ --cc=linux-kernel@vger.kernel.org \ --cc=robin.murphy@arm.com \ --cc=yi.l.liu@linux.intel.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.