On Tue, May 12, 2020 at 3:30 pm, Darek Stojaczyk
<dariusz.stojac...@intel.com> wrote:
The parsing code was bailing on domains greater than UINT16_MAX,
but domain numbers like that are still valid and present on some
systems.
One example is Intel VMD (Volume Management Device), which acts
somewhat
as a software-managed PCI switch and its upstream linux driver assigns
all downstream devices a PCI domain of 0x10000.
Parsing a BDF like 10000:01:00.0 was failing before. To fix it,
increase
the upper limit of domain number to UINT32_MAX. This matches the size
of
struct rte_pci_addr->domain (uint32).
Signed-off-by: Darek Stojaczyk <dariusz.stojac...@intel.com
<mailto:dariusz.stojac...@intel.com>>
---
lib/librte_pci/rte_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_pci/rte_pci.c b/lib/librte_pci/rte_pci.c
index d1ab6b414d..ad2cdfebb2 100644
--- a/lib/librte_pci/rte_pci.c
+++ b/lib/librte_pci/rte_pci.c
@@ -72,9 +72,9 @@ pci_dbdf_parse(const char *input, struct
rte_pci_addr *dev_addr)
errno = 0;
val = strtoul(in, &end, 16);
- if (errno != 0 || end[0] != ':' || val > UINT16_MAX)
+ if (errno != 0 || end[0] != ':' || val > UINT32_MAX)
return -EINVAL;
- dev_addr->domain = (uint16_t)val;
+ dev_addr->domain = (uint32_t)val;
in = end + 1;
in = get_u8_pciaddr_field(in, &dev_addr->bus, ':');
if (in == NULL)
--
2.17.1
Agree this came up before on Hyper-V as well. It meant fixing libpci.
Not sure the cast of val is necessary, other than an attempt to silence
some static checker
about implicit type conversion causing loss of precision.
