RFC: APEI hardware reduced profile

RFC: APEI hardware reduced profile

[Tomasz Nowicki]

Hi,

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.

Regards,
Tomasz

Re: RFC: APEI hardware reduced profile

[Rafael J. Wysocki]

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.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: RFC: APEI hardware reduced profile

[Mauro Carvalho Chehab]

Em Wed, 26 Mar 2014 15:55:07 +0100
"Rafael J. Wysocki" <rjw@rjwysocki.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

Re: RFC: APEI hardware reduced profile

[Borislav Petkov]

On Wed, Mar 26, 2014 at 12:10:47PM -0300, Mauro Carvalho Chehab wrote:
> 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.

Well, I don't see anything x86-specific in ghes.c on a quick scan - just
the GHES gunk itself, which is the spec. Which begs the question, how
much of the APEI spec is ARM going to implement and if it is a subset,
this definitely needs to be handled cleanly. Judging by your text, it
seems like you want to ignore the correctable errors part...?

So yes, Tomasz, you want to be much more specific here :-)

Thanks.

Re: RFC: APEI hardware reduced profile

[Tomasz Nowicki]

On 03/26/14 21:36, Borislav Petkov wrote:
> On Wed, Mar 26, 2014 at 12:10:47PM -0300, Mauro Carvalho Chehab wrote:
>> 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.
>
> Well, I don't see anything x86-specific in ghes.c on a quick scan - just
> the GHES gunk itself, which is the spec. Which begs the question, how
> much of the APEI spec is ARM going to implement and if it is a subset,
> this definitely needs to be handled cleanly. Judging by your text, it
> seems like you want to ignore the correctable errors part...?
>
> So yes, Tomasz, you want to be much more specific here :-)

Thanks for your comment. Please refer to my email to Mauro. I have put 
more explanation there.

Correctable errors are fine for ARM. But ARM is not going to have NMI 
ever. So as responded to Mauro, I am focusing on making NMI as the 
feature for ghes.c.

Thanks,
Tomasz

Re: RFC: APEI hardware reduced profile

[Tomasz Nowicki]

On 03/26/14 16:10, Mauro Carvalho Chehab wrote:
> Em Wed, 26 Mar 2014 15:55:07 +0100
> "Rafael J. Wysocki" <rjw@rjwysocki.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.

Yes and sorry, I should have been more specific here.

After scanning APEI code it seems like NMI notification of GHES implies 
APEI x86 dependency for Kconfig, so I am targeting ghes.c.

I agree that ACPI_REDUCED_foo is not suitable for that purpose. However, 
ACPI_X86_NMI sounds good to me. I also have been thinking of moving NMI 
code (from ghes.c) to separate file but NMI and IRQ context are tightly 
coupled. That convinced me to leave it in ghes.c for now but I need to 
look at it closer.

Thanks,
Tomasz