1. 07 Jun, 2021 5 commits
    • Brett Creeley's avatar
      ice: Refactor VIRTCHNL_OP_CONFIG_VSI_QUEUES handling · 7ad15440
      Brett Creeley authored
      Currently, when a VF requests queue configuration via
      VIRTCHNL_OP_CONFIG_VSI_QUEUES the PF driver expects that this message
      will only be called once and we always assume the queues being
      configured start from 0. This is incorrect and is causing issues when
      a VF tries to send this message for multiple queue blocks. Fix this by
      using the queue_id specified in the virtchnl message and allowing for
      individual Rx and/or Tx queues to be configured.
      
      Also, reduce the duplicated for loops for configuring the queues by
      moving all the logic into a single for loop.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      7ad15440
    • Krzysztof Kazimierczak's avatar
      ice: Refactor ice_setup_rx_ctx · 43c7f919
      Krzysztof Kazimierczak authored
      Move AF_XDP logic and buffer allocation out of ice_setup_rx_ctx() to a
      new function ice_vsi_cfg_rxq(), so the function actually sets up the Rx
      context.
      Signed-off-by: default avatarKrzysztof Kazimierczak <krzysztof.kazimierczak@intel.com>
      Co-developed-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Tested-by: default avatarKiran Bhandare <kiranx.bhandare@intel.com>
      43c7f919
    • Brett Creeley's avatar
      ice: Save VF's MAC across reboot · f28cd5ce
      Brett Creeley authored
      If a VM reboots and/or VF driver is unloaded, its cached hardware MAC
      address (hw_lan_addr.addr) is cleared in some cases. If the VF is
      trusted, then the PF driver allows the VF to clear its old MAC address
      even if this MAC was configured by a host administrator. If the VF is
      untrusted, then the PF driver allows the VF to clear its old MAC
      address only if the host admin did not set it.
      
      For the trusted VF case, this is unexpected and will cause issues
      because the host configured MAC (i.e. via XML) will be cleared on VM
      reboot. For the untrusted VF case, this is done to be consistent and it
      will allow the VF to keep the same MAC across VM reboot.
      
      Fix this by introducing dev_lan_addr to the VF structure. This will be
      the VF's MAC address when it's up and running and in most cases will be
      the same as the hw_lan_addr. However, to address the VM reboot and
      unload/reload problem, the driver will never allow the hw_lan_addr to be
      cleared via VIRTCHNL_OP_DEL_ETH_ADDR. When the VF's MAC is changed, the
      dev_lan_addr and hw_lan_addr will always be updated with the same value.
      The only ways the VF's MAC can change are the following:
      
      - Set the VF's MAC administratively on the host via iproute2.
      - If the VF is trusted and changes/sets its own MAC.
      - If the VF is untrusted and the host has not set the MAC via iproute2.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      f28cd5ce
    • Brett Creeley's avatar
      ice: Manage VF's MAC address for both legacy and new cases · 51efbbdf
      Brett Creeley authored
      Currently there is no way for a VF driver to specify if it wants to
      change it's hardware address. New bits are being added to virtchnl.h
      in struct virtchnl_ether_addr that allow for the VF to correctly
      communicate this information. However, legacy VF drivers that don't
      support the new virtchnl.h bits still need to be supported. Make a
      best effort attempt at saving the VF's primary/device address in the
      legacy case and depend on the VIRTCHNL_ETHER_ADDR_PRIMARY type for
      the new case.
      
      Legacy case - If a unicast MAC is being added and the
      hw_lan_addr.addr is empty, then populate it. This assumes that the
      address is the VF's hardware address. If a unicast MAC is being
      added and the hw_lan_addr.addr is not empty, then cache it in the
      legacy_last_added_umac.addr. If a unicast MAC is being deleted and it
      matches the hw_lan_addr.addr, then zero the hw_lan_addr.addr.
      Also, if the legacy_last_added_umac.addr has not expired, copy the
      legacy_last_added_umac.addr into the hw_lan_addr.addr. This is done
      because we cannot guarantee the order of VIRTCHNL_OP_ADD_ETH_ADDR and
      VIRTCHNL_OP_DEL_ETH_ADDR.
      
      New case - If a unicast MAC is being added and it's specified as
      VIRTCHNL_ETHER_ADDR_PRIMARY, then replace the current
      hw_lan_addr.addr. If a unicast MAC is being deleted and it's type
      is specified as VIRTCHNL_ETHER_ADDR_PRIMARY, then zero the
      hw_lan_addr.addr.
      
      Untrusted VFs - Only allow above legacy/new changes to their
      hardware address if the PF has not set it administratively via
      iproute2.
      
      Trusted VFs - Always allow above legacy/new changes to their
      hardware address even if the PF has administratively set it via
      iproute2.
      
      Also, change the variable dflt_lan_addr to hw_lan_addr to clearly
      represent the purpose of this variable since it's purpose is to
      act as a hardware programmed MAC address for the VF.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      51efbbdf
    • Brett Creeley's avatar
      virtchnl: Use pad byte in virtchnl_ether_addr to specify MAC type · eb550f53
      Brett Creeley authored
      Currently, there is no way for a VF driver to specify that it wants to
      change its device/primary unicast MAC address. This makes it
      difficult/impossible for the PF driver to track the VF's device/primary
      unicast MAC address, which is used for VM/VF reboot and displaying on
      the host. Fix this by using 2 bits of a pad byte in the
      virtchnl_ether_addr structure so the VF can specify what type of MAC
      it's adding/deleting.
      
      Below are the values that should be used by all VF drivers going
      forward.
      
      VIRTCHNL_ETHER_ADDR_LEGACY(0):
      	- The type should only ever be 0 for legacy AVF drivers (i.e.
      	  drivers that don't support the new type bits). The PF drivers
      	  will track VF's device/primary unicast MAC, but this will only
      	  be a best effort.
      
      VIRTCHNL_ETHER_ADDR_PRIMARY(1):
      	- This type should only be used when the VF is changing their
      	  device/primary unicast MAC. It should be used for both delete
      	  and add cases related to the device/primary unicast MAC.
      
      VIRTCHNL_ETHER_ADDR_EXTRA(2):
      	- This type should be used when the VF is adding and/or deleting
      	  MAC addresses that are not the device/primary unicast MAC. For
      	  example, extra unicast addresses and multicast addresses
      	  assuming the PF supports "extra" addresses at all.
      
      If a PF is parsing the type field of the virtchnl_ether_addr, then it
      should use the VIRTCHNL_ETHER_ADDR_TYPE_MASK to mask the first two bits
      of the type field since 0, 1, and 2 are the only valid values.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      eb550f53
  2. 04 Jun, 2021 26 commits
  3. 03 Jun, 2021 9 commits