linux-kernel - Re: RFC: APEI hardware reduced profile

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Mar 2014 12:10:47 -0300
From:	Mauro Carvalho Chehab <m.chehab@...sung.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Tomasz Nowicki <tomasz.nowicki@...aro.org>,
	Len Brown <lenb@...nel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linaro-acpi <linaro-acpi@...ts.linaro.org>,
	Tony <tony.luck@...el.com>, Borislav Petkov <bp@...en8.de>,
	Borislav Petkov <bp@...e.de>, linux-edac@...r.kernel.org,
	x86@...nel.org
Subject: Re: RFC: APEI hardware reduced profile

Em Wed, 26 Mar 2014 15:55:07 +0100
"Rafael J. Wysocki" <rjw@...ysocki.net> escreveu:

> On Wednesday, March 26, 2014 01:08:10 PM Tomasz Nowicki wrote:
> > Hi,
> 
> Hi,
> 
> This is a question for Tony, Boris and Mauro (CCed now).
> 
> > Currently APEI depends on x86 architecture. It is because of many x86 
> > specific features like "IA-32 Architecture Corrected Machine Check
> > " error source or NMI hardware error notification. However, many other 
> > features like "PCI Express Device AER Structure" or GHES via external 
> > interrupt can be still used perfectly by other architectures. So my idea 
> > is to move x86 dependency away form Kconfig to APEI areas where it 
> > really applies to.
> > 
> > I have started refactoring ghes.c driver in that direction. And here 
> > comes my confusion, how should we treat x86 related parts, as fixed 
> > profile? (which means we could use ACPI_REDUCED_HARDWARE or 
> > CONFIG_ACPI_REDUCED_HARDWARE_ONLY define). I would like to ask for your 
> > opinion.

That's a good question, and probably depends on how are you mapping the
ACPI changes. For example, are you moving acpi out of /arch?

As I answered to a similar questioning, IMHO, the better would be to 
have the hardware error report mechanisms on /drivers/ras, and have 
there some Kconfig items that would depend on X86 to enable certain
drivers.

Also, I don't like to have something like ACPI_REDUCED_foo. IMHO, the
better would be to do the reverse: to have Kconfig symbols enabling the
extra X86-specific functionality, and have them mapped into separate
files/drivers, with proper KConfig names, like ACPI_X86 or ACPI_X86_NMI.

Yet, it would be better if you could be a little more specific about
what are your plans and what are the common/not-common features that
you're mapping.

Regards,
Mauro
--
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/