1. 10 10月, 2020 7 次提交
    • M
      net/mlx5: Add support for fw live patch event · 2d693567
      Moshe Shemesh 提交于
      Firmware live patch event notifies the driver that the firmware was just
      updated using live patch. In such case the driver should not reload or
      re-initiate entities, part to updating the firmware version and
      re-initiate the firmware tracer which can be updated by live patch with
      new strings database to help debugging an issue.
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NSaeed Mahameed <saeedm@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      2d693567
    • M
      devlink: Add enable_remote_dev_reset generic parameter · 195d9dec
      Moshe Shemesh 提交于
      The enable_remote_dev_reset devlink param flags that the host admin
      allows device resets that can be initiated by other hosts. This
      parameter is useful for setups where a device is shared by different
      hosts, such as multi-host setup. Once the user set this parameter to
      false, the driver should NACK any attempt to reset the device while the
      driver is loaded.
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      195d9dec
    • M
      net/mlx5: Handle sync reset request event · 38b9f903
      Moshe Shemesh 提交于
      Once the driver gets sync_reset_request from firmware it prepares for the
      coming reset and sends acknowledge.
      After getting this event the driver expects device reset, either it will
      trigger PCI reset on sync_reset_now event or such PCI reset will be
      triggered by another PF of the same device. So it moves to reset
      requested mode and if it gets PCI reset triggered by the other PF it
      detect the reset and reloads.
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NSaeed Mahameed <saeedm@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      38b9f903
    • M
      devlink: Add remote reload stats · 77069ba2
      Moshe Shemesh 提交于
      Add remote reload stats to hold the history of actions performed due
      devlink reload commands initiated by remote host. For example, in case
      firmware activation with reset finished successfully but was initiated
      by remote host.
      
      The function devlink_remote_reload_actions_performed() is exported to
      enable drivers update on remote reload actions performed as it was not
      initiated by their own devlink instance.
      
      Expose devlink remote reload stats to the user through devlink dev get
      command.
      
      Examples:
      $ devlink dev show
      pci/0000:82:00.0:
        stats:
            reload:
              driver_reinit 2 fw_activate 1 fw_activate_no_reset 0
            remote_reload:
              driver_reinit 0 fw_activate 0 fw_activate_no_reset 0
      pci/0000:82:00.1:
        stats:
            reload:
              driver_reinit 1 fw_activate 0 fw_activate_no_reset 0
            remote_reload:
              driver_reinit 1 fw_activate 1 fw_activate_no_reset 0
      
      $ devlink dev show -jp
      {
          "dev": {
              "pci/0000:82:00.0": {
                  "stats": {
                      "reload": {
                          "driver_reinit": 2,
                          "fw_activate": 1,
                          "fw_activate_no_reset": 0
                      },
                      "remote_reload": {
                          "driver_reinit": 0,
                          "fw_activate": 0,
                          "fw_activate_no_reset": 0
                      }
                  }
              },
              "pci/0000:82:00.1": {
                  "stats": {
                      "reload": {
                          "driver_reinit": 1,
                          "fw_activate": 0,
                          "fw_activate_no_reset": 0
                      },
                      "remote_reload": {
                          "driver_reinit": 1,
                          "fw_activate": 1,
                          "fw_activate_no_reset": 0
                      }
                  }
              }
          }
      }
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      77069ba2
    • M
      devlink: Add reload stats · a254c264
      Moshe Shemesh 提交于
      Add reload stats to hold the history per reload action type and limit.
      
      For example, the number of times fw_activate has been performed on this
      device since the driver module was added or if the firmware activation
      was performed with or without reset.
      
      Add devlink notification on stats update.
      
      Expose devlink reload stats to the user through devlink dev get command.
      
      Examples:
      $ devlink dev show
      pci/0000:82:00.0:
        stats:
            reload:
              driver_reinit 2 fw_activate 1 fw_activate_no_reset 0
      pci/0000:82:00.1:
        stats:
            reload:
              driver_reinit 1 fw_activate 0 fw_activate_no_reset 0
      
      $ devlink dev show -jp
      {
          "dev": {
              "pci/0000:82:00.0": {
                  "stats": {
                      "reload": {
                          "driver_reinit": 2,
                          "fw_activate": 1,
                          "fw_activate_no_reset": 0
                      }
                  }
              },
              "pci/0000:82:00.1": {
                  "stats": {
                      "reload": {
                          "driver_reinit": 1,
                          "fw_activate": 0,
                          "fw_activate_no_reset": 0
                      }
                  }
              }
          }
      }
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      a254c264
    • M
      devlink: Add devlink reload limit option · dc64cc7c
      Moshe Shemesh 提交于
      Add reload limit to demand restrictions on reload actions.
      Reload limits supported:
      no_reset: No reset allowed, no down time allowed, no link flap and no
                configuration is lost.
      
      By default reload limit is unspecified and so no constraints on reload
      actions are required.
      
      Some combinations of action and limit are invalid. For example, driver
      can not reinitialize its entities without any downtime.
      
      The no_reset reload limit will have usecase in this patchset to
      implement restricted fw_activate on mlx5.
      
      Have the uapi parameter of reload limit ready for future support of
      multiselection.
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      dc64cc7c
    • M
      devlink: Add reload action option to devlink reload command · ccdf0721
      Moshe Shemesh 提交于
      Add devlink reload action to allow the user to request a specific reload
      action. The action parameter is optional, if not specified then devlink
      driver re-init action is used (backward compatible).
      Note that when required to do firmware activation some drivers may need
      to reload the driver. On the other hand some drivers may need to reset
      the firmware to reinitialize the driver entities. Therefore, the devlink
      reload command returns the actions which were actually performed.
      Reload actions supported are:
      driver_reinit: driver entities re-initialization, applying devlink-param
                     and devlink-resource values.
      fw_activate: firmware activate.
      
      command examples:
      $devlink dev reload pci/0000:82:00.0 action driver_reinit
      reload_actions_performed:
        driver_reinit
      
      $devlink dev reload pci/0000:82:00.0 action fw_activate
      reload_actions_performed:
        driver_reinit fw_activate
      Signed-off-by: NMoshe Shemesh <moshe@mellanox.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      ccdf0721
  2. 09 10月, 2020 1 次提交
  3. 07 10月, 2020 1 次提交
    • M
      arm/arm64: xen: Fix to convert percpu address to gfn correctly · 5a067711
      Masami Hiramatsu 提交于
      Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
      address conversion.
      
      In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
      to gfn by virt_to_gfn() macro. However, since the virt_to_gfn(v)
      assumes the given virtual address is in linear mapped kernel memory
      area, it can not convert the per-cpu memory if it is allocated on
      vmalloc area.
      
      This depends on CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK.
      If it is enabled, the first chunk of percpu memory is linear mapped.
      In the other case, that is allocated from vmalloc area. Moreover,
      if the first chunk of percpu has run out until allocating
      xen_vcpu_info, it will be allocated on the 2nd chunk, which is
      based on kernel memory or vmalloc memory (depends on
      CONFIG_NEED_PER_CPU_KM).
      
      Without this fix and kernel configured to use vmalloc area for
      the percpu memory, the Dom0 kernel will fail to boot with following
      errors.
      
      [    0.466172] Xen: initializing cpu0
      [    0.469601] ------------[ cut here ]------------
      [    0.474295] WARNING: CPU: 0 PID: 1 at arch/arm64/xen/../../arm/xen/enlighten.c:153 xen_starting_cpu+0x160/0x180
      [    0.484435] Modules linked in:
      [    0.487565] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4+ #4
      [    0.493895] Hardware name: Socionext Developer Box (DT)
      [    0.499194] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--)
      [    0.504836] pc : xen_starting_cpu+0x160/0x180
      [    0.509263] lr : xen_starting_cpu+0xb0/0x180
      [    0.513599] sp : ffff8000116cbb60
      [    0.516984] x29: ffff8000116cbb60 x28: ffff80000abec000
      [    0.522366] x27: 0000000000000000 x26: 0000000000000000
      [    0.527754] x25: ffff80001156c000 x24: fffffdffbfcdb600
      [    0.533129] x23: 0000000000000000 x22: 0000000000000000
      [    0.538511] x21: ffff8000113a99c8 x20: ffff800010fe4f68
      [    0.543892] x19: ffff8000113a9988 x18: 0000000000000010
      [    0.549274] x17: 0000000094fe0f81 x16: 00000000deadbeef
      [    0.554655] x15: ffffffffffffffff x14: 0720072007200720
      [    0.560037] x13: 0720072007200720 x12: 0720072007200720
      [    0.565418] x11: 0720072007200720 x10: 0720072007200720
      [    0.570801] x9 : ffff8000100fbdc0 x8 : ffff800010715208
      [    0.576182] x7 : 0000000000000054 x6 : ffff00001b790f00
      [    0.581564] x5 : ffff800010bbf880 x4 : 0000000000000000
      [    0.586945] x3 : 0000000000000000 x2 : ffff80000abec000
      [    0.592327] x1 : 000000000000002f x0 : 0000800000000000
      [    0.597716] Call trace:
      [    0.600232]  xen_starting_cpu+0x160/0x180
      [    0.604309]  cpuhp_invoke_callback+0xac/0x640
      [    0.608736]  cpuhp_issue_call+0xf4/0x150
      [    0.612728]  __cpuhp_setup_state_cpuslocked+0x128/0x2c8
      [    0.618030]  __cpuhp_setup_state+0x84/0xf8
      [    0.622192]  xen_guest_init+0x324/0x364
      [    0.626097]  do_one_initcall+0x54/0x250
      [    0.630003]  kernel_init_freeable+0x12c/0x2c8
      [    0.634428]  kernel_init+0x1c/0x128
      [    0.637988]  ret_from_fork+0x10/0x18
      [    0.641635] ---[ end trace d95b5309a33f8b27 ]---
      [    0.646337] ------------[ cut here ]------------
      [    0.651005] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:158!
      [    0.657697] Internal error: Oops - BUG: 0 [#1] SMP
      [    0.662548] Modules linked in:
      [    0.665676] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W         5.9.0-rc4+ #4
      [    0.673398] Hardware name: Socionext Developer Box (DT)
      [    0.678695] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--)
      [    0.684338] pc : xen_starting_cpu+0x178/0x180
      [    0.688765] lr : xen_starting_cpu+0x144/0x180
      [    0.693188] sp : ffff8000116cbb60
      [    0.696573] x29: ffff8000116cbb60 x28: ffff80000abec000
      [    0.701955] x27: 0000000000000000 x26: 0000000000000000
      [    0.707344] x25: ffff80001156c000 x24: fffffdffbfcdb600
      [    0.712718] x23: 0000000000000000 x22: 0000000000000000
      [    0.718107] x21: ffff8000113a99c8 x20: ffff800010fe4f68
      [    0.723481] x19: ffff8000113a9988 x18: 0000000000000010
      [    0.728863] x17: 0000000094fe0f81 x16: 00000000deadbeef
      [    0.734245] x15: ffffffffffffffff x14: 0720072007200720
      [    0.739626] x13: 0720072007200720 x12: 0720072007200720
      [    0.745008] x11: 0720072007200720 x10: 0720072007200720
      [    0.750390] x9 : ffff8000100fbdc0 x8 : ffff800010715208
      [    0.755771] x7 : 0000000000000054 x6 : ffff00001b790f00
      [    0.761153] x5 : ffff800010bbf880 x4 : 0000000000000000
      [    0.766534] x3 : 0000000000000000 x2 : 00000000deadbeef
      [    0.771916] x1 : 00000000deadbeef x0 : ffffffffffffffea
      [    0.777304] Call trace:
      [    0.779819]  xen_starting_cpu+0x178/0x180
      [    0.783898]  cpuhp_invoke_callback+0xac/0x640
      [    0.788325]  cpuhp_issue_call+0xf4/0x150
      [    0.792317]  __cpuhp_setup_state_cpuslocked+0x128/0x2c8
      [    0.797619]  __cpuhp_setup_state+0x84/0xf8
      [    0.801779]  xen_guest_init+0x324/0x364
      [    0.805683]  do_one_initcall+0x54/0x250
      [    0.809590]  kernel_init_freeable+0x12c/0x2c8
      [    0.814016]  kernel_init+0x1c/0x128
      [    0.817583]  ret_from_fork+0x10/0x18
      [    0.821226] Code: d0006980 f9427c00 cb000300 17ffffea (d4210000)
      [    0.827415] ---[ end trace d95b5309a33f8b28 ]---
      [    0.832076] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      [    0.839815] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
      Link: https://lore.kernel.org/r/160196697165.60224.17470743378683334995.stgit@devnote2Signed-off-by: NJuergen Gross <jgross@suse.com>
      5a067711
  4. 06 10月, 2020 4 次提交
  5. 05 10月, 2020 9 次提交
  6. 04 10月, 2020 6 次提交
  7. 03 10月, 2020 12 次提交