FLR是pci reset的一种。
关于FLR的寄存器操作比较简单, 相关的寄存器有:
配置空间里device cap里的FLR capability bit, 这个表示设备是否支持FLR。
配置空间里device control里的BCR_FLR bit, 写这个bit可以触发FLR。
调用函数检测是否支持FLR:
/* drivers/pci/pci.c */ pcie_has_flr(struct pci_dev *dev)
Linux kernel里pcie_flr会被下面的函数调用到, 触发FLR
/* drivers/pci/pci.c: below tree functions will call __pci_reset_function_locked */
pci_reset_function(struct pci_dev *dev)
pci_reset_function_locked(struct pci_dev *dev)
pci_try_reset_function(struct pci_dev *dev)
=> __pci_reset_function_locked(struct pci_dev *dev)
-> pcie_flr(struct pci_dev *dev)
执行 __pci_reset_function_locked 的时候,6.2内核提供的reset方法有:
/* dev->reset_methods[] is a 0-terminated list of indices into this array */ static const struct pci_reset_fn_method pci_reset_fn_methods[] = { { }, { pci_dev_specific_reset, .name = "device_specific" }, { pci_dev_acpi_reset, .name = "acpi" }, { pcie_reset_flr, .name = "flr" }, { pci_af_flr, .name = "af_flr" }, { pci_pm_reset, .name = "pm" }, { pci_reset_bus_function, .name = "bus" }, };
那么这些reset的优先级,是从数组下标小的,优先级就高。在4.19的内核中,并没有做成table,但顺序是一样的。
且前面reset只要返回不是 -ENOTTY,则不会执行后面的reset。
首先,暴露给用户态的接口,通过这个设备的sysfs接口可以触发FLR:
/* drivers/pci/pci-sysfs.c */ reset_store -> pci_reset_function(struct pci_dev *dev)
另外,vfio里也提供的接口,可以供给用户态触发FLR。这些接口包括,vfio设备的enable,
disable, 以及一个vfio设备相关的ioctl。
`
/* drivers/vfio/pci/vfio_pci_config.c */
vfio_exp_config_write
-> pci_try_reset_function
/* drivers/vfio/pci/vfio_pci.c */
vfio_pci_enable
vfio_pci_disable
vfio_pci_ioctl (cmd == VFIO_DEVICE_RESET)
=> pci_try_reset_function(pdev);
`
单独的FLR操作需要配合整个reset流程工作, 在上面的调用pcie_flr的函数里,他们基本
的处理流程都是, 先做reset_prepare, 再触发FLR,最后做reset后的恢复:
`
the logic of pci_reset_function and its brother functions are:
- reset_prepare
- flr operation if supporting flr
- reset_done
reset_prepare and reset_done callbacks are stored in pci_driver’s pci_error_handlers,大多数驱动注册了pci_error_handler,但很多没有实现prepare。
these callbacks should be offered by your device driver:
驱动中的函数:
struct pci_driver {
…
const struct pci_error_handlers {
…
void (*reset_prepare)(struct pci_dev _dev);
void (_reset_done)(struct pci_dev *dev);
…
}
…
}
`
从上面的代码分析中可以看出,linux内核中的flr流程并不涉及到软件中设备结构的销毁.包括驱动资源的释放。
所以,只要在发生flr这段时间不去下发硬件请求,如果用lspci看,设备理论上会一直都在。对于使能了sriov的硬件,
在实现flr的时候,如果对pf执行flr,在硬件层面都有pf到vf的通知方式, 包括业务黑洞的设置,这样可以保证在pf flr时候通知到
flr做必要的处理,当pf flr完成后,可以通知vf驱动做必要的硬件配置上的恢复。
如果只是flr 某一个vf,不应该影响到其他vf的业务流。
注意,这个跟pcie g5 spec有一些相差。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章