pcie reset系列之 内核框架

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有一些相差。