1. 16 6月, 2015 1 次提交
  2. 03 4月, 2015 5 次提交
  3. 07 3月, 2015 1 次提交
  4. 05 2月, 2015 1 次提交
  5. 28 1月, 2015 1 次提交
  6. 26 1月, 2015 2 次提交
    • Y
      net/mlx4_core: Enable device recovery flow with SRIOV · 55ad3592
      Yishai Hadas 提交于
      In SRIOV, both the PF and the VF may attempt device recovery whenever they
      assume that the device is not functioning.  When the PF driver resets the
      device, the VF should detect this and attempt to reinitialize itself.
      
      The VF must be able to reset itself under all circumstances, even
      if the PF is not responsive.
      
      The VF shall reset itself in the following cases:
      
      1. Commands are not processed within reasonable time over the communication channel.
      This is done considering device state and the correct return code based on
      the command as was done in the native mode, done in the next patch.
      
      2. The VF driver receives an internal error event reported by the PF on the
      communication channel. This occurs when the PF driver resets the device or
      when VF is out of sync with the PF.
      
      Add 'VF reset' capability, which allows the VF to reinitialize itself even when the
      PF is not responsive.
      
      As PF and VF may run their reset flow simulantanisly, there are several cases
      that are handled:
      - Prevent freeing VF resources upon FLR, when PF is in its unloading stage.
      - Prevent PF getting VF commands before it has finished initializing its resources.
      - Upon VF startup, check that comm-channel is online before sending
        commands to the PF and getting timed-out.
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55ad3592
    • Y
      net/mlx4_core: Activate reset flow upon fatal command cases · f5aef5aa
      Yishai Hadas 提交于
      We activate reset flow upon command fatal errors, when the device enters an
      erroneous state, and must be reset.
      
      The cases below are assumed to be fatal: FW command timed-out, an error from FW
      on closing commands, pci is offline when posting/pending a command.
      
      In those cases we place the device into an error state: chip is reset, pending
      commands are awakened and completed immediately. Subsequent commands will
      return immediately.
      
      The return code in the above cases will depend on the command. Commands which
      free and close resources will return success (because the chip was reset, so
      callers may safely free their kernel resources). Other commands will return -EIO.
      
      Since the device's state was marked as error, the catas poller will
      detect this and restart the device's software stack (as is done when a FW
      internal error is directly detected). The device state is protected by a
      persistent mutex lives on its mlx4_dev, as such no need any more for the
      hcr_mutex which is removed.
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5aef5aa
  7. 04 11月, 2014 1 次提交
  8. 29 10月, 2014 1 次提交
  9. 05 8月, 2014 1 次提交
    • J
      mlx4_core: Add support for secure-host and SMP firewall · 114840c3
      Jack Morgenstein 提交于
      Secure-host is the general term for the capability of a device
      to protect itself and the subnet from malicious host software.
      
      This is achieved by:
      1. Not allowing un-trusted entities to access device configuration
         registers, directly (through pci_cr or pci_conf) and indirectly
         (through MADs).
      
      2. Hiding M_Key from untrusted entities.
      
      3. Preventing the modification of GUID0 by un-trusted entities
      
      4. Not allowing drivers on untrusted hosts to receive nor to transmit
         packets over QP0 (SMP Firewall).
      
      The secure-host capability depends on firmware handling all QP0
      packets, and not passing these packets up to the driver. Any information
      required by the driver for proper operation (e.g., SM lid) is passed
      via events generated by the firmware while processing QP0 MADs.
      
      Driver support mainly requires using the MAD_DEMUX FW command at startup,
      where the feature is enabled/disabled through a procedure described in
      the Mellanox HCA tools package.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      
      [ Fix error path in mlx4_setup_hca to go to err_mcg_table_free. - Roland ]
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      114840c3
  10. 29 3月, 2014 1 次提交
  11. 13 3月, 2014 1 次提交
    • J
      mlx4: Implement IP based gids support for RoCE/SRIOV · 5ea8bbfc
      Jack Morgenstein 提交于
      Since there is no connection between the MAC/VLAN and the GID
      when using IP-based addressing, the proxy QP1 (running on the
      slave) must pass the source-mac, destination-mac, and vlan_id
      information separately from the GID. Additionally, the Host
      must pass the remote source-mac and vlan_id back to the slave,
      
      This is achieved as follows:
      Outgoing MADs:
          1. Source MAC: obtained from the CQ completion structure
             (struct ib_wc, smac field).
          2. Destination MAC: obtained from the tunnel header
          3. vlan_id: obtained from the tunnel header.
      Incoming MADs
          1. The source (i.e., remote) MAC and vlan_id are passed in
             the tunnel header to the proxy QP1.
      
      VST mode support:
           For outgoing MADs,  the vlan_id obtained from the header is
              discarded, and the vlan_id specified by the Hypervisor is used
              instead.
           For incoming MADs, the incoming vlan_id (in the wc) is discarded, and the
              "invalid" vlan (0xffff)  is substituted when forwarding to the slave.
      Signed-off-by: NMoni Shoua <monis@mellanox.co.il>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ea8bbfc
  12. 15 1月, 2014 1 次提交
  13. 01 1月, 2014 1 次提交
  14. 18 10月, 2013 1 次提交
  15. 29 7月, 2013 1 次提交
  16. 02 7月, 2013 1 次提交
  17. 14 6月, 2013 1 次提交
  18. 27 4月, 2013 4 次提交
  19. 08 7月, 2012 1 次提交
  20. 05 4月, 2012 1 次提交
  21. 14 12月, 2011 3 次提交
    • J
      mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet · ab9c17a0
      Jack Morgenstein 提交于
      1. Added module parameters sr_iov and probe_vf for controlling enablement of
         SRIOV mode.
      2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
         SRIOV mode
      3. Added port_type_array as a module parameter to allow driver startup with
         ports configured as desired.
         In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
         for the case where the FW supports both port types (ETH and IB), the
         port_type_array parameter is used.
         By default, the port_type_array is set to configure both ports as IB.
      4. When running in sriov mode, the master needs to initialize the ICM eq table
         to hold the eq's for itself and also for all the slaves.
      5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
      6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
         mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
         modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
         VFs obtain their startup information from the PF (master) device via the
         comm channel.
      7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
         aborts loading the device.
      8. Do not allow setting port type via sysfs when running in SRIOV mode.
      9. mlx4_get_ownership:  Currently, only one PF is supported by the driver.
         If the HCA is burned with FW which enables more than one PF, only one
         of the PFs is allowed to run.  The first one up grabs a FW ownership
         semaphone -- all other PFs will find that semaphore taken, and the
         driver will not allow them to run.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
      Signed-off-by: NLiran Liss <liranl@mellanox.co.il>
      Signed-off-by: NMarcel Apfelbaum <marcela@mellanox.co.il>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab9c17a0
    • J
      mlx4_core: Add "native" argument to mlx4_cmd and its callers (where needed) · f9baff50
      Jack Morgenstein 提交于
      For SRIOV, some Hypervisor commands can be executed directly (native = 1).
      Others should go through the command wrapper flow (for tracking resource
      usage, for example, or for changing some HCA configurations that slaves
      need to be notified of).
      
      This patch sets the groundwork for this capability -- adding the correct
      value of "native" in each case.
      
      Note that if SRIOV is not activated, this parameter has no effect.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9baff50
    • J
      mlx4_core: initial header-file changes for SRIOV support · 623ed84b
      Jack Morgenstein 提交于
      These changes will not affect module operation as yet. They
      are only to get some structs and enums in place for use by
      subsequent patches (making those smaller).
      
      Added here:
      * sriov state structs and inlines (mlx4_is_master/slave/mfunc)
      * comm-channel and vhcr support structures
      * enum values for new FW and comm-channel virtual commands
        (i.e., commands, passed via the comm channel to the PF-driver).
      * prototypes for many command wrapper functions (used by the
        PF context for processing FW commands passed to it by the VFs).
      * struct mlx4_eqe is moved from eq.c to mlx4.h (it will be used
        by other mlx4_core source files).
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      623ed84b
  22. 19 7月, 2011 1 次提交
    • O
      mlx4_core: Add network flow counters · f2a3f6a3
      Or Gerlitz 提交于
      ConnectX devices support a set of flow counters that can be attached
      to a set containing one or more QPs.  Each such counter tracks receive
      and transmit packets and bytes of these QPs.  This patch queries the
      device to check support for counters, handles initialization of the
      HCA to enable counters, and initializes a bitmap allocator to control
      counter allocations.  Derived from patch by Eli Cohen <eli@mellanox.co.il>.
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.co.il>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      f2a3f6a3
  23. 26 10月, 2010 1 次提交
  24. 24 10月, 2010 1 次提交
    • J
      IB/mlx4: Signal node desc changes to SM by using FW to generate trap 144 · d0d68b86
      Jack Morgenstein 提交于
      The Node Description cannot be changed via MADs (it is read-only).
      Until now, it was changed in the driver via sysfs, and the new Node
      Description was simply inserted by the driver into MAD responses
      (replacing the description returned by FW).
      
      System startup scripts use the sysfs interface to change the node
      description at driver startup to show the hostname, etc. However, this
      has a race condition: the SM could discover the original FW node
      description rather than the system-specific description if it queried the
      port before the startup scripts finish running.
      
      For mlx4, we fix this with a new FW command (SET_NODE) that allows
      passing the new node description to FW.  When this command is invoked,
      FW sends a trap 144 to the SM.  When it gets this trap, the SM can
      query the node to obtain the new node description -- thus eliminating
      the effects of the race.
      
      This patch simply calls SET_NODE command when a new node description
      is entered via sysfs (thus causing trap 144 to be issued by the FW).
      We ignore all failures of the SET_NODE command (including those caused
      by using a device FW that predates the SET_NODE command), since in
      that case things work just as before.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      d0d68b86
  25. 25 8月, 2010 1 次提交
  26. 19 3月, 2009 1 次提交
  27. 23 10月, 2008 1 次提交
  28. 17 4月, 2008 1 次提交
  29. 18 6月, 2007 1 次提交
    • R
      IB/mlx4: Handle FW command interface rev 3 · 5ae2a7a8
      Roland Dreier 提交于
      Upcoming firmware introduces command interface revision 3, which
      changes the way port capabilities are queried and set.  Update the
      driver to handle both the new and old command interfaces by adding a
      new MLX4_FLAG_OLD_PORT_CMDS that it is set after querying the firmware
      interface revision and then using the correct interface based on the
      setting of the flag.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      5ae2a7a8
  30. 09 5月, 2007 1 次提交
    • R
      IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters · 225c7b1f
      Roland Dreier 提交于
      Add an InfiniBand driver for Mellanox ConnectX adapters.  Because
      these adapters can also be used as ethernet NICs and Fibre Channel 
      HBAs, the driver is split into two modules: 
       
        mlx4_core: Handles low-level things like device initialization and 
          processing firmware commands.  Also controls resource allocation 
          so that the InfiniBand, ethernet and FC functions can share a 
          device without stepping on each other. 
       
        mlx4_ib: Handles InfiniBand-specific things; plugs into the 
          InfiniBand midlayer. 
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      225c7b1f