1. 02 2月, 2017 1 次提交
  2. 01 12月, 2016 1 次提交
    • N
      powerpc/pseries: Use lmb_is_removable() to check removability · 2db029ef
      Nathan Fontenot 提交于
      We should be using lmb_is_removable() to validate that enough LMBs
      are available to remove when doing a remove by count. This will check
      that the LMB is owned by the system and it is considered removable.
      This patch also adds a pr_info() notification to report the LMB count
      to remove was not satisfied.
      
      What we do now is just check that there are enough LMBs owned by the
      system when validating there are enough LMBs to remove. This can
      lead to situations where there are enough LMBs owned by the system
      but not enough that are considered removable. This results in having
      to bail out of the remove operation instead of just failing the request
      that we should have known wouldn't succeed.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      2db029ef
  3. 09 8月, 2016 1 次提交
    • A
      powerpc: Fix unused function warning 'lmb_to_memblock' · 9dc51281
      Alastair D'Silva 提交于
      This patch fixes the following warning:
      arch/powerpc/platforms/pseries/hotplug-memory.c:323:29: error: 'lmb_to_memblock' defined but not used [-Werror=unused-function]
      static struct memory_block *lmb_to_memblock(struct of_drconf_cell *lmb)
                                 ^~~~~~~~~~~~~~~
      
      The only consumer of this function is 'dlpar_remove_lmb', which is
      enabled with CONFIG_MEMORY_HOTREMOVE, so move it into the same
      ifdef block.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      9dc51281
  4. 15 7月, 2016 4 次提交
  5. 11 4月, 2016 2 次提交
    • N
      powerpc/pseries: Update LMB associativity index during DLPAR add/remove · bdf5fc63
      Nathan Fontenot 提交于
      The associativity array index specified for a LMB in the device tree,
      /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory, needs to be updated
      prior to DLPAR adding a LMB and after DLPAR removing a LMB.
      
      Without doing this step in the DLPAR add process a LMB could be configured
      with the incorrect affinity. For a LMB that was not present at boot the
      affinity index is set to 0xffffffff, which defaults to adding the LMB to
      the first online node since the index is not a valid value. Or, the
      affinity index could contain a stale value if the LMB was present at boot
      but later DLPAR removed and is being DLPAR added back to the system.
      
      This patch adds a step in the DLPAR add flow to look up the associativity
      index for a LMB prior to adding a LMB and setting the associativity to
      0xffffffff when a LMB is removed.
      
      This patch also modifies the DLPAR add/remove flow to no longer do a single
      update of the device tree property after all of the requested DLPAR
      operations are complete and now does a property update during the add
      or remove of each LMB.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      bdf5fc63
    • N
      powerpc/pseries: Refactor dlpar_add_lmb() code · 4a4bdfea
      Nathan Fontenot 提交于
      Re-factor dlpar_lmb_add() routine by moving the validation of the lmb
      flags and the acquireing of the DRC to a wrapper around the work to add
      the memory to the system. This is done to make handling of errors
      during the addition of the memory easier and to facilitate the upcoming
      addition of updating the lmb's affinity prior to adding the memory.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      4a4bdfea
  6. 18 8月, 2015 1 次提交
  7. 15 4月, 2015 1 次提交
  8. 14 4月, 2015 1 次提交
  9. 17 3月, 2015 3 次提交
    • N
      powerpc/pseries: Implement memory hotplug remove in the kernel · 51925fb3
      Nathan Fontenot 提交于
      This patch adds the ability to do memory hotplug remove in the kernel.
      
      Currently the operation to hotplug remove memory is handled by the drmgr
      command which performs the operation by performing some work in user-space
      and making requests to the kernel to handle other pieces. By moving all
      of the work to the kernel we can do the remove faster, and provide a common
      code path to do memory hotplug for both the PowerVM and PowerKVM environments.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      51925fb3
    • N
      powerpc/pseries: Implement memory hotplug add in the kernel · 5f97b2a0
      Nathan Fontenot 提交于
      This patch adds the ability to do memory hotplug add in the kernel.
      
      Currently the operation to hotplug add memory is handled by the drmgr
      command which performs the operation by performing some work in user-space
      and making requests to the kernel to handle other pieces. By moving all
      of the work to the kernel we can do the add faster, and provide a common
      code path to do memory hotplug for both the PowerVM and PowerKVM environments.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5f97b2a0
    • N
      powerpc/pseries: Create new device hotplug entry point · 999e2dad
      Nathan Fontenot 提交于
      The current hotplug (or dlpar) of devices (the process is generally the
      same for memory, cpu, and pci) on PowerVM systems is initiated
      from the HMC, which communicates the request to the partitions through
      the RSCT framework. The RSCT framework then invokes the drmgr command.
      The drmgr command performs the hotplug operation by doing some pieces,
      such as most of the rtas calls and device tree parsing, in userspace
      and make requests to the kernel to online/offline the device, update the
      device tree and add/remove the device.
      
      For PowerKVM the approach for device hotplug is to follow what is currently
      being done for pci hotplug. A hotplug request is initiated from the host.
      QEMU then generates an EPOW interrupt to the guest which causes the guest
      to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
      returns a rtas hotplug event to the guest.
      
      Please note that the current pci hotplug path for PowerKVM involves the
      kernel receiving the rtas hotplug event, passing it to rtas_errd in
      userspace, and having rtas_errd invoke drmgr. The drmgr command then
      handles the request as described above for PowerVM systems.
      
      There is no need for this circuitous route, we should just handle the entire
      hotplug of devices in the kernel. What I am planning is to enable this
      by moving the code to handle hotplug from drmgr into the kernel to
      provide a single path for handling device hotplug for both PowerVM and
      PowerKVM systems. This patch provides the common iframework and entry point.
      For PowerKVM a future update to the kernel rtas code will recognize rtas
      hotplug events returned from rtas,check-exception calls and use the common
      entry point to handle hotplug of the device.
      
      For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
      used by the drmgr command to initiate hotplug requests. In order to do
      this a string of the format "<resource> <action> <id_type> <id>" is
      written to this file. The string consists of a resource (cpu, memory, pci,
      phb), an action (add or remove), an id_type (count, drc index, drc name),
      and the corresponding id. The kernel will parse the string and create a
      rtas hotplug section that can be passed to the common entry point for
      handling hotplug requests.
      
      It should be noted that there is no chance of updating how we receive
      hotplug (dlpar) requests from the HMC on PowerVM systems.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      999e2dad
  10. 25 11月, 2014 1 次提交
    • G
      of/reconfig: Always use the same structure for notifiers · f5242e5a
      Grant Likely 提交于
      The OF_RECONFIG notifier callback uses a different structure depending
      on whether it is a node change or a property change. This is silly, and
      not very safe. Rework the code to use the same data structure regardless
      of the type of notifier.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
      Cc: <linuxppc-dev@lists.ozlabs.org>
      f5242e5a
  11. 05 11月, 2014 1 次提交
  12. 25 9月, 2014 1 次提交
  13. 09 9月, 2014 1 次提交
  14. 26 8月, 2014 1 次提交
  15. 13 8月, 2014 1 次提交
    • G
      powerpc/pseries: Failure on removing device node · f1b3929c
      Gavin Shan 提交于
      While running command "drmgr -c phb -r -s 'PHB 528'", following
      backtrace jumped out because the target device node isn't marked
      with OF_DETACHED by of_detach_node(), which caused by error
      returned from memory hotplug related reconfig notifier when
      disabling CONFIG_MEMORY_HOTREMOVE. The patch fixes it.
      
      ERROR: Bad of_node_put() on /pci@800000020000210/ethernet@0
      CPU: 14 PID: 2252 Comm: drmgr Tainted: G        W     3.16.0+ #427
      Call Trace:
      [c000000012a776a0] [c000000000013d9c] .show_stack+0x88/0x148 (unreliable)
      [c000000012a77750] [c00000000083cd34] .dump_stack+0x7c/0x9c
      [c000000012a777d0] [c0000000006807c4] .of_node_release+0x58/0xe0
      [c000000012a77860] [c00000000038a7d0] .kobject_release+0x174/0x1b8
      [c000000012a77900] [c00000000038a884] .kobject_put+0x70/0x78
      [c000000012a77980] [c000000000681680] .of_node_put+0x28/0x34
      [c000000012a77a00] [c000000000681ea8] .__of_get_next_child+0x64/0x70
      [c000000012a77a90] [c000000000682138] .of_find_node_by_path+0x1b8/0x20c
      [c000000012a77b40] [c000000000051840] .ofdt_write+0x308/0x688
      [c000000012a77c20] [c000000000238430] .proc_reg_write+0xb8/0xd4
      [c000000012a77cd0] [c0000000001cbeac] .vfs_write+0xec/0x1f8
      [c000000012a77d70] [c0000000001cc3b0] .SyS_write+0x58/0xa0
      [c000000012a77e30] [c00000000000a064] syscall_exit+0x0/0x98
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f1b3929c
  16. 24 7月, 2014 1 次提交
    • G
      of: Reorder device tree changes and notifiers · 259092a3
      Grant Likely 提交于
      Currently, devicetree reconfig notifiers get emitted before the change
      is applied to the tree, but that behaviour is problematic if the
      receiver wants the determine the new state of the tree. The current
      users don't care, but the changeset code to follow will be making
      multiple changes at once. Reorder notifiers to get emitted after the
      change has been applied to the tree so that callbacks see the new tree
      state.
      
      At the same time, fixup the existing callbacks to expect the new order.
      There are a few callbacks that compare the old and new values of a
      changed property. Put both property pointers into the of_prop_reconfig
      structure.
      
      The current notifiers also allow the notifier callback to fail and
      cancel the change to the tree, but that feature isn't actually used.
      It really isn't valid to ignore a tree modification provided by firmware
      anyway, so remove the ability to cancel a change to the tree.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Cc: Nathan Fontenot <nfont@austin.ibm.com>
      259092a3
  17. 05 6月, 2014 1 次提交
  18. 28 4月, 2014 1 次提交
    • L
      powerpc/pseries: Protect remove_memory() with device hotplug lock · 42dbfc86
      Li Zhong 提交于
      While testing memory hot-remove, I found following dead lock:
      
      Process #1141 is drmgr, trying to remove some memory, i.e. memory499.
      It holds the memory_hotplug_mutex, and blocks when trying to remove file
      "online" under dir memory499, in kernfs_drain(), at
              wait_event(root->deactivate_waitq,
                         atomic_read(&kn->active) == KN_DEACTIVATED_BIAS);
      
      Process #1120 is trying to online memory499 by
         echo 1 > memory499/online
      
      In .kernfs_fop_write, it uses kernfs_get_active() to increase
      &kn->active, thus blocking process #1141. While itself is blocked later
      when trying to acquire memory_hotplug_mutex, which is held by process
      
      The backtrace of both processes are shown below:
      
      [<c000000001b18600>] 0xc000000001b18600
      [<c000000000015044>] .__switch_to+0x144/0x200
      [<c000000000263ca4>] .online_pages+0x74/0x7b0
      [<c00000000055b40c>] .memory_subsys_online+0x9c/0x150
      [<c00000000053cbe8>] .device_online+0xb8/0x120
      [<c00000000053cd04>] .online_store+0xb4/0xc0
      [<c000000000538ce4>] .dev_attr_store+0x64/0xa0
      [<c00000000030f4ec>] .sysfs_kf_write+0x7c/0xb0
      [<c00000000030e574>] .kernfs_fop_write+0x154/0x1e0
      [<c000000000268450>] .vfs_write+0xe0/0x260
      [<c000000000269144>] .SyS_write+0x64/0x110
      [<c000000000009ffc>] syscall_exit+0x0/0x7c
      
      [<c000000001b18600>] 0xc000000001b18600
      [<c000000000015044>] .__switch_to+0x144/0x200
      [<c00000000030be14>] .__kernfs_remove+0x204/0x300
      [<c00000000030d428>] .kernfs_remove_by_name_ns+0x68/0xf0
      [<c00000000030fb38>] .sysfs_remove_file_ns+0x38/0x60
      [<c000000000539354>] .device_remove_attrs+0x54/0xc0
      [<c000000000539fd8>] .device_del+0x158/0x250
      [<c00000000053a104>] .device_unregister+0x34/0xa0
      [<c00000000055bc14>] .unregister_memory_section+0x164/0x170
      [<c00000000024ee18>] .__remove_pages+0x108/0x4c0
      [<c00000000004b590>] .arch_remove_memory+0x60/0xc0
      [<c00000000026446c>] .remove_memory+0x8c/0xe0
      [<c00000000007f9f4>] .pseries_remove_memblock+0xd4/0x160
      [<c00000000007fcfc>] .pseries_memory_notifier+0x27c/0x290
      [<c0000000008ae6cc>] .notifier_call_chain+0x8c/0x100
      [<c0000000000d858c>] .__blocking_notifier_call_chain+0x6c/0xe0
      [<c00000000071ddec>] .of_property_notify+0x7c/0xc0
      [<c00000000071ed3c>] .of_update_property+0x3c/0x1b0
      [<c0000000000756cc>] .ofdt_write+0x3dc/0x740
      [<c0000000002f60fc>] .proc_reg_write+0xac/0x110
      [<c000000000268450>] .vfs_write+0xe0/0x260
      [<c000000000269144>] .SyS_write+0x64/0x110
      [<c000000000009ffc>] syscall_exit+0x0/0x7c
      
      This patch uses lock_device_hotplug() to protect remove_memory() called
      in pseries_remove_memblock(), which is also stated before function
      remove_memory():
      
       * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
       * and online/offline operations before this call, as required by
       * try_offline_node().
       */
      void __ref remove_memory(int nid, u64 start, u64 size)
      
      With this lock held, the other process(#1120 above) trying to online the
      memory block will retry the system call when calling
      lock_device_hotplug_sysfs(), and finally find No such device error.
      Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      42dbfc86
  19. 07 3月, 2014 1 次提交
    • N
      powerpc/pseries: Use remove_memory() to remove memory · 9ac8cde9
      Nathan Fontenot 提交于
      The memory remove code for powerpc/pseries should call remove_memory()
      so that we are holding the hotplug_memory lock during memory remove
      operations.
      
      This patch updates the memory node remove handler to call remove_memory()
      and adds a ppc_md.remove_memory() entry to handle pseries specific work
      that is called from arch_remove_memory().
      
      During memory remove in pseries_remove_memblock() we have to stay with
      removing memory one section at a time. This is needed because of how memory
      resources are handled. During memory add for pseries (via the probe file in
      sysfs) we add memory one section at a time which gives us a memory resource
      for each section. Future patches will aim to address this so will not have
      to remove memory one section at a time.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      9ac8cde9
  20. 10 10月, 2013 1 次提交
    • R
      powerpc: add explicit OF includes · 26a2056e
      Rob Herring 提交于
      When removing prom.h include by of.h, several OF headers will no longer
      be implicitly included. Add explicit includes of of_*.h as needed.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Acked-by: NGrant Likely <grant.likely@linaro.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Anatolij Gustschin <agust@denx.de>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: linuxppc-dev@lists.ozlabs.org
      26a2056e
  21. 30 4月, 2013 1 次提交
  22. 15 11月, 2012 1 次提交
  23. 11 10月, 2012 2 次提交
  24. 09 10月, 2012 1 次提交
    • Y
      memory-hotplug: suppress "Trying to free nonexistent resource... · d760afd4
      Yasuaki Ishimatsu 提交于
      memory-hotplug: suppress "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning
      
      When our x86 box calls __remove_pages(), release_mem_region() shows many
      warnings.  And x86 box cannot unregister iomem_resource.
      
        "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>"
      
      release_mem_region() has been changed to be called in each
      PAGES_PER_SECTION by commit de7f0cba ("memory hotplug: release
      memory regions in PAGES_PER_SECTION chunks").  Because powerpc registers
      iomem_resource in each PAGES_PER_SECTION chunk.  But when I hot add
      memory on x86 box, iomem_resource is register in each _CRS not
      PAGES_PER_SECTION chunk.  So x86 box unregisters iomem_resource.
      
      The patch fixes the problem.
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Jiang Liu <liuj97@gmail.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Dave Hansen <dave@linux.vnet.ibm.com>
      Cc: Nathan Fontenot <nfont@austin.ibm.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d760afd4
  25. 12 7月, 2011 1 次提交
    • B
      powerpc/mm: Fix memory_block_size_bytes() for non-pseries · 770e1ac5
      Benjamin Herrenschmidt 提交于
      Just compiling pseries in the kernel causes it to override
      memory_block_size_bytes() regardless of what is the runtime
      platform.
      
      This cleans up the implementation of that function, fixing
      a bug or two while at it, so that it's harmless (and potentially
      useful) for other platforms. Without this, bugs in that code
      would trigger a WARN_ON() in drivers/base/memory.c when
      booting some different platforms.
      
      If/when we have another platform supporting memory hotplug we
      might want to either move that out to a generic place or
      make it a ppc_md. callback.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      770e1ac5
  26. 29 6月, 2011 1 次提交
  27. 04 2月, 2011 1 次提交
  28. 23 7月, 2010 1 次提交
  29. 14 7月, 2010 1 次提交
  30. 28 4月, 2010 1 次提交
  31. 10 2月, 2009 1 次提交
  32. 21 10月, 2008 1 次提交
  33. 10 10月, 2008 1 次提交