netdev - Re: [PATCH net-next 03/14] bnxt_en: Refactor bnxt_sriov

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 30 Aug 2019 09:00:27 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Vasundhara Volam <vasundhara-v.volam@...adcom.com>,
        Jiri Pirko <jiri@...lanox.com>, Ray Jui <ray.jui@...adcom.com>
Subject: Re: [PATCH net-next 03/14] bnxt_en: Refactor bnxt_sriov_enable().

On Fri, Aug 30, 2019 at 2:18 AM Leon Romanovsky <leon@...nel.org> wrote:
>
> On Mon, Aug 26, 2019 at 09:00:45AM +0300, Leon Romanovsky wrote:
> > On Sun, Aug 25, 2019 at 11:54:54PM -0400, Michael Chan wrote:
> > > Refactor the hardware/firmware configuration portion in
> > > bnxt_sriov_enable() into a new function bnxt_cfg_hw_sriov().  This
> > > new function can be called after a firmware reset to reconfigure the
> > > VFs previously enabled.
> >
> > I wonder what does it mean for already bound VFs to vfio driver?
> > Will you rebind them as well? Can I assume that FW error in one VF
> > will trigger "restart" of other VFs too?
>
> Care to reply?
>
>
Sorry, I missed your email earlier.

A firmware reset/recovery has no direct effect on a VF or any function
if it is just idle.  The PCI interface of any function does not get
reset.

If a VF driver (Linux VF driver, DPDK driver, etc) has initialized on
that function, meaning it has exchanged messages with firmware to
register itself and to allocate resources (such as rings), then the
firmware reset will require all those resources to be re-discovered
and re-initialized.  These VF resources are initially assigned by the
PF.  So this refactored function on the PF is to re-assign these
resources back to the VF after the firmware reset.  Again, if the VF
is just bound to vfio and is idle, there is no effect.