Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Raphael Norwitz <raphael.norwitz@nutanix.com>
To:     Alex Williamson <alex.williamson@redhat.com>
CC:     Amey Narkhede <ameynarkhede03@gmail.com>,
        Leon Romanovsky <leon@kernel.org>,
        "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
        "bhelgaas@google.com" <bhelgaas@google.com>,
        Raphael Norwitz <raphael.norwitz@nutanix.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Alay Shah <alay.shah@nutanix.com>,
        Suresh Gumpula <suresh.gumpula@nutanix.com>,
        Shyam Rajendran <shyam.rajendran@nutanix.com>,
        Felipe Franciosi <felipe@nutanix.com>
Subject: Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device
 reset mechanism
Thread-Topic: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device
 reset mechanism
Thread-Index: AQHXF2ZMYtuGPNuUOUiLwgvTDmOeEqqELEyAgADnPYCAAAKHAIAAC6iAgAAJPgCAAAdkgIAAD7AAgAAiQQA=
Date:   Mon, 15 Mar 2021 18:32:32 +0000
Message-ID: <20210315183226.GA14801@raphael-debian-dev>
References: <20210312173452.3855-1-ameynarkhede03@gmail.com>
 <20210312173452.3855-5-ameynarkhede03@gmail.com>
 <20210314235545.girtrazsdxtrqo2q@pali>
 <20210315134323.llz2o7yhezwgealp@archlinux>
 <20210315135226.avwmnhkfsgof6ihw@pali>
 <20210315083409.08b1359b@x1.home.shazbot.org> <YE94InPHLWmOaH/b@unreal>
 <20210315153341.miip637z35mwv7fv@archlinux>
 <20210315102950.230de1d6@x1.home.shazbot.org>
In-Reply-To: <20210315102950.230de1d6@x1.home.shazbot.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mutt/1.10.1 (2018-07-13)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2AE6A70E8C58EE4AB152A17B003ABFFB@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fdf43914-8441-47ba-2c6d-08d8e7e0b2ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2021 18:32:32.8641
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bb047546-786f-4de1-bd75-24e5b6f79043
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: A7hHqTL8aWASzurxqGe+3t4qcTxdkdHok4IBO9MSavb8KevM6F+825neX1Z/CO6Eo4PTk3E0EtWPqRkeohVZPkW7StsPV46fTo+mFi+5Zhc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB4111
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369,18.0.761
 definitions=2021-03-15_11:2021-03-15,2021-03-15 signatures=0
X-Proofpoint-Spam-Reason: safe
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 15, 2021 at 10:29:50AM -0600, Alex Williamson wrote:
> On Mon, 15 Mar 2021 21:03:41 +0530
> Amey Narkhede <ameynarkhede03@gmail.com> wrote:
>=20
> > On 21/03/15 05:07PM, Leon Romanovsky wrote:
> > > On Mon, Mar 15, 2021 at 08:34:09AM -0600, Alex Williamson wrote: =20
> > > > On Mon, 15 Mar 2021 14:52:26 +0100
> > > > Pali Roh=E1r <pali@kernel.org> wrote:
> > > > =20
> > > > > On Monday 15 March 2021 19:13:23 Amey Narkhede wrote: =20
> > > > > > slot reset (pci_dev_reset_slot_function) and secondary bus
> > > > > > reset(pci_parent_bus_reset) which I think are hot reset and
> > > > > > warm reset respectively. =20
> > > > >
> > > > > No. PCI secondary bus reset =3D PCIe Hot Reset. Slot reset is jus=
t another
> > > > > type of reset, which is currently implemented only for PCIe hot p=
lug
> > > > > bridges and for PowerPC PowerNV platform and it just call PCI sec=
ondary
> > > > > bus reset with some other hook. PCIe Warm Reset does not have API=
 in
> > > > > kernel and therefore drivers do not export this type of reset via=
 any
> > > > > kernel function (yet). =20
> > > >
> > > > Warm reset is beyond the scope of this series, but could be impleme=
nted
> > > > in a compatible way to fit within the pci_reset_fn_methods[] array
> > > > defined here.  Note that with this series the resets available thro=
ugh
> > > > pci_reset_function() and the per device reset attribute is sysfs re=
main
> > > > exactly the same as they are currently.  The bus and slot reset
> > > > methods used here are limited to devices where only a single functi=
on is
> > > > affected by the reset, therefore it is not like the patch you propo=
sed
> > > > which performed a reset irrespective of the downstream devices.  Th=
is
> > > > series only enables selection of the existing methods.  Thanks, =20
> > >
> > > Alex,
> > >
> > > I asked the patch author here [1], but didn't get any response, maybe
> > > you can answer me. What is the use case scenario for this functionali=
ty?
> > >
> > > Thanks
> > >
> > > [1] https://lore.kernel.org/lkml/YE389lAqjJSeTolM@unreal/=20
> > > =20
> > Sorry for not responding immediately. There were some buggy wifi cards
> > which needed FLR explicitly not sure if that behavior is fixed in
> > drivers. Also there is use a case at Nutanix but the engineer who
> > is involved is on PTO that is why I did not respond immediately as
> > I don't know the details yet.
>=20
> And more generally, devices continue to have reset issues and we
> impose a fixed priority in our ordering.  We can and probably should
> continue to quirk devices when we find broken resets so that we have
> the best default behavior, but it's currently not easy for an end user
> to experiment, ie. this reset works, that one doesn't.  We might also
> have platform issues where a given reset works better on a certain
> platform.  Exposing a way to test these things might lead to better
> quirks.  In the case I think Pali was looking for, they wanted a
> mechanism to force a bus reset, if this was in reference to a single
> function device, this could be accomplished by setting a priority for
> that mechanism, which would translate to not only the sysfs reset
> attribute, but also the reset mechanism used by vfio-pci.  Thanks,
>=20
> Alex
>

To confirm from our end - we have seen many such instances where default
reset methods have not worked well on our platform. Debugging these
issues is painful in practice, and this interface would make it far
easier.

Having an interface like this would also help us better communicate the
issues we find with upstream. Allowing others to more easily test our
(or other entities') findings should give better visibility into
which issues apply to the device in general and which are platform
specific. In disambiguating the former from the latter, we should be
able to better quirk devices for everyone, and in the latter cases, this
interface allows for a safer and more elegant solution than any of the
current alternatives.

CC Alay, Suresh, Shyam and Felipe in case they have anything to add.