On Fri, Aug 30, 2019 at 09:00:27AM -0700, Michael Chan wrote: > On Fri, Aug 30, 2019 at 2:18 AM Leon Romanovsky <l...@kernel.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.
Thanks for explaining the flow.
