On Wed, Jun 10, 2015 at 01:06:27PM +0100, Jan Beulich wrote:
> >>> On 10.06.15 at 13:43, wrote:
> > On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote:
> >> >>> On 08.06.15 at 13:28, wrote:
> >> > On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
> >> >> while function 0 has
>
>>> On 10.06.15 at 13:46, wrote:
> I don't really know. The idea would be that device
> is not designed for memory to be disabled when it's
> active, and starts behaving in broken ways.
But you recall that we know the origin of the offending write is in
the hypervisor, and we also know that the d
>>> On 10.06.15 at 13:43, wrote:
> On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote:
>> >>> On 08.06.15 at 13:28, wrote:
>> > On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
>> >> while function 0 has
>> >>
>> >> 0x10: Base Address Register 0 = 0xca23000c (Memory space,
On Wed, Jun 10, 2015 at 08:08:37AM +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 11:30, wrote:
> > What happens if you disable SERR# in the command register
> > of 83:00.1?
>
> We've just been told that with SERR not enabled in any of the
> sibling endpoints the NMI still occurs. Not really surp
On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 13:28, wrote:
> > On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
> >> while function 0 has
> >>
> >> 0x10: Base Address Register 0 = 0xca23000c (Memory space, 64-bit access,
> >> prefetchable)
> >> 0
>>> On 08.06.15 at 11:30, wrote:
> What happens if you disable SERR# in the command register
> of 83:00.1?
We've just been told that with SERR not enabled in any of the
sibling endpoints the NMI still occurs. Not really surprising with
us now assuming that it's the root port that generates the SE
>>> On 08.06.15 at 13:28, wrote:
> On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
>> while function 0 has
>>
>> 0x10: Base Address Register 0 = 0xca23000c (Memory space, 64-bit access,
>> prefetchable)
>> 0x18: Base Address Register 2 = 0xca24000c (Memory space, 64-bit access,
>
>>> On 08.06.15 at 13:28, wrote:
> On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
>> But you asking this made me look more closely at the
>> memory ranges dumped out to the ITP log: The root port has
>>
>> 0x20: Memory Base = 0xca40
>> 0x22: Memory Limit = 0
On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 11:36, wrote:
> > On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote:
> >> >>> On 08.06.15 at 10:09, wrote:
> >> > I believe the correct behaviour is happening but a PCIE completion
> >> > timeout
> >> >
>>> On 08.06.15 at 11:36, wrote:
> On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote:
>> >>> On 08.06.15 at 10:09, wrote:
>> > I believe the correct behaviour is happening but a PCIE completion timeout
>> > is occurring instead of a
>> > unsupported request.
>>
>> Might it be that wit
>>> On 08.06.15 at 11:30, wrote:
> On Mon, Jun 08, 2015 at 08:42:57AM +0100, Jan Beulich wrote:
>> 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. t
On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote:
> >>> On 08.06.15 at 10:09, wrote:
> > On 08/06/15 08:42, Jan Beulich wrote:
> >> 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. Ot
On Mon, Jun 08, 2015 at 08:42:57AM +0100, Jan Beulich wrote:
> >>> On 07.06.15 at 08:23, 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, wrote:
> >> > > On Mon, Apr 13
>>> On 08.06.15 at 10:09, wrote:
> On 08/06/15 08:42, Jan Beulich wrote:
>> 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. Otoh the respective root port also has
>> - Received Master Abort set in
On Mon, Jun 08, 2015 at 09:09:15AM +0100, Malcolm Crossley wrote:
> On 08/06/15 08:42, Jan Beulich wrote:
> On 07.06.15 at 08:23, 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.
On 08/06/15 08:42, Jan Beulich wrote:
On 07.06.15 at 08:23, 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, wrote:
> On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan
>>> On 07.06.15 at 08:23, 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, wrote:
>> > > On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan Beulich wrote:
>> > >> >>> On 13.04.15
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
>>> On 20.04.15 at 16:32, wrote:
> On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote:
>> >>> On 20.04.15 at 15:43, wrote:
>> > 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 co
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
>>> 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 se
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 t
>>> 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 fla
On Mon, Apr 13, 2015 at 01:40:59PM +0100, Jan Beulich wrote:
> >>> On 13.04.15 at 13:47, wrote:
> > On Mon, Apr 13, 2015 at 12:34:34PM +0100, Jan Beulich wrote:
> >> >>> On 13.04.15 at 13:19, wrote:
> >> > Yes Linux can't fix firmware 1st mode, but
> >> > PCI express spec says what firmware shoul
>>> On 13.04.15 at 13:47, wrote:
> On Mon, Apr 13, 2015 at 12:34:34PM +0100, Jan Beulich wrote:
>> >>> On 13.04.15 at 13:19, wrote:
>> > Yes Linux can't fix firmware 1st mode, but
>> > PCI express spec says what firmware should do in this case:
>> >
>> > IMPLEMENTATION NOTE Software UR Reporting
On Mon, Apr 13, 2015 at 12:34:34PM +0100, Jan Beulich wrote:
> >>> On 13.04.15 at 13:19, wrote:
> > Yes Linux can't fix firmware 1st mode, but
> > PCI express spec says what firmware should do in this case:
> >
> > IMPLEMENTATION NOTE Software UR Reporting Compatibility with 1.0a Devices
> >
> >
>>> On 13.04.15 at 13:19, wrote:
> Yes Linux can't fix firmware 1st mode, but
> PCI express spec says what firmware should do in this case:
>
> IMPLEMENTATION NOTE Software UR Reporting Compatibility with 1.0a Devices
>
> With 1.0a device Functions, 96 if the Unsupported Request Reportin
On Mon, Apr 13, 2015 at 09:17:04AM +0100, Jan Beulich wrote:
> >>> On 01.04.15 at 11:59, wrote:
> > On Wed, Apr 01, 2015 at 10:41:12AM +0100, Andrew Cooper wrote:
> >> On 01/04/15 10:20, Stefano Stabellini wrote:
> >> > CC'ing the author of the patch and xen-devel.
> >> > FYI I think that Jan is g
>>> On 01.04.15 at 11:59, wrote:
> On Wed, Apr 01, 2015 at 10:41:12AM +0100, Andrew Cooper wrote:
>> On 01/04/15 10:20, Stefano Stabellini wrote:
>> > CC'ing the author of the patch and xen-devel.
>> > FYI I think that Jan is going to be on vacation for a couple of weeks.
>> >
>> > On Wed, 1 Apr 2
On Wed, Apr 01, 2015 at 10:50:45AM +0100, Ian Campbell wrote:
> On Wed, 2015-04-01 at 10:20 +0100, Stefano Stabellini wrote:
> > CC'ing the author of the patch and xen-devel.
>
> Adding Andy C who I think knows about this stuff.
>
> > FYI I think that Jan is going to be on vacation for a couple o
On Wed, Apr 01, 2015 at 10:41:12AM +0100, Andrew Cooper wrote:
> On 01/04/15 10:20, Stefano Stabellini wrote:
> > CC'ing the author of the patch and xen-devel.
> > FYI I think that Jan is going to be on vacation for a couple of weeks.
> >
> > On Wed, 1 Apr 2015, Michael S. Tsirkin wrote:
> >> On Tu
On Wed, 2015-04-01 at 10:20 +0100, Stefano Stabellini wrote:
> CC'ing the author of the patch and xen-devel.
Adding Andy C who I think knows about this stuff.
> FYI I think that Jan is going to be on vacation for a couple of weeks.
>
> On Wed, 1 Apr 2015, Michael S. Tsirkin wrote:
> > On Tue, Ma
On 01/04/15 10:20, Stefano Stabellini wrote:
> CC'ing the author of the patch and xen-devel.
> FYI I think that Jan is going to be on vacation for a couple of weeks.
>
> On Wed, 1 Apr 2015, Michael S. Tsirkin wrote:
>> On Tue, Mar 31, 2015 at 03:18:03PM +0100, Stefano Stabellini wrote:
>>> From: Ja
On Wed, Apr 01, 2015 at 10:20:06AM +0100, Stefano Stabellini wrote:
> CC'ing the author of the patch and xen-devel.
> FYI I think that Jan is going to be on vacation for a couple of weeks.
>
> On Wed, 1 Apr 2015, Michael S. Tsirkin wrote:
> > On Tue, Mar 31, 2015 at 03:18:03PM +0100, Stefano Stabe
CC'ing the author of the patch and xen-devel.
FYI I think that Jan is going to be on vacation for a couple of weeks.
On Wed, 1 Apr 2015, Michael S. Tsirkin wrote:
> On Tue, Mar 31, 2015 at 03:18:03PM +0100, Stefano Stabellini wrote:
> > From: Jan Beulich
> >
> > Otherwise the guest can abuse tha
35 matches
Mail list logo
