On Fri, Aug 30, 2019 at 09:00:27AM -0700, Michael Chan wrote:

On Fri, Aug 30, 2019 at 2:18 AM Leon Romanovsky [off-list ref] wrote:

quoted

On Mon, Aug 26, 2019 at 09:00:45AM +0300, Leon Romanovsky wrote:

quoted

On Sun, Aug 25, 2019 at 11:54:54PM -0400, Michael Chan wrote:

quoted

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.

Thanks for explaining the flow.