1. 07 Jun, 2021 2 commits
    • 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 12 commits