Previously FSLMC bus only supported blacklisting of DPNI (eth),
DPSECI (crypto) devices. With this patch, devices like DPIO,
DPMCP, and other DP* can also be blacklisted/whitelisted.
This is a required condition for secondary processes where the
secondary needs to be passed a mutually exclusive list of
resources as compared the primary and all other secondaries.
This patch also moves the DPIO memory from malloc to hugepage so
that in future in case the DPIO list can be shared, it can be
accessed in secondaries.
Once this patch is done, multi-process cases can be executed by
whitelisting/blacklisting devices in each instance.
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
The I/O threads for DPAA2 take their reference for bpool ID, the
port ID and other info like qdid, from the rte_eth_dev. Further,
to get this data during I/O operation, a reference of the RTE
device is kept in the queue structure (dpaa2_queue).
In case of secondary processes, rte_eth_dev is not same as the
primary process. Thus, the reference goes invalid.
This patch changes the implementation to use the dev_private
rather than the rte_eth_dev as that is shared area across
all the processes.
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
Initial design was to have the buffer pool per process where a
global static array stores the bpids. But, in case of secondary
processes, this would not allow the I/O threads to translate the
bpid in Rx'd packets.
This patch moves the array to a global area (rte_malloc) and in
case of Rx thread not containing a valid reference to the array,
reference is build using the handle avaialble in the dpaa2_queue.
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
Add support in bus and vfio to scan dpdmux type of objects
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
This is to align with the latest qbman hw library
Signed-off-by: Youri Querry <youri.querry_1@nxp.com>
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Add flag in portal init to adjust the qbman memory type,
to decide between legacy portal mode or newly introduced
memory backed portals.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
Signed-off-by: Youri Querry <youri.querry_1@nxp.com>
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
This patch upgrades and sync the dpdk based qbman code
with new version of qbman flib.
Signed-off-by: Youri Querry <youri.querry_1@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Current code expects that bus->parse() would get a string containing
the name of the bus. That is incorrect. bus->parse() is expected
to have strings like:
dpni.1,key=val
dpio.2,key=val
when user passed:
-b fslmc:dpni.1,key=val
This commit fixes this behavior.
Fixes: 50245be05d ("bus/fslmc: support device blacklisting")
Cc: stable@dpdk.org
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
This is just a information. No need to print
it as a error.
Fixes: ce9efbf5bb ("bus/fslmc: support dynamic logging")
Cc: stable@dpdk.org
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Existing code is using the lcore id as the physical core
id. Add code to get the right physical id.
Also, dpaa2 can not support one lcore mapping to multiple cpus,
print err on such cases.
Fixes: ce9efbf5bb ("bus/fslmc: support dynamic logging")
Cc: stable@dpdk.org
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
The code was incorrectly using the cache inhibited access.
It shall use cached enabled access for better performance.
Fixes: 293c0ca94c ("bus/fslmc: support memory backed portals with QBMAN 5.0")
Cc: stable@dpdk.org
Signed-off-by: Youri Querry <youri.querry_1@nxp.com>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
The code was treating the lcore id as physical core id.
The code is updated to use actual physical core value
for any core affinity logic.
Note that DPAA devices are single cluster systems.
Fixes: 5d944582d0 ("bus/dpaa: check portal presence in the caller function")
Cc: stable@dpdk.org
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
With a larger PAGE_SIZE it is possible for the MSI table to very
close to the end of the BAR s.t. when we align the start and end
of the MSI table to the PAGE_SIZE, the end offset of the MSI
table is out of the PCI BAR boundary.
This patch addresses the issue by comparing both the start and the
end offset of the MSI table with the BAR size, and skip the mapping
if it is out of Bar scope.
The patch fixes the debug log as below:
EAL: Skipping BAR0
Signed-off-by: Tone Zhang <tone.zhang@arm.com>
Reviewed-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
The DPAA bus support code put out messages like:
dpaax: read_memory_node(): Unable to glob device-tree memory node:
(/proc/device-tree/memory[@0-9]*/reg)(3)
dpaax: PA->VA translation not available;
dpaax: Expect performance impact.
These are unnecessary and likely to confuse the end user.
Fix this by doing nothing if bus is empty.
Fixes: 5a7dbb934d ("dpaa: enable dpaax library")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
When using multiple queues, there was a race with the kernel
in setting up the second channel. This regression is due to a kernel change
which does not allow accessing sysfs files for Hyper-V channels that are not opened.
The fix is simple, just move the logic to detect not ready
sub channels earlier in the existing loop.
Fixes: 831dba47bd ("bus/vmbus: add Hyper-V virtual bus support")
Cc: stable@dpdk.org
Reported-by: Mohammed Gamal <mgamal@redhat.com>
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Setting up a device that wasn't setup in the primary
process will possibly break the primary process. That's
because the IPC message to retrieve the group fd in the
primary will also *open* that group if it wasn't opened
before. Even though the secondary process closes that fd
soon after as a part of its error handling path, the
primary process leaks it.
What's worse, opening that fd on the primary will
increment the process-local counter of opened groups.
If it was 0 before, then the group will never be added
to the vfio container, nor dpdk memory will be ever
mapped.
This patch moves the proper error checks earlier in the
code to fully prevent setting up devices in secondary
processes that weren't setup in the primary process.
Fixes: 2f4adfad0a ("vfio: add multiprocess support")
Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
The pci_resource_by_index called strlen() on uninitialized
memory which would lead to the wrong size of memory allocated
for the path portion of the resource map. This would either cause
excessively large allocation, or worse memory corruption.
Coverity issue: 300868
Fixes: ea9d56226e ("pci: introduce function to map uio resource by index")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
drivers/bus/pci/linux/pci_vfio.c:45:23: error:
‘failure_handle_lock’ defined but not used
Fixes: 8ffe738651 ("vfio: add lock for hot-unplug failure handler")
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
When the sigbus handler be enabled for hot-unplug, whatever hot-unplug
sigbus or origin sigbus occur, the sigbus handler will be invoked and
it will access the bus and device. While in the control path, the vfio
req handler also will process the bus and device, so a protection of
the resources in vfio req handler should be need. This patch add a lock
in vfio req handler when process bus and device resource, to avoid the
synchronization issue when device be hot-unplugged.
Fixes: c115fd000c ("vfio: handle hotplug request notifier")
Signed-off-by: Jeff Guo <jia.guo@intel.com>
If sysfs directory was incorrectly formatted then the vmbus
setup code would leak a directory handle in the error path.
Coverity issue: 302848
Fixes: 831dba47bd ("bus/vmbus: add Hyper-V virtual bus support")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The devargs of a device can be replaced by a newly allocated one
when trying to probe again the same device (multi-process or
multi-ports scenarios). This is breaking some pointer references.
It can be avoided by copying the new content, freeing the new devargs,
and returning the already inserted pointer.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Tested-by: Qi Zhang <qi.z.zhang@intel.com>
Tested-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Calling rte_mem_check_dma_mask when memory has not been initialized
yet is wrong. This patch use rte_mem_set_dma_mask instead.
Once memory initialization is done, the dma mask set will be used
for checking memory mapped is within the specified mask.
Fixes: fe822eb8c5 ("bus/pci: use IOVA DMA mask check when setting IOVA mode")
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
Current name rte_eal_check_dma_mask does not follow the naming
used in the rest of the file.
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
build error:
In function ‘fman_if_init’,
.../drivers/bus/dpaa/base/fman/fman.c:186:2:
error: ‘strncpy’ output may be truncated copying 4095 bytes from a
string of length 4095 [-Werror=stringop-truncation]
strncpy(__if->node_path, dpa_node->full_name, PATH_MAX - 1);
strncpy may result a not null-terminated string,
replaced it with strlcpy
Fixes: 5b22cf7446 ("bus/dpaa: introducing FMan configurations")
Cc: stable@dpdk.org
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
A constructor is usually declared with RTE_INIT* macros.
As it is a static function, no need to declare before its definition.
The macro is used directly in the function definition.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
When scanning an already plugged device, the virtual address
of mapped PCI resource in rte_pci_device will be overridden
with 0, that may cause driver does not work correctly.
The fix is not to update any rte_pci_device's field if the being
scanned device's driver is already probed.
Bugzilla ID: 85
Fixes: c752998b5e ("pci: introduce library and driver")
Cc: stable@dpdk.org
Reported-by: Geoffrey Lv <geoffrey.lv@gmail.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Some global variables are defined with generic names, add component name
as prefix to variables to prevent collusion with application variables.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
Acked-by: Tianfei Zhang <tianfei.zhang@intel.com>
Some global variables can indeed be static, add static keyword to them.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
In a couple of places we check its error code against -EEXIST,
but this function returned either -1, 0, or 1.
This gets critical when hotplugging a device in secondary
process, while the same device is already plugged in the
primary. Failing to "hotplug" it in the primary will cause
the secondary to fail as well.
Fixes: e9d159c3d5 ("eal: allow probing a device again")
Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
This function is documented to return the number of unregistered
callbacks or negative numbers on error, but pci_vfio checks for
ret != 0 to detect failures. Not anymore.
Fixes: c115fd000c ("vfio: handle hotplug request notifier")
Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Invoking the right pci read/write functions is based on interrupt
handler type. However, this is not configured for secondary processes
precluding to use those functions.
This patch fixes the issue using the driver name the device is bound
to instead.
Fixes: 632b2d1dee ("eal: provide functions to access PCI config")
Cc: stable@dpdk.org
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
On Linux, rte_pci_read_config on success returns the number of read
bytes, but on BSD it returns 0.
Document the return values, and have BSD behave as Linux does.
At least one case (bnx2x PMD) treats 0 as an error, so the change
makes sense also for that.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Currently the code precludes IOVA mode if IOMMU hardware reports
less addressing bits than necessary for full virtual memory range.
Although VT-d emulation currently only supports 39 bits, it could
be iovas for allocated memlory being within that supported range.
This patch allows IOVA mode in such a case adding a call to
rte_eal_check_dma_mask using the reported addressing bits by the
IOMMU hardware.
Indeed, memory initialization code has been modified for using lower
virtual addresses than those used by the kernel for 64 bits processes
by default, and therefore memsegs iovas can use 39 bits or less for
most systems. And this is likely 100% true for VMs.
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Current code checks if IOMMU hardware reports enough addressing
bits for using IOVA mode but it repeats the same check for any
PCI device present. This is not necessary because the IOMMU hardware
is the same for all of them.
This patch only checks the IOMMU using first PCI device found.
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
It's not necessary to insert device argment to devargs_list
during bus scan, but this happens when we try to attach a
device on secondary process. The patch fix the issue.
Fixes: cdb068f031 ("bus/vdev: scan by multi-process channel")
Cc: stable@dpdk.org
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
A virtual device can be matched with following syntax:
bus=vdev,name=X
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
This patch fixes an issue caught with ASAN where a vdev_scan()
to a secondary bus was failing to free some memory.
The doxygen comment in EAL is fixed at the same time.
Fixes: cdb068f031 ("bus/vdev: scan by multi-process channel")
Fixes: 783b6e5497 ("eal: add synchronous multi-process communication")
Cc: stable@dpdk.org
Signed-off-by: Paul Luse <paul.e.luse@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Presence of PA-VA Table is transparent to the drivers. Ignoring the
return values from table update call.
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Device bus should be initialized after bus scan.
While it does not happened when scan vdev from secondary process,
that cause segment fault at rte_dev_probe when call dev->bus->xxx.
Fixes: cdb068f031 ("bus/vdev: scan by multi-process channel")
Cc: stable@dpdk.org
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Musl already has PAGE_SIZE defined, and our define clashed with it.
Rename our define to SYS_PAGE_SIZE.
Bugzilla ID: 36
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
We use _GNU_SOURCE all over the place, but often times we miss
defining it, resulting in broken builds on musl. Rather than
fixing every library's and driver's and application's makefile,
fix it by simply defining _GNU_SOURCE by default for all
builds.
Remove all usages of _GNU_SOURCE in source files and makefiles,
and also fixup a couple of instances of using __USE_GNU instead
of _GNU_SOURCE.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
After calling unplug function of a bus, the device is expected
to be freed. It is too late for getting devargs to remove.
Anyway, the buses which implement unplug are already freeing
the devargs, except the PCI bus.
So the call to rte_devargs_remove() is removed from EAL and
added in PCI.
Fixes: 2effa126fb ("devargs: simplify parameters of removal function")
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
In the devargs syntax for device representors, it is possible to add
several devices at once: -w dbdf,representor=[0-3]
It will become a more frequent case when introducing wildcards
and ranges in the new devargs syntax.
If a devargs string is provided for probing, and updated with a bigger
range for a new probing, then we do not want it to fail because
part of this range was already probed previously.
There can be new ports to create from an existing rte_device.
That's why the check for an already probed device
is moved as bus responsibility.
In the case of vdev, a global check is kept in insert_vdev(),
assuming that a vdev will always have only one port.
In the case of ifpga and vmbus, already probed devices are checked.
In the case of NXP buses, the probing is done only once (no hotplug),
though a check is added at bus level for consistency.
In the case of PCI, a driver flag is added to allow PMD probing again.
Only the PMD knows the ports attached to one rte_device.
As another consequence of being able to probe in several steps,
the field rte_device.devargs must not be considered as a full
representation of the rte_device, but only the latest probing args.
Anyway, the field rte_device.devargs is used only for probing.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Tested-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
The function rte_dev_is_probed() is added in order to improve semantic
and enforce proper check of the probing status of a device.
It will answer this rte_device query:
Is it already successfully probed or not?
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Tested-by: Andrew Rybchenko <arybchenko@solarflare.com>
The PCI mapping requires to know the PCI driver to use,
even before the probing is done. That's why the PCI driver is
referenced early inside the PCI device structure. See
commit 1d20a073fa ("bus/pci: reference driver structure before mapping")
However the rte_driver does not need to be referenced in rte_device
before the device probing is done.
By moving back this assignment at the end of the device probing,
it becomes possible to make clear the status of a rte_device.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Tested-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Rosen Xu <rosen.xu@intel.com>
The following change set introduces HAVE_VFIO_DEV_REQ_INTERFACE
and used in the below files.
drivers/bus/pci/linux/pci_vfio.c
drivers/bus/pci/pci_common.c
lib/librte_eal/linuxapp/eal/eal_interrupts.c
However, Except the first file, the change missed to include
<rte_vfio.h> where HAVE_VFIO_DEV_REQ_INTERFACE defined.
This creates runtime following error on vfio-pci mode and
kernel >= 4.0.0 combination.
EAL: [rte_intr_enable] Unknown handle type of fd 95
EAL: [pci_vfio_enable_notifier]Fail to enable req notifier.
EAL: Fail to unregister req notifier handler.
EAL: Error setting up notifier!
EAL: Requested device 0000:07:00.1 cannot be used
Fixes: cda9441996 ("vfio: fix build with Linux < 4.0")
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
