Bug 370
Summary: | Cannot hotplug VFIO devices if VFIO driver was not loaded at init | ||
---|---|---|---|
Product: | DPDK | Reporter: | Anatoly Burakov (anatoly.burakov) |
Component: | core | Assignee: | Anatoly Burakov (anatoly.burakov) |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ajit.khaparde |
Priority: | Normal | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Anatoly, Is this bug opened to track so that it does not fall through the cracks? Is it ok to assign to you? Since you maintain VFIO anyway? Thanks Yes and yes :) |
Currently, VFIO device initialization depends upon checking if VFIO is enabled. That code looks like this: > int > rte_vfio_is_enabled(const char *modname) > { > const int mod_available = rte_eal_check_module(modname) > 0; > return default_vfio_cfg->vfio_enabled && mod_available; > } The `default_vfio_cfg->vfio_enabled` is set at initialization time with `rte_vfio_enable` function, and is never rechecked afterwards. This makes it so that if `vfio` driver was not loaded at EAL initialization time, any subsequent VFIO device initialization will fail. To fix that, we would have to re-check the existence of a `vfio` driver every time, however the current API gets in the way, because even though it stores global state, it is implemented in a way that looks like it is supposed to be generic and support multiple driver names (and is never used that way - the only time this API is used is in the EAL initialization when checking for a specific `vfio` driver - i think it's a safe assumption to make that whatever implementation of VFIO is in use, it will depend upon the `vfio` kernel module). So, current API will need to be changed (it makes no sense anyway) before this bug can be fixed.