From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkBzk-0008Fh-C5 for qemu-devel@nongnu.org; Mon, 20 Apr 2015 09:44:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkBzg-0006t9-As for qemu-devel@nongnu.org; Mon, 20 Apr 2015 09:44:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkBzg-0006ru-3E for qemu-devel@nongnu.org; Mon, 20 Apr 2015 09:44:12 -0400 Date: Mon, 20 Apr 2015 15:43:58 +0200 From: "Michael S. Tsirkin" Message-ID: <20150420153915-mutt-send-email-mst@redhat.com> References: <551BBD38.60204@citrix.com> <20150401115032-mutt-send-email-mst@redhat.com> <552B97A00200007800071558@mail.emea.novell.com> <20150413125101-mutt-send-email-mst@redhat.com> <552BC5EA02000078000716E7@mail.emea.novell.com> <20150413133843-mutt-send-email-mst@redhat.com> <552BD57B0200007800071763@mail.emea.novell.com> <20150413144223-mutt-send-email-mst@redhat.com> <552BD7DA0200007800071783@mail.emea.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552BD7DA0200007800071783@mail.emea.novell.com> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xensource.com, pmatouse@redhat.com, qemu-devel@nongnu.org, Stefano Stabellini On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: > >>> On 13.04.15 at 14:47, wrote: > > On Mon, Apr 13, 2015 at 01:40:59PM +0100, Jan Beulich wrote: > >> Quite possible. Looking at the ITP log we were provided, the UR > >> severity bit is clear (non-fatal), yet the error got surfaced to the > >> OS as a fatal one (I would guess because it validly gets flagged as > >> uncorrectable at the same time). > > > > No, that's not valid. > > Can you check device capabilities register, offset 0x4 within > > pci express capability structure? > > Bit 15 is 15 Role-Based Error Reporting. > > Is it set? > > > > The spec says: > > > > 15 > > On platforms where robust error handling and PC-compatible Configuration > > Space probing is > > required, it is suggested that software or firmware have the Unsupported > > Request Reporting Enable > > bit Set for Role-Based Error Reporting Functions, but clear for 1.0a > > Functions. Software or > > firmware can distinguish the two classes of Functions by examining the > > Role-Based Error Reporting > > bit in the Device Capabilities register. > > Yes, that bit is set. > > Jan curiouser and curiouser. So with functions that do support Role-Based Error Reporting, we have this: With device Functions implementing Role-Based Error Reporting, setting the Unsupported Request Reporting Enable bit will not interfere with PC-compatible Configuration Space probing, assuming that the severity for UR is left at its default of non-fatal. However, setting the Unsupported Request Reporting Enable bit will enable the Function to report UR errors 97 detected with posted Requests, helping avoid this case for potential silent data corruption. did firmware reconfigure this device to report URs as fatal errors then? From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register Date: Mon, 20 Apr 2015 15:43:58 +0200 Message-ID: <20150420153915-mutt-send-email-mst@redhat.com> References: <551BBD38.60204@citrix.com> <20150401115032-mutt-send-email-mst@redhat.com> <552B97A00200007800071558@mail.emea.novell.com> <20150413125101-mutt-send-email-mst@redhat.com> <552BC5EA02000078000716E7@mail.emea.novell.com> <20150413133843-mutt-send-email-mst@redhat.com> <552BD57B0200007800071763@mail.emea.novell.com> <20150413144223-mutt-send-email-mst@redhat.com> <552BD7DA0200007800071783@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <552BD7DA0200007800071783@mail.emea.novell.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xensource.com, pmatouse@redhat.com, qemu-devel@nongnu.org, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: > >>> On 13.04.15 at 14:47, wrote: > > On Mon, Apr 13, 2015 at 01:40:59PM +0100, Jan Beulich wrote: > >> Quite possible. Looking at the ITP log we were provided, the UR > >> severity bit is clear (non-fatal), yet the error got surfaced to the > >> OS as a fatal one (I would guess because it validly gets flagged as > >> uncorrectable at the same time). > > > > No, that's not valid. > > Can you check device capabilities register, offset 0x4 within > > pci express capability structure? > > Bit 15 is 15 Role-Based Error Reporting. > > Is it set? > > > > The spec says: > > > > 15 > > On platforms where robust error handling and PC-compatible Configuration > > Space probing is > > required, it is suggested that software or firmware have the Unsupported > > Request Reporting Enable > > bit Set for Role-Based Error Reporting Functions, but clear for 1.0a > > Functions. Software or > > firmware can distinguish the two classes of Functions by examining the > > Role-Based Error Reporting > > bit in the Device Capabilities register. > > Yes, that bit is set. > > Jan curiouser and curiouser. So with functions that do support Role-Based Error Reporting, we have this: With device Functions implementing Role-Based Error Reporting, setting the Unsupported Request Reporting Enable bit will not interfere with PC-compatible Configuration Space probing, assuming that the severity for UR is left at its default of non-fatal. However, setting the Unsupported Request Reporting Enable bit will enable the Function to report UR errors 97 detected with posted Requests, helping avoid this case for potential silent data corruption. did firmware reconfigure this device to report URs as fatal errors then?