Re: [PATCH] ACPI, APEI: Add apei_exec_run_optional

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 22/03/13 11:45, Jan Beulich wrote:
>>>> On 22.03.13 at 12:27, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 22/03/13 09:14, Jan Beulich wrote:
>>>>>> On 22.03.13 at 10:07, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> All we appear to be missing in this case is Linux commit
>>>> eecf2f7124834dd1cad21807526a8ea031ba8217. I'll get that
>>>> ported over...
>>> ACPI, APEI: Add apei_exec_run_optional
>>>
>>> Some actions in APEI ERST and EINJ tables are optional, for example,
>>> ACPI_EINJ_BEGIN_OPERATION action is used to do some preparation for
>>> error injection, and firmware may choose to do nothing here.  While
>>> some other actions are mandatory, for example, firmware must provide
>>> ACPI_EINJ_GET_ERROR_TYPE implementation.
>>>
>>> Original implementation treats all actions as optional (that is, can
>>> have no instructions), that may cause issue if firmware does not
>>> provide some mandatory actions.  To fix this, this patch adds
>>> apei_exec_run_optional, which should be used for optional actions.
>>> The original apei_exec_run should be used for mandatory actions.
>>>
>>> Signed-off-by: Huang Ying <ying.huang@intel.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> (Via backport to 4.2)
>>
>> For what it is worth, with the spinlock fix, I disabled the "Intel only"
>> restriction, and so far I have been unable to find a problematic AMD box.
> So Ian, with those two fixes in, could you retry the revert of the
> Intel-only enforcement in a full ad-hoc run? If successful, that
> would then also give us reasonable assurance to backport all the
> APEI fixes to the stable branches.
>
> Thanks, Jan
>

>From the XenServer side of testing, I am running with the following
patches backported to 4.2:

25932 - ACPI: move tables.c fully into .init.*
26060 - ACPI: fix APEI related table size checking
26062 - ACPI/APEI: fix ERST MOVE_DATA instruction implementation
26736 - ACPI/APEI: Unlock apei_iomaps_lock on error path (Pre-emptivly
nabbed from staging)
And a backport of this patch

So far, no issues found.  I shall see about scheduling tests on some of
our older AMD boxes.

One minor suggestion I have is to use "ACPI:" prefixes in the error
messages.

~Andrew