aboutsummaryrefslogtreecommitdiffstats
path: root/src/vlib/linux/vmbus.c
AgeCommit message (Collapse)AuthorFilesLines
2021-01-11dpdk: allow configure individual VMBUS devicesVladimir Ratnikov1-8/+14
now startup.conf supports confuguration for VMBUS devices as for PCI devices for whitelisting/blacklisting dpdk { dev fa5a6e7a-cf3a-4b98-9569-addb479b84bc } with sub-configuration as for PCI devices dpdk { blacklist fa5a6e7a-cf3a-4b98-9569-addb479b84bc } where fa5a6e7a-cf3a-4b98-9569-addb479b84bc - example of UUID struct vlib_vmbus_addr_t changed to union with UUID described fields Added device_config_index_by_vmbus_addr blacklist_by_vmbus_addr to enumerate available device configs hash_key is as_u32[0] field(last 4 bytes of UUID) Lost of precision against full UUID, but 2^32 is enough to handle all the devices available Added is_blacklisted check while creating vnet devices in order to supress creation of dev if it's blacklisted Type: feature Signed-off-by: Vladimir Ratnikov <vratnikov@netgate.com> Change-Id: Id82611e54fed082190e488c7e5fbe14ecbe5b2ab
2019-05-16init / exit function orderingDave Barach1-2/+7
The vlib init function subsystem now supports a mix of procedural and formally-specified ordering constraints. We should eliminate procedural knowledge wherever possible. The following schemes are *roughly* equivalent: static clib_error_t *init_runs_first (vlib_main_t *vm) { clib_error_t *error; ... do some stuff... if ((error = vlib_call_init_function (init_runs_next))) return error; ... } VLIB_INIT_FUNCTION (init_runs_first); and static clib_error_t *init_runs_first (vlib_main_t *vm) { ... do some stuff... } VLIB_INIT_FUNCTION (init_runs_first) = { .runs_before = VLIB_INITS("init_runs_next"), }; The first form will [most likely] call "init_runs_next" on the spot. The second form means that "init_runs_first" runs before "init_runs_next," possibly much earlier in the sequence. Please DO NOT construct sets of init functions where A before B actually means A *right before* B. It's not necessary - simply combine A and B - and it leads to hugely annoying debugging exercises when trying to switch from ad-hoc procedural ordering constraints to formal ordering constraints. Change-Id: I5e4353503bf43b4acb11a45fb33c79a5ade8426c Signed-off-by: Dave Barach <dave@barachs.net>
2019-03-13VPP-1576: fix a set of coverity warningsDave Barach1-1/+4
Change-Id: Ifd34aed8692d5acaa370d4976d974ac573e43705 Signed-off-by: Dave Barach <dave@barachs.net>
2019-03-13vmbus: not having uio_hv_generic is not an errorStephen Hemminger1-7/+20
If uio_hv_generic is not loaded, then the startup code will fallback to the older failsafe/tap method of initialization in DPDK. Therefore don't put out scary message in the log. Also, reorder startup to avoid manipulating lower device until/unless uio is going to work. Change-Id: Ie1cc77b4b5359c04f00a93d01a772eccf3bbab37 Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
2019-03-06vmbus: fix bug that breaks multiple netvsc vdevsMatthew Smith1-2/+2
VPP supports two DPDK drivers for managing netvsc devices on Azure/Hyper-V. The new netvsc PMD looks a lot like other PCI-based PMDs but it requires recently added kernel support (>=4.17). The older vdev_netvsc is an abstraction that manages the mlx4 VF and tap device underlying the netvsc interface using the failsafe PMD. Distros with older kernels (e.g. RHEL/CentOS 7.x) have to use vdev_netvsc. At startup, netvsc devices are processed and an attempt is made to initialize them for management by the netvsc PMD. If that fails, then vlib_vmbus_bind_to_uio() returns early and the device can be initialized for management by vdev_netvsc. The operation that is supposed to fail if the netvsc PMD cannot be used is registration of the netvsc device type ID with the uio_hv_generic driver. This operation is attempted exactly once so it does not fail for netvsc devices processed after the first one and they end up in a state where they cannot be initialized for use by vdev_netvsc. Only unset uio_new_id_needed if uio_hv_generic registration succeeds. Change-Id: I6be925d422b87ed24e0f4611304cc3a6b07a34fd Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2019-01-17vmbus: fix strncpy related warningsStephen Hemminger1-4/+4
The code that was manipulating interface names with ifreq was causing warnings about possible truncation and non terminated strings. These are warnings only since kernel would allow a interface name > 15 characters anyway. Change-Id: I794a94fe310b8568403d4e3523c61d53468a6f02 Reported-by: Burt Silverman <burtms@gmail.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
2018-12-19vlib: support Hyper-v/Azure VMBusStephen Hemminger1-0/+405
This patch adds support for VMBus to the VPP infrastructure. Since the only device that matters is the netvsc Poll Mode Driver in DPDK, the infrastructure is much simpler than PCI. Change-Id: Ie96c897ad9c426716c2398e4528688ce2217419b Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>