linux-kernel - Re: [PATCH 3/4] iommu: Introduce device fault report API

Open Source and information security mailing list archives

Message-ID: <20190524110005.55c3eade@jacob-builder>
Date:   Fri, 24 May 2019 11:00:05 -0700
From:   Jacob Pan <jacob.jun.pan@...ux.intel.com>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Jean-Philippe Brucker <jean-philippe.brucker@....com>,
        joro@...tes.org, alex.williamson@...hat.com,
        yi.l.liu@...ux.intel.com, iommu@...ts.linux-foundation.org,
        ashok.raj@...el.com, linux-kernel@...r.kernel.org,
        jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH 3/4] iommu: Introduce device fault report API

On Thu, 23 May 2019 19:56:54 +0100
Robin Murphy <robin.murphy@....com> wrote:

> On 23/05/2019 19:06, Jean-Philippe Brucker wrote:
> > From: Jacob Pan <jacob.jun.pan@...ux.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@...ux.intel.com>
> > Signed-off-by: Ashok Raj <ashok.raj@...el.com>
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@....com>
> > Signed-off-by: Eric Auger <eric.auger@...hat.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@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

[Jacob Pan]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives