[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKocOOM42mpRRt1ziYaUfTfrsRDL5nLM=yUPEGinUvmQXA=x=w@mail.gmail.com>
Date: Fri, 21 Jun 2013 10:44:06 -0600
From: Shuah Khan <shuahkhan@...il.com>
To: Joerg Roedel <joro@...tes.org>
Cc: Borislav Petkov <bp@...en8.de>, suravee.suthikulpanit@....com,
iommu@...ts.linux-foundation.org, ddutile@...hat.com,
alex.williamson@...hat.com, linux-kernel@...r.kernel.org,
shuah.kh@...sung.com
Subject: Re: [PATCH 0/3] iommu/amd: IOMMU Error Reporting/Handling/Filtering
On Fri, Jun 21, 2013 at 10:24 AM, Joerg Roedel <joro@...tes.org> wrote:
> On Fri, Jun 21, 2013 at 05:59:33PM +0200, Borislav Petkov wrote:
>> On Fri, Jun 21, 2013 at 05:15:00PM +0200, Joerg Roedel wrote:
>> > Instead of extending this bad scaling dmesg error-reporting mechanism,
>> > I would very much like to see an integration of IOMMU error handling
>> > into the EDAC framework.
>>
>> Wouldn't just adding a tracepoint and collecting the logs in debugfs be
>> enough? This would at least avoid spamming syslog with the messages.
>
> I would rather not create another user-space interface for this which we
> then have to keep forever because someone started using it. What we need
> is a well defined mechanism to report these kernel metrics to userspace
> which can then do with it whatever it wants. I think EDAC can provide
> that interface.
>
I think it makes prefect sense to use EDAC as a common frame-work for
iommu errors as well.
Especially if and when APEI evolves to cover IOMMU tables (both Intel
VT-d and AMD) , since
EDAC is already capable of working with APEI, using EDAC will work
well on platforms that support
APEI as well as the ones that don't.
-- Shuah
Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) shuah.kh@...sung.com | (970) 672-0658
--
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