pcie reset系列之内核框架

布满荆棘的人生 2024-03-17 18:24 37阅读 0赞

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