summaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
Commit message (Collapse)AuthorAgeFilesLines
* i40e: Fix the conditional for i40e_vc_validate_vqs_bitmapsBrett Creeley2020-02-111-2/+2
| | | | | | | | | | | | | Commit d9d6a9aed3f6 ("i40e: Fix virtchnl_queue_select bitmap validation") introduced a necessary change for verifying how queue bitmaps from the iavf driver get validated. Unfortunately, the conditional was reversed. Fix this. Fixes: d9d6a9aed3f6 ("i40e: Fix virtchnl_queue_select bitmap validation") Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i40e: Fix virtchnl_queue_select bitmap validationBrett Creeley2020-01-091-4/+18
| | | | | | | | | | | | | | | | | | | Currently in i40e_vc_disable_queues_msg() we are incorrectly validating the virtchnl queue select bitmaps. The virtchnl_queue_select rx_queues and tx_queue bitmap is being compared against ICE_MAX_VF_QUEUES, but the problem is that these bitmaps can have a value greater than I40E_MAX_VF_QUEUES. Fix this by comparing the bitmaps against BIT(I40E_MAX_VF_QUEUES). Also, add the function i40e_vc_validate_vqs_bitmaps() that checks to see if both virtchnl_queue_select bitmaps are empty along with checking that the bitmaps only have valid bits set. This function can then be used in both the queue enable and disable flows. Suggested-by: Arkady Gilinksky <arkady.gilinsky@harmonicinc.com> Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: implement VF stats NDOJesse Brandeburg2019-11-041-0/+48
| | | | | | | | | | | | | | | | | | | | Implement the VF stats gathering via the kernel via ndo_get_vf_stats(). The driver will show per-VF stats in the output of the command: ip -s link show dev <PF> Testing Hints: ip -s link show dev eth0 will return non-zero VF stats. ... vf 0 MAC 00:55:aa:00:55:aa, spoof checking on, link-state enable, trust off RX: bytes packets mcast bcast 128000 1000 104 104 TX: bytes packets 128000 1000 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Refactoring VF MAC filters counting to make more reliableAleksandr Loktionov2019-10-251-26/+19
| | | | | | | | | | | | | | This patch prepares ground for the next VF MAC address change fix. It lets untrusted VF to delete any VF mac filter, but it still doesn't let untrusted VF to add mac filter not setup by PF. It removes information duplication in num_mac mac filters counter. And improves exact h/w mac filters usage checking in the i40e_check_vf_permission() function by counting mac2add_cnt. It also improves logging because now all mac addresses will be validated first and corresponding messages will be logged. Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
* i40e: clear __I40E_VIRTCHNL_OP_PENDING on invalid min Tx rateStefan Assmann2019-09-111-1/+2
| | | | | | | | | | In the case of an invalid min Tx rate being requested i40e_ndo_set_vf_bw() immediately returns -EINVAL instead of releasing __I40E_VIRTCHNL_OP_PENDING first. Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Fix crash caused by stress setting of VF MAC addressesSlawomir Laba2019-08-221-1/+6
| | | | | | | | | | | | | | | | | Add update to the VSI pointer passed to the i40e_set_vf_mac function. If VF is in reset state the driver waits in i40e_set_vf_mac function for the reset to be complete, yet after reset the vsi pointer that was passed into this function is no longer valid. The patch updates local VSI pointer directly from pf->vsi array, by using the id stored in VF pointer (lan_vsi_idx). Without this commit the driver might occasionally invoke general protection fault in kernel and disable the OS entirely. Signed-off-by: Slawomir Laba <slawomirx.laba@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Remove unicast log when VF is leaving multicast mode.Czeslaw Zagorski2019-08-051-18/+21
| | | | | | | | | | | | This patch removes unicast log when VF is leaving multicast mode. Added check of vf->vf_states & I40E_VF_STATE_MC_PROMISC/I40E_VF_STATE_UC_PROMISC. Without this commit, leaving multicast mode logs "unset unicast" in dmsg. Signed-off-by: Czeslaw Zagorski <czeslawx.zagorski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: fix code commentsJeff Kirsher2019-08-051-1/+1
| | | | | | | Found a code comment that needed TLC to correct their formatting. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
* i40e: don't report link up for a VF who hasn't enabled queuesJacob Keller2019-08-051-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit d3d657a90850 ("i40e: update VFs of link state after GET_VF_RESOURCES") modified the PF driver to notify a VF of its link status immediately after it requests resources. This was intended to fix reporting on VF drivers, so that they would properly report link status. However, some older VF drivers do not respond well to receiving a link up notification before queues are enabled. This can cause their state machine to think that it is safe to send traffic. This results in a Tx hang on the VF. More recent versions of the old i40evf and all versions of iavf are resilient to these early link status messages. However, if a VM happens to run an older version of the VF driver, this can be problematic. Record whether the PF has actually enabled queues for the VF. When reporting link status, always report link down if the queues aren't enabled. In this way, the VF driver will never receive a link up notification until after its queues are enabled. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e/i40e_virtchnl_pf: Use struct_size() in kzalloc()Gustavo A. R. Silva2019-06-261-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct virtchnl_iwarp_qvlist_info { ... struct virtchnl_iwarp_qv_info qv_info[1]; }; size = sizeof(struct virtchnl_iwarp_qvlist_info) + (sizeof(struct virtchnl_iwarp_qv_info) * count; instance = kzalloc(size, GFP_KERNEL); and struct virtchnl_vf_resource { ... struct virtchnl_vsi_resource vsi_res[1]; }; size = sizeof(struct virtchnl_vf_resource) + sizeof(struct virtchnl_vsi_resource) * count; instance = kzalloc(size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, qv_info, count), GFP_KERNEL); and instance = kzalloc(struct_size(instance, vsi_res, count), GFP_KERNEL); Notice that, in the first case above, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: "Gustavo A. R. Silva" <gustavo@embeddedor.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: add input validation for virtchnl handlersSergey Nemov2019-06-141-43/+31
| | | | | | | | | | | | | | | | | | | | Change some data to unsigned int instead of integer when we compare. Check LUT values in VIRTCHNL_OP_CONFIG_RSS_LUT handler. Also enhance error/warning messages to print the real values of I40E_MAX_VF_QUEUES, I40E_MAX_VF_VSI and I40E_DEFAULT_QUEUES_PER_VF instead of plain text. Refactor code to comply with 'check first then assign' policy. Remove duplicate checks for VIRTCHNL_OP_CONFIG_RSS_KEY and VIRTCHNL_OP_CONFIG_RSS_LUT opcodes in i40e_vc_process_vf_msg(). We have the very same checks inside the handlers already. Signed-off-by: Sergey Nemov <sergey.nemov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Add bounds check for ch[] arrayPiotr Kwapulinski2019-06-141-1/+10
| | | | | | | | | Add bounds check for ch[] array. Use ARRAY_SIZE() to ensure that idx is within the range. Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: let untrusted VF to create up to 16 VLANsPiotr Kwapulinski2019-06-141-1/+1
| | | | | | | | | | This patch lets untrusted VF to create up to 16 VLANs. It was implemented by increasing I40E_VC_MAX_VLAN_PER_VF up to 16. Without this patch untrusted VF could create only up to 8 VLANs. Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Check and set the PF driver state first in i40e_ndo_set_vf_macLihong Yang2019-06-051-5/+5
| | | | | | | | | | | | The PF driver state flag __I40E_VIRTCHNL_OP_PENDING needs to be checked and set at the beginning of i40e_ndo_set_vf_mac. Otherwise, if there are error conditions before it, the flag will be cleared unexpectedly by this function to cause potential race conditions. Hence move the check to the top of this function. Signed-off-by: Lihong Yang <lihong.yang@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i40e: Do not check VF state in i40e_ndo_get_vf_configLihong Yang2019-06-051-4/+2
| | | | | | | | | | | | | The VF configuration returned in i40e_ndo_get_vf_config is already stored by the PF. There is no dependency on any specific state of the VF to return the configuration. Drop the check against I40E_VF_STATE_INIT since it is not needed. Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i40e: Memory leak in i40e_config_iwarp_qvlistMartyna Szapar2019-05-041-8/+15
| | | | | | | | | | Added freeing the old allocation of vf->qvlist_info in function i40e_config_iwarp_qvlist before overwriting it with the new allocation. Signed-off-by: Martyna Szapar <martyna.szapar@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Fix of memory leak and integer truncation in i40e_virtchnl.cMartyna Szapar2019-05-041-6/+10
| | | | | | | | | | | | Fixed possible memory leak in i40e_vc_add_cloud_filter function: cfilter is being allocated and in some error conditions the function returns without freeing the memory. Fix of integer truncation from u16 (type of queue_id value) to u8 when calling i40e_vc_isvalid_queue_id function. Signed-off-by: Martyna Szapar <martyna.szapar@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: missing input validation on VF message handling by the PFMartyna Szapar2019-05-041-14/+44
| | | | | | | | | | | | | Patch is adding missing input validation on VF message handling by the PF to the functions with opcodes: VIRTCHNL_OP_CONFIG_VSI_QUEUES = 6 VIRTCHNL_OP_CONFIG_IRQ_MAP = 7, VIRTCHNL_OP_DISABLE_QUEUES = 9, VIRTCHNL_OP_CONFIG_PROMISCUOUS_MODE = 14, Signed-off-by: Martyna Szapar <martyna.szapar@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Wrong truncation from u16 to u8Grzegorz Siwik2019-05-041-1/+1
| | | | | | | | | | | | In this patch fixed wrong truncation method from u16 to u8 during validation. It was changed by changing u8 to u32 parameter in method declaration and arguments were changed to u32. Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: add num_vectors checker in iwarp handlerSergey Nemov2019-05-041-0/+10
| | | | | | | | | | Field num_vectors from struct virtchnl_iwarp_qvlist_info should not be larger than num_msix_vectors_vf in the hw struct. The iwarp uses the same set of vectors as the LAN VF driver. Signed-off-by: Sergey Nemov <sergey.nemov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: VF's promiscuous attribute is not keptGrzegorz Siwik2019-05-041-0/+23
| | | | | | | | | | | | This patch fixes a bug where the promiscuous mode was not being kept when the VF switched to a new VLAN. Now we are config two times a promiscuous mode when we switch VLAN. Without this change when we change VF VLAN we still receive all the packets from previous VLAN and only unicast from new VLAN. Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: fix misleading message about promisc setting on un-trusted VFHarshitha Ramamurthy2019-05-031-12/+16
| | | | | | | | | | | | | | | | | | | A refactor of the i40e_vc_config_promiscuous_mode_msg function moved the check for un-trusted VF into another function. We have to lie to an un-trusted VF that its request to set promiscuous mode is successful even when it is not because we don't want the VF to find out its trust status this way. With the refactor, we were running into a case where even though we were not setting promiscuous mode for an un-trusted VF, we still printed a misleading message that it was successful. This patch fixes that by ensuring that a success message is printed on the host side only when the promiscuous mode change has been successful. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: remove out-of-range comparisons in i40e_validate_cloud_filterJacob Keller2019-05-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The function i40e_validate_cloud_filter checks that the destination and source port numbers are valid by attempting to ensure that the number is non-zero and no larger than 0xFFFF. However, the types for the dst_port and src_port variable are __be16 which by definition cannot be larger than 0xFFFF Since these values cannot be larger than 2 bytes, the check to see if they exceed 0xFFFF is meaningless. One might consider these checks as some sort of defensive coding, in case the type was later changed. However, these checks also byte-swap the value before comparison using be16_to_cpu, which will truncate the values to 16bits anyways. Additionally, changing the type would require updating the opcodes to support new data layout of these virtchnl commands. Remove the check to silence the -Wtype-limits warning that was added to GCC 8. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: remove error msg when vf with port vlan tries to remove vlan 0Aleksandr Loktionov2019-05-031-1/+2
| | | | | | | | | | | VF's attempt to delete vlan 0 when a port vlan is configured is harmless in this case pf driver just does nothing. If vf will try to remove other vlans when a port vlan is configured it will still produce error as before. Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Able to add up to 16 MAC filters on an untrusted VFAdam Ludkiewicz2019-04-161-2/+4
| | | | | | | | | | | | This patch fixes the problem with the driver being able to add only 7 multicast MAC address filters instead of 16. The problem is fixed by changing the maximum number of MAC address filters to 16+1+1 (two extra are needed because the driver uses 1 for unicast MAC address and 1 for broadcast). Signed-off-by: Adam Ludkiewicz <adam.ludkiewicz@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: clean up several indentation issuesColin Ian King2019-01-221-2/+2
| | | | | | | | | There are several statements that have incorrect levels of indentation, fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: check queue pairs num in config queues handlerSergey Nemov2019-01-221-1/+6
| | | | | | | | | | | | Check if num_queue_pairs number requested by VF is less than maximum possible value in VIRTCHNL_OP_CONFIG_VSI_QUEUES handler. Also check if local_vf_id >= 0 in common handler since it is of int type and can potentially be negative. Signed-off-by: Sergey Nemov <sergey.nemov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: suppress bogus error messageMitch Williams2018-11-141-1/+2
| | | | | | | | | | | | | | | The i40e driver complains about unprivileged VFs trying to configure promiscuous mode each time a VF reset occurs. This isn't the fault of the poor VF driver - the PF driver itself is making the request. To fix this, skip the privilege check if the request is to disable all promiscuous activity. This gets rid of the bogus message, but doesn't affect privilege checks, since we really only care if the unprivileged VF is trying to enable promiscuous mode. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Protect access to VF control methodsJan Sokolowski2018-11-141-5/+59
| | | | | | | | | | | | | | A scenario has been found in which simultaneous addition/removal and modification of VF's might cause unstable behaviour, up to and including kernel panics. Protect the methods that create/modify/destroy VF's by locking them behind an atomically set bit in PF status bitfield. Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Update status codesMitch Williams2018-10-311-1/+1
| | | | | | | | | | | Add a few new status code which will be used by the ice driver, and rename a few to make them more consistent. Error code are mapped to similar values as in i40e_status.h, so as to be compatible with older VF drivers not using this status enum. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Use proper enum in i40e_ndo_set_vf_link_stateNathan Chancellor2018-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | Clang warns when one enumerated type is converted implicitly to another. drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4214:42: warning: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Wenum-conversion] pfe.event_data.link_event.link_speed = I40E_LINK_SPEED_40GB; ~ ^~~~~~~~~~~~~~~~~~~~ 1 warning generated. Use the proper enum from virtchnl_link_speed, which has the same value as I40E_LINK_SPEED_40GB, VIRTCHNL_LINK_SPEED_40GB. This appears to be missed by commit ff3f4cc267f6 ("virtchnl: finish conversion to virtchnl interface"). Link: https://github.com/ClangBuiltLinux/linux/issues/81 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Remove unused msglen parameter from virtchnl functionsPatryk Małek2018-09-251-59/+37
| | | | | | | | | msglen parameter seems to be unused in several virtchnl function. This patch removes it from signatures of those functions. Signed-off-by: Patryk Małek <patryk.malek@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: add a helper function to validate a VF based on the vf idHarshitha Ramamurthy2018-09-251-21/+41
| | | | | | | | | | | | | | | | | When we are trying to change VF settings, it is possible for 2 race conditions to happen. One, when the VF is created but not yet enabled. Second, the VF is enabled but the VSI is still not created or not yet re-created in the VF reset flow. This patch introduces a helper function to validate that the VF is enabled and that the VSI is set up. This patch also calls this function from other functions which could get into these race conditions. While we are poking around here, remove unnecessary parenthesis that checkpatch was complaining about. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Unset promiscuous settings on VF resetMariusz Stachura2018-09-251-110/+157
| | | | | | | | | | This patch cleans up promiscuous configuration when a VF reset occurs. Previously the promiscuous mode settings were still there after the VF driver removal. Signed-off-by: Mariusz Stachura <mariusz.stachura@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Prevent deleting MAC address from VF when set by PFPatryk Małek2018-08-301-0/+10
| | | | | | | | | | To prevent VF from deleting MAC address that was assigned by the PF we need to check for that scenario when we try to delete a MAC address from a VF. Signed-off-by: Patryk Małek <patryk.malek@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40evf: Change a VF mac without reloading the VF driverPaweł Jabłoński2018-08-301-3/+5
| | | | | | | | | | | | | Add possibility to change a VF mac address from host side without reloading the VF driver on the guest side. Without this patch it is not possible to change the VF mac because executing i40evf_virtchnl_completion function with VIRTCHNL_OP_GET_VF_RESOURCES opcode resets the VF mac address to previous value. Signed-off-by: Paweł Jabłoński <pawel.jablonski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e/i40evf: take into account queue map from vf when handling queuesHarshitha Ramamurthy2018-04-301-3/+66
| | | | | | | | | | | | | | | | The expectation of the ops VIRTCHNL_OP_ENABLE_QUEUES and VIRTCHNL_OP_DISABLE_QUEUES is that the queue map sent by the VF is taken into account when enabling/disabling queues in the VF VSI. This patch makes sure that happens. By breaking out the individual queue set up functions so that they can be called directly from the i40e_virtchnl_pf.c file, only the queues as specified by the queue bit map that accompanies the enable/disable queues ops will be handled. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e/i40evf: cleanup incorrect function doxygen commentsJacob Keller2018-04-301-8/+8
| | | | | | | | | | | Recent versions of the Linux kernel now warn about incorrect parameter definitions for function comments. Fix up several function comments to correctly reflect the current function arguments. This cleans up the warnings and helps ensure our documentation is accurate. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* net: intel: Cleanup the copyright/license headersJeff Kirsher2018-04-271-25/+1
| | | | | | | | | | | | | | | After many years of having a ~30 line copyright and license header to our source files, we are finally able to reduce that to one line with the advent of the SPDX identifier. Also caught a few files missing the SPDX license identifier, so fixed them up. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Shannon Nelson <shannon.nelson@oracle.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* intel: add SPDX identifiers to all the Intel driversJeff Kirsher2018-03-231-0/+1
| | | | | | | | | Add the SPDX identifiers to all the Intel wired LAN driver files, as outlined in Documentation/process/license-rules.rst. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i40e: Fix permission check for VF MAC filtersFilip Sadowski2018-03-141-28/+51
| | | | | | | | | | | | | | | | | | | | | | | | | When VF requests adding of MAC filters the checking is done against number of already present MAC filters not adding them at the same time. It makes it possible to add a bunch of filters at once possibly exceeding acceptable limit of I40E_VC_MAX_MAC_ADDR_PER_VF filters. This happens because when checking vf->num_mac, we do not check how many filters are being requested at once. Modify the check function to ensure that it knows how many filters are being requested. This allows the check to ensure that the total number of filters in a single request does not cause us to go over the limit. Additionally, move the check to within the lock to ensure that the vf->num_mac is checked while holding the lock to maintain consistency. We could have simply moved the call to i40e_vf_check_permission to within the loop, but this could cause a request to be non-atomic, and add some but not all the addresses, while reporting an error code. We want to avoid this behavior so that users are not confused about which filters have or have not been added. Signed-off-by: Filip Sadowski <filip.sadowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Fix attach VF to VM issuePaweł Jabłoński2018-03-141-0/+11
| | | | | | | | | | | | | Fix for "Resource temporarily unavailable" problem when virsh is trying to attach a device to VM. When the VF driver is loaded on host and virsh is trying to attach it to the VM and set a MAC address, it ends with a race condition between i40e_reset_vf and i40e_ndo_set_vf_mac functions. The bug is fixed by adding polling in i40e_ndo_set_vf_mac function For when the VF is in Reset mode. Signed-off-by: Paweł Jabłoński <pawel.jablonski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: remove some stray indentingDan Carpenter2018-02-261-2/+2
| | | | | | | | These two lines are indented too far. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: check that pointer VSI is not null before dereferencing itColin Ian King2018-02-261-1/+1
| | | | | | | | | | | | Function i40e_find_vsi_from_id can potentially return null, hence VSI may be null, so defensively check it is non-null before dereferencing it to check the seid. Fixes: e284fc280473 ("i40e: Add and delete cloud filter") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Add and delete cloud filterAvinash Dayanand2018-02-141-1/+457
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides support to add or delete cloud filter for queue channels created for ADq on VF. We are using the HW's cloud filter feature and programming it to act as a TC filter applied to a group of queues. There are two possible modes for a VF when applying a cloud filter 1. Basic Mode: Intended to apply filters that don't need a VF to be Trusted. This would include the following Dest MAC + L4 port Dest MAC + VLAN + L4 port 2. Advanced Mode: This mode is only for filters with combination that requires VF to be Trusted. Dest IP + L4 port When cloud filters are applied on a trusted VF and for some reason the same VF is later made as untrusted then all cloud filters will be deleted. All cloud filters has to be re-applied in such a case. Cloud filters are also deleted when queue channel is deleted. Testing-Hints: ============= 1. Adding Basic Mode filter should be possible on a VF in Non-Trusted mode. 2. In Advanced mode all filters should be able to be created. Steps: ====== 1. Enable ADq and create TCs using TC mqprio command 2. Apply cloud filter. 3. Turn-off the spoof check. 4. Pass traffic. Example: ======== 1. tc qdisc add dev enp4s2 root mqprio num_tc 4 map 0 0 0 0 1 2 2 3\ queues 2@0 2@2 1@4 1@5 hw 1 mode channel 2. tc qdisc add dev enp4s2 ingress 3. ethtool -K enp4s2 hw-tc-offload on 4. ip link set ens261f0 vf 0 spoofchk off 5. tc filter add dev enp4s2 protocol ip parent ffff: prio 1 flower\ dst_ip 192.168.3.5/32 ip_proto udp dst_port 25 skip_sw hw_tc 2 Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Service request to configure bandwidth for ADq on a VFAvinash Dayanand2018-02-141-3/+53
| | | | | | | | | This patch handles the request from ADq enabled VF to allocate bandwidth to each traffic class which means for each VSI. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Delete queue channel for ADq on VFAvinash Dayanand2018-02-141-0/+63
| | | | | | | | | | | | | This patch takes care of freeing up all the VSIs, queues and other ADq related software and hardware resources, when a user requests for deletion of ADq on VF. Example command: tc qdisc del dev eth0 root Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: Enable ADq and create queue channel/s on VFAvinash Dayanand2018-02-141-68/+361
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables ADq and creates queue channels on a VF. An ADq enabled VF can have up to 4 VSIs and each one of them represents a traffic class and this is termed as a queue channel. Each of these VSIs can have up to 4 queues. This patch services the request for enabling ADq and adds queue channel based on the TC mqprio info provided by the user in the VF. Initially a check is made to see if spoof check is OFF, if not ADq will not be enabled. PF notifies VF for a reset in order to complete the creation of ADq resources i.e. creation of additional VSIs and allocation of queues as per TC information, all in the reset path. Steps: ====== 1. Turn off the spoof check 2. Enable ADq using tc mqprio command with or without rate limit. 3. Pass traffic. Example: ======== % ip link set dev eth0 vf 0 spoofchk off % tc qdisc add dev $iface root mqprio num_tc 4 map\ 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 queues\ 4@0 4@4 4@8 4@8 hw 1 mode channel Expected results: ================= 1. Total number of queues for the VF should be sum of queues of all TCs. 2. Traffic flow should be normal without errors. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: add helper conversion function for link_speedJacob Keller2018-01-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We introduced the virtchnl interface in order to have an interface for talking to a virtual device driver which was host-driver agnostic. This interface has its own definitions, including one for link speed. The host driver has to talk to the virtchnl interface using these new definitions in order to remain compatible. Today, the i40e link_speed enumerations are value-exact matches for the virtchnl interface, so it was originally decided to simply use a typecast. However, this is unsafe, and makes it easier for future drivers to continue this unsafe practice. There is nothing guaranteeing these values are exact, and the type-cast would hide any compiler warning which indicates the problem. Rather than rely on this type cast, introduce a helper function which can convert the AdminQ link speed definition into a virtchnl definition. This can then be used by host driver implementations in order to safely convert to the interface recognized by the virtual functions. If the link speed is not able to be represented by the virtchnl definitions we'll report UNKNOWN which is the safest result. This will ensure that should the driver specific link_speeds actual bit definitions change, we do not report them incorrectly according to the VF. Additionally, this provides a better pattern for future drivers to copy, as it is more likely a future device may not use the exact same bit-wise definition as the current virtchnl interface. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* i40e: update VFs of link state after GET_VF_RESOURCESJacob Keller2018-01-101-0/+1
| | | | | | | | | | | | | | | | | | | | We currently notify a VF of the link state after ENABLE_QUEUES, which is the last thing a VF does after being configured. Guests may not actually ENABLE_QUEUES until they get configured, and thus between driver load and device configuration the VF may show inaccurate link status. Fix this by also sending the link state after GET_VF_RESOURCES. Although we could remove the message following ENABLE_QUEUES, it's not that significant of a loss, so this patch just keeps both to ensure maximum compatibility with guests on various OSes. Specifically, without this patch guests running FreeBSD will display inaccurate link state until the device is brought up. This is mostly a cosmetic issue but can be confusing to system administrators. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
OpenPOWER on IntegriCloud