From mboxrd@z Thu Jan 1 00:00:00 1970 From: Malcolm Crossley Subject: Re: [PATCH v2 RFC] VT-d: honor firmware-first mode in XSA-59 workaround code Date: Tue, 3 Jun 2014 15:38:56 +0100 Message-ID: <538DDE00.8030500@citrix.com> References: <537CEBD20200007800014A29@mail.emea.novell.com> <538331390200007800015B4F@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wrprj-0004j2-Cs for xen-devel@lists.xenproject.org; Tue, 03 Jun 2014 14:39:03 +0000 In-Reply-To: <538331390200007800015B4F@mail.emea.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 , Andrew Cooper Cc: Yang Z Zhang , xen-devel , Kevin Tian , Donald D Dugger List-Id: xen-devel@lists.xenproject.org On 26/05/14 11:19, Jan Beulich wrote: > When firmware-first mode is being indicated by firmware, we shouldn't > be modifying AER registers - these are considered to be owned by > firmware in that case. Violating this is being reported to result in > SMI storms. While circumventing the workaround means re-exposing > affected hosts to the XSA-59 issues, this in any event seems better > than not booting at all. Respective messages are being issued to the > log, so the situation can be diagnosed. > > The basic building blocks were taken from Linux 3.15-rc. Note that > this includes a block of code enclosed in #ifdef CONFIG_X86_MCE - we > don't define that symbol, and that code also wouldn't build without > suitable machine check side code added; that should happen eventually, > but isn't subject of this change. > > Reported-by: Andrew Cooper > Reported-by: Malcolm Crossley > Signed-off-by: Jan Beulich Tested-by: Malcolm Crossley > --- > v2: Only check firmware-first for actual AER (i.e. ignore it for host > bridges in DMI mode). Use MASK_EXTR() instead of open coding it. > Re-word message from "cannot" to "must not". I tested this patch on an Dell R810 BIOS version 2.7.4, it successfully detected the firmware first mode and did not mask device 0000:00:00.0. The other root ports already had the relevant AER errors masked. (XEN) Must not mask UR signaling on 0000:00:00.0 (XEN) PCI add device 0000:00:00.0 (XEN) Found masked UR signaling on 0000:00:01.0 (XEN) PCI add device 0000:00:01.0 (XEN) Found masked UR signaling on 0000:00:02.0 (XEN) PCI add device 0000:00:02.0 (XEN) Found masked UR signaling on 0000:00:03.0 (XEN) PCI add device 0000:00:03.0 (XEN) Found masked UR signaling on 0000:00:05.0 (XEN) PCI add device 0000:00:05.0 (XEN) Found masked UR signaling on 0000:00:07.0 (XEN) PCI add device 0000:00:07.0 (XEN) Found masked UR signaling on 0000:00:09.0 (XEN) PCI add device 0000:00:09.0 (XEN) Masked VT-d error signaling on 0000:00:14.0 lspci -n output for Dell R810: 00:00.0 0600: 8086:3407 (rev 22) 00:01.0 0604: 8086:3408 (rev 22) 00:02.0 0604: 8086:3409 (rev 22) 00:03.0 0604: 8086:340a (rev 22) 00:05.0 0604: 8086:340c (rev 22) 00:07.0 0604: 8086:340e (rev 22) 00:09.0 0604: 8086:3410 (rev 22) 00:14.0 0800: 8086:342e (rev 22) 00:14.1 0800: 8086:3422 (rev 22) 00:14.2 0800: 8086:3423 (rev 22)