This is a code clarity and extensibility issue, rather than a problem in behaviour.
Description of problem
A number of places in the runtime code use values described as a "PCI address" but which are not actuall in PCI address format (DDDD:BB:DD.F). Rather they are "PCI paths" - that is a description of the location of a device based on its slot number and the slot number of all the bridges traversed to reach it.
For now, the PCI paths we generate always have exactly two elements (one bridge + the device itself), but we will want to use other cases in future. kata-containers/agent#854 is tracking making that generalization on the agent side.
Expected result
PCI paths are handled and named consistently distinct from PCI addresses in the normal format.
Actual result
"PCI address" in the code frequently refers to (a limited form of) PCI paths.
Further information
See also kata-containers/agent#854 and kata-containers/agent#855
This is a code clarity and extensibility issue, rather than a problem in behaviour.
Description of problem
A number of places in the runtime code use values described as a "PCI address" but which are not actuall in PCI address format (DDDD:BB:DD.F). Rather they are "PCI paths" - that is a description of the location of a device based on its slot number and the slot number of all the bridges traversed to reach it.
For now, the PCI paths we generate always have exactly two elements (one bridge + the device itself), but we will want to use other cases in future. kata-containers/agent#854 is tracking making that generalization on the agent side.
Expected result
PCI paths are handled and named consistently distinct from PCI addresses in the normal format.
Actual result
"PCI address" in the code frequently refers to (a limited form of) PCI paths.
Further information
See also kata-containers/agent#854 and kata-containers/agent#855