Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote:
> >>> On 13.04.15 at 14:47, <mst@redhat.com> 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?