From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCkI-0000Fv-1R for qemu-devel@nongnu.org; Mon, 20 Apr 2015 10:32:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkCkC-0007Jl-KK for qemu-devel@nongnu.org; Mon, 20 Apr 2015 10:32:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCkC-0007Jf-GO for qemu-devel@nongnu.org; Mon, 20 Apr 2015 10:32:16 -0400 Date: Mon, 20 Apr 2015 16:32:12 +0200 From: "Michael S. Tsirkin" Message-ID: <20150420162712-mutt-send-email-mst@redhat.com> References: <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> <20150420153915-mutt-send-email-mst@redhat.com> <553524690200007800073D57@mail.emea.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <553524690200007800073D57@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 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote: > >>> On 20.04.15 at 15:43, wrote: > > On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote: > >> >>> On 13.04.15 at 14:47, wrote: > >> > 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. > > > > 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. > > I still don't see what the PC-compatible config space probing has to > do with our issue. I'm not sure but I think it's listed here because it causes a ton of URs when device scan probes unimplemented functions. > > did firmware reconfigure this device to report URs as fatal errors then? > > No, the Unsupported Request Error Serverity flag is zero. > > Jan OK, that's the correct configuration, so how come the box crashes when there's a UR then? -- MST