From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1U02-0008S2-1F for qemu-devel@nongnu.org; Sun, 07 Jun 2015 02:24:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1Tzy-0001Md-PO for qemu-devel@nongnu.org; Sun, 07 Jun 2015 02:24:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1Tzy-0001Ls-Kh for qemu-devel@nongnu.org; Sun, 07 Jun 2015 02:23:58 -0400 Date: Sun, 7 Jun 2015 08:23:53 +0200 From: "Michael S. Tsirkin" Message-ID: <20150607082252-mutt-send-email-mst@redhat.com> References: <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> <20150420162712-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420162712-mutt-send-email-mst@redhat.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 04:32:12PM +0200, Michael S. Tsirkin wrote: > 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? Ping - any update on this? Do we can chalk this up to hardware bugs on a specific box? > -- > MST