[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control o
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register |
Date: |
Mon, 8 Jun 2015 11:30:10 +0200 |
On Mon, Jun 08, 2015 at 08:42:57AM +0100, Jan Beulich wrote:
> >>> On 07.06.15 at 08:23, <address@hidden> wrote:
> > 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, <address@hidden> wrote:
> >> > > On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote:
> >> > >> >>> On 13.04.15 at 14:47, <address@hidden> 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.
> >>
> >> OK, that's the correct configuration, so how come the box crashes when
> >> there's a UR then?
> >
> > Ping - any update on this?
>
> Not really. All we concluded so far is that _maybe_ the bridge, upon
> seeing the UR, generates a Master Abort, rendering the whole thing
> fatal.
But Master Abort is the equivalent of the UR, so I think that a
reasonable system would not be configured to trigger a fatal error
in this case - and you previously said it's configured reasonably.
> Otoh the respective root port also has
> - Received Master Abort set in its Secondary Status register (but
> that's also already the case in the log that we have before the UR
> occurs, i.e. that doesn't mean all that much),
> - Received System Error set in its Secondary Status register (and
> after the UR the sibling endpoint [UR originating from 83:00.0,
> sibling being 83:00.1] also shows Signaled System Error set).
It's another function of the same physical device, correct?
So is this sibling the only function sending SERR?
What happens if you disable SERR# in the command register
of 83:00.1?
> > Do we can chalk this up to hardware bugs on a specific box?
>
> I have to admit that I'm still very uncertain whether to consider all
> this correct behavior, a firmware flaw, or a hardware bug.
>
> Jan
Questions:
1. Does this only happen with a specific endpoint?
What if you add another endpoint to the same system?
2. Has a driver initialized this endpoint? What if you don't
load a driver before sending the transaction resulting in the UR?
--
MST
- Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register, Michael S. Tsirkin, 2015/06/07
- Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register, Malcolm Crossley, 2015/06/08
- Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register, Michael S. Tsirkin, 2015/06/08
- Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register, Jan Beulich, 2015/06/08
- Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register, Michael S. Tsirkin, 2015/06/08
- Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register, Jan Beulich, 2015/06/08
- Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register, Michael S. Tsirkin, 2015/06/08