From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] ACPI, APEI: Add apei_exec_run_optional Date: Fri, 22 Mar 2013 11:54:43 +0000 Message-ID: <514C4683.7050803@citrix.com> References: <514B961E.8010202@citrix.com> <514C2D4E02000078000C7AF2@nat28.tlf.novell.com> <514C2F0502000078000C7AFD@nat28.tlf.novell.com> <514C4036.2090809@citrix.com> <514C525802000078000C7B5C@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <514C525802000078000C7B5C@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: "Keir (Xen.org)" , Ian Jackson , Xen-devel List List-Id: xen-devel@lists.xenproject.org On 22/03/13 11:45, Jan Beulich wrote: >>>> On 22.03.13 at 12:27, Andrew Cooper wrote: >> On 22/03/13 09:14, Jan Beulich wrote: >>>>>> On 22.03.13 at 10:07, "Jan Beulich" 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 >>> Signed-off-by: Jan Beulich >> Tested-by: Andrew Cooper >> >> (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