From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, david.daney@cavium.com,
linux-pci@vger.kernel.org,
Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>,
linux-kernel@vger.kernel.org,
Robert Richter <robert.richter@cavium.com>,
Jon Masters <jcm@redhat.com>, Bjorn Helgaas <bhelgaas@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [v4,0/3] Workaround for bus/slot reset on Cavium cn8xxx root ports
Date: Thu, 21 Sep 2017 10:06:59 +0200 [thread overview]
Message-ID: <20170921080659.GA12818@hc> (raw)
In-Reply-To: <20170920120912.7544420d@t450s.home>
On Wed, Sep 20, 2017 at 12:09:12PM -0600, Alex Williamson wrote:
> On Tue, 12 Sep 2017 02:40:49 -0700
> Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com> wrote:
>
> > Hi all,
> >
> > Are there any updates on this ?
> > Comments/objections/acks/nacks ?
> >
> > WBBR,
> > Vadim
> >
> > On Fri, Sep 08, 2017 at 10:10:30AM +0200, Jan Glauber wrote:
> > > Using vfio-pci on a combination of cn8xxx and some PCI devices results in
> > > a kernel panic. This is triggered by issuing a bus or a slot reset
> > > on the PCI device.
> > >
> > > With this series both checks indicate that the reset is not possible
> > > preventing the kernel panic.
> > >
> > > David Daney (2):
> > > PCI: Allow PCI_DEV_FLAGS_NO_BUS_RESET to be used on bus device
> > > PCI: Avoid bus reset for Cavium cn8xxx root ports
> > >
> > > Jan Glauber (1):
> > > PCI: Avoid slot reset if bus reset is not possible
> > >
> > > drivers/pci/pci.c | 8 ++++++++
> > > drivers/pci/quirks.c | 8 ++++++++
> > > 2 files changed, 16 insertions(+)
>
>
> Looks ok to me, for series:
>
> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Thanks for the review. And also for being patient with my iterations.
> I am curious why we're happy targeting this quirk at a single device ID
> while at the same time trying to expand the ACS quirk to a notable
> fraction of the Cavium PCI device ID address space. Thanks,
David, please correct me if I'm wrong but I think this problem only
exists on cn88xx (device id 0xa100) but not on cn81xx/cn83xx (0xa200,
0xa300). I've seen the bridge causing the problem only on cn88xx.
--Jan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: jan.glauber@caviumnetworks.com (Jan Glauber)
To: linux-arm-kernel@lists.infradead.org
Subject: [v4,0/3] Workaround for bus/slot reset on Cavium cn8xxx root ports
Date: Thu, 21 Sep 2017 10:06:59 +0200 [thread overview]
Message-ID: <20170921080659.GA12818@hc> (raw)
In-Reply-To: <20170920120912.7544420d@t450s.home>
On Wed, Sep 20, 2017 at 12:09:12PM -0600, Alex Williamson wrote:
> On Tue, 12 Sep 2017 02:40:49 -0700
> Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com> wrote:
>
> > Hi all,
> >
> > Are there any updates on this ?
> > Comments/objections/acks/nacks ?
> >
> > WBBR,
> > Vadim
> >
> > On Fri, Sep 08, 2017 at 10:10:30AM +0200, Jan Glauber wrote:
> > > Using vfio-pci on a combination of cn8xxx and some PCI devices results in
> > > a kernel panic. This is triggered by issuing a bus or a slot reset
> > > on the PCI device.
> > >
> > > With this series both checks indicate that the reset is not possible
> > > preventing the kernel panic.
> > >
> > > David Daney (2):
> > > PCI: Allow PCI_DEV_FLAGS_NO_BUS_RESET to be used on bus device
> > > PCI: Avoid bus reset for Cavium cn8xxx root ports
> > >
> > > Jan Glauber (1):
> > > PCI: Avoid slot reset if bus reset is not possible
> > >
> > > drivers/pci/pci.c | 8 ++++++++
> > > drivers/pci/quirks.c | 8 ++++++++
> > > 2 files changed, 16 insertions(+)
>
>
> Looks ok to me, for series:
>
> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Thanks for the review. And also for being patient with my iterations.
> I am curious why we're happy targeting this quirk at a single device ID
> while at the same time trying to expand the ACS quirk to a notable
> fraction of the Cavium PCI device ID address space. Thanks,
David, please correct me if I'm wrong but I think this problem only
exists on cn88xx (device id 0xa100) but not on cn81xx/cn83xx (0xa200,
0xa300). I've seen the bridge causing the problem only on cn88xx.
--Jan
WARNING: multiple messages have this Message-ID (diff)
From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>,
Bjorn Helgaas <bhelgaas@google.com>,
kvm@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, Jon Masters <jcm@redhat.com>,
linux-arm-kernel@lists.infradead.org, david.daney@cavium.com,
Robert Richter <robert.richter@cavium.com>
Subject: Re: [v4,0/3] Workaround for bus/slot reset on Cavium cn8xxx root ports
Date: Thu, 21 Sep 2017 10:06:59 +0200 [thread overview]
Message-ID: <20170921080659.GA12818@hc> (raw)
In-Reply-To: <20170920120912.7544420d@t450s.home>
On Wed, Sep 20, 2017 at 12:09:12PM -0600, Alex Williamson wrote:
> On Tue, 12 Sep 2017 02:40:49 -0700
> Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com> wrote:
>
> > Hi all,
> >
> > Are there any updates on this ?
> > Comments/objections/acks/nacks ?
> >
> > WBBR,
> > Vadim
> >
> > On Fri, Sep 08, 2017 at 10:10:30AM +0200, Jan Glauber wrote:
> > > Using vfio-pci on a combination of cn8xxx and some PCI devices results in
> > > a kernel panic. This is triggered by issuing a bus or a slot reset
> > > on the PCI device.
> > >
> > > With this series both checks indicate that the reset is not possible
> > > preventing the kernel panic.
> > >
> > > David Daney (2):
> > > PCI: Allow PCI_DEV_FLAGS_NO_BUS_RESET to be used on bus device
> > > PCI: Avoid bus reset for Cavium cn8xxx root ports
> > >
> > > Jan Glauber (1):
> > > PCI: Avoid slot reset if bus reset is not possible
> > >
> > > drivers/pci/pci.c | 8 ++++++++
> > > drivers/pci/quirks.c | 8 ++++++++
> > > 2 files changed, 16 insertions(+)
>
>
> Looks ok to me, for series:
>
> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Thanks for the review. And also for being patient with my iterations.
> I am curious why we're happy targeting this quirk at a single device ID
> while at the same time trying to expand the ACS quirk to a notable
> fraction of the Cavium PCI device ID address space. Thanks,
David, please correct me if I'm wrong but I think this problem only
exists on cn88xx (device id 0xa100) but not on cn81xx/cn83xx (0xa200,
0xa300). I've seen the bridge causing the problem only on cn88xx.
--Jan
next prev parent reply other threads:[~2017-09-21 8:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 8:10 [PATCH v4 0/3] Workaround for bus/slot reset on Cavium cn8xxx root ports Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` [PATCH v4 1/3] PCI: Allow PCI_DEV_FLAGS_NO_BUS_RESET to be used on bus device Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` [PATCH v4 2/3] PCI: Avoid bus reset for Cavium cn8xxx root ports Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` [PATCH v4 3/3] PCI: Avoid slot reset if bus reset is not possible Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-08 8:10 ` Jan Glauber
2017-09-12 9:40 ` [v4,0/3] Workaround for bus/slot reset on Cavium cn8xxx root ports Vadim Lomovtsev
2017-09-12 9:40 ` Vadim Lomovtsev
2017-09-12 9:40 ` Vadim Lomovtsev
2017-09-20 17:50 ` Jon Masters
2017-09-20 17:50 ` Jon Masters
2017-09-20 17:50 ` Jon Masters
2017-09-20 18:09 ` Alex Williamson
2017-09-20 18:09 ` Alex Williamson
2017-09-20 18:09 ` Alex Williamson
2017-09-21 8:06 ` Jan Glauber [this message]
2017-09-21 8:06 ` Jan Glauber
2017-09-21 8:06 ` Jan Glauber
2017-09-26 12:00 ` Jan Glauber
2017-09-26 12:00 ` Jan Glauber
2017-09-26 12:00 ` Jan Glauber
2017-10-11 15:33 ` [PATCH v4 0/3] " Robert Richter
2017-10-11 15:33 ` Robert Richter
2017-10-11 15:33 ` Robert Richter
2017-10-11 18:32 ` Bjorn Helgaas
2017-10-11 18:32 ` Bjorn Helgaas
2017-10-11 18:32 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170921080659.GA12818@hc \
--to=jan.glauber@caviumnetworks.com \
--cc=Vadim.Lomovtsev@caviumnetworks.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=david.daney@cavium.com \
--cc=jcm@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=robert.richter@cavium.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.