[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9F6FE96B71CF29479FF1CDC8046E15035A1B2E@039-SN1MPN1-003.039d.mgd.msft.net>
Date: Wed, 3 Apr 2013 15:55:36 +0000
From: Yoder Stuart-B08248 <B08248@...escale.com>
To: Sethi Varun-B16395 <B16395@...escale.com>,
Wood Scott-B07421 <B07421@...escale.com>,
Timur Tabi <timur@...i.org>
CC: Joerg Roedel <joro@...tes.org>,
lkml <linux-kernel@...r.kernel.org>,
Kumar Gala <galak@...nel.crashing.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
implementation.
> -----Original Message-----
> From: Sethi Varun-B16395
> Sent: Wednesday, April 03, 2013 12:12 AM
> To: Wood Scott-B07421; Timur Tabi
> Cc: Joerg Roedel; lkml; Kumar Gala; Yoder Stuart-B08248; iommu@...ts.linux-foundation.org; Benjamin
> Herrenschmidt; linuxppc-dev@...ts.ozlabs.org
> Subject: RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
>
>
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 03, 2013 7:23 AM
> > To: Timur Tabi
> > Cc: Joerg Roedel; Sethi Varun-B16395; lkml; Kumar Gala; Yoder Stuart-
> > B08248; iommu@...ts.linux-foundation.org; Benjamin Herrenschmidt;
> > linuxppc-dev@...ts.ozlabs.org
> > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
> > implementation.
> >
> > On 04/02/2013 08:35:54 PM, Timur Tabi wrote:
> > > On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro@...tes.org> wrote:
> > >
> > > > > + panic("\n");
> > > >
> > > > A kernel panic seems like an over-reaction to an access violation.
> > >
> > > We have no way to determining what code caused the violation, so we
> > > can't just kill the process. I agree it seems like overkill, but what
> > > else should we do? Does the IOMMU layer have a way for the IOMMU
> > > driver to stop the device that caused the problem?
> >
> > At a minimum, log a message and continue. Probably turn off the LIODN,
> > at least if it continues to be noisy (otherwise we could get stuck in an
> > interrupt storm as you note). Possibly let the user know somehow,
> > especially if it's a VFIO domain.
> [Sethi Varun-B16395] Can definitely log the message and disable the LIODN (to avoid an interrupt storm),
> but
> we definitely need a mechanism to inform vfio subsystem about the error. Also, disabling LIODN may not
> be a viable
> option with the new LIODN allocation scheme (where LIODN would be associated with a domain).
I think for phase 1 of this, just log the error, shut down DMA as you described.
We can implement more full featured error management, like notifying vfio
or the VM somehow in the future.
Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists