1. 13 5月, 2015 2 次提交
  2. 15 4月, 2015 1 次提交
    • M
      s390/mm: Fix memory hotplug for unaligned standby memory · 8741ce6d
      Michael Holzheu 提交于
      Commit 27356f54 ("mm/hotplug: verify hotplug memory range")
      introduced a check that makes add_memory() only accept section size
      aligned memory.
      
      Therefore on z/VM systems, where standby memory is not aligned, no
      standby memory is registered at all.
      
      Example:
      
       #cp def store 3504M standby 2336M
       00: CP Q V STORE
       00: STORAGE = 3504M MAX = 6G INC = 8M STANDBY = 2336M RESERVED = 0
      
      For this setup the following error message is printed:
      
       Section-unaligned hotplug range: start 0xdb000000, size 0x92000000
      
      So fix this and register aligned memory in "sclp_cmd.c". This means
      that for the corner cases where the standby memory is not aligned we
      loose some memory.
      
      In order to inform the user about the potential loss of standby memory,
      we add a new message for each added standby block and print how
      much of the standby memory is usable, for example:
      
       sclp_cmd.4336b4: Standby memory at 0x50000000 (256M of 256M usable)
       sclp_cmd.4336b4: Standby memory at 0xb0000000 (256M of 256M usable)
       sclp_cmd.4336b4: Standby memory at 0xdb000000 (2048M of 2336M usable)
      
      We also ensure that a potential memory block that contains both "assigned"
      and "standby" memory cannot be setup offline.
      Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
      Reviewed-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8741ce6d
  3. 11 4月, 2014 1 次提交
  4. 01 4月, 2014 1 次提交
  5. 24 1月, 2014 1 次提交
  6. 16 12月, 2013 1 次提交
  7. 15 11月, 2013 2 次提交
  8. 30 9月, 2013 1 次提交
  9. 27 6月, 2013 2 次提交
  10. 02 5月, 2013 1 次提交
  11. 26 4月, 2013 1 次提交
    • H
      s390/memory hotplug: prevent offline of active memory increments · 94c16366
      Heiko Carstens 提交于
      In case a machine supports memory hotplug all active memory increments
      present at IPL time have been initialized with a "usecount" of 1.
      This is wrong if the memory increment size is larger than the memory
      section size of the memory hotplug code. If that is the case the
      usecount must be initialized with the number of memory sections that
      fit into one memory increment.
      Otherwise it is possible to put a memory increment into standby state
      even if there are still active sections.
      Afterwards addressing exceptions might happen which cause the kernel
      to panic.
      However even worse, if a memory increment was put into standby state
      and afterwards into active state again, it's contents would have been
      zeroed, leading to memory corruption.
      
      This was only an issue for machines that support standby memory and
      have at least 256GB memory.
      
      This is broken since commit fdb1bb15 "[S390] sclp/memory hotplug: fix
      initial usecount of increments".
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: stable@vger.kernel.org # 2.6.39+
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      94c16366
  12. 11 3月, 2013 1 次提交
  13. 14 2月, 2013 1 次提交
    • M
      s390/mm: implement software dirty bits · abf09bed
      Martin Schwidefsky 提交于
      The s390 architecture is unique in respect to dirty page detection,
      it uses the change bit in the per-page storage key to track page
      modifications. All other architectures track dirty bits by means
      of page table entries. This property of s390 has caused numerous
      problems in the past, e.g. see git commit ef5d437f
      "mm: fix XFS oops due to dirty pages without buffers on s390".
      
      To avoid future issues in regard to per-page dirty bits convert
      s390 to a fault based software dirty bit detection mechanism. All
      user page table entries which are marked as clean will be hardware
      read-only, even if the pte is supposed to be writable. A write by
      the user process will trigger a protection fault which will cause
      the user pte to be marked as dirty and the hardware read-only bit
      is removed.
      
      With this change the dirty bit in the storage key is irrelevant
      for Linux as a host, but the storage key is still required for
      KVM guests. The effect is that page_test_and_clear_dirty and the
      related code can be removed. The referenced bit in the storage
      key is still used by the page_test_and_clear_young primitive to
      provide page age information.
      
      For page cache pages of mappings with mapping_cap_account_dirty
      there will not be any change in behavior as the dirty bit tracking
      already uses read-only ptes to control the amount of dirty pages.
      Only for swap cache pages and pages of mappings without
      mapping_cap_account_dirty there can be additional protection faults.
      To avoid an excessive number of additional faults the mk_pte
      primitive checks for PageDirty if the pgprot value allows for writes
      and pre-dirties the pte. That avoids all additional faults for
      tmpfs and shmem pages until these pages are added to the swap cache.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      abf09bed
  14. 01 12月, 2012 1 次提交
    • J
      s390/pci: PCI hotplug support via SCLP · 7441b062
      Jan Glauber 提交于
      Add SCLP PCI configure/deconfigure and implement a PCI hotplug
      controller (s390_pci_hpc). The hotplug controller creates a slot
      for every PCI function in stand-by or configured state. The PCI
      functions are named after the PCI function ID (fid). By writing to
      the power attribute in /sys/bus/pci/slots/<fid>/power the PCI function
      is moved to stand-by or configured state. If moved to the configured
      state the device is automatically scanned by the s390 PCI layer.
      Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      7441b062
  15. 23 11月, 2012 1 次提交
  16. 14 6月, 2012 1 次提交
  17. 18 5月, 2012 1 次提交
  18. 16 5月, 2012 1 次提交
  19. 29 3月, 2012 1 次提交
  20. 24 3月, 2012 1 次提交
  21. 30 10月, 2011 1 次提交
  22. 24 8月, 2011 1 次提交
  23. 10 5月, 2011 1 次提交
  24. 24 3月, 2010 1 次提交
  25. 18 3月, 2010 1 次提交
  26. 16 12月, 2009 1 次提交
  27. 07 12月, 2009 1 次提交
  28. 16 6月, 2009 1 次提交
  29. 19 2月, 2009 1 次提交
  30. 25 12月, 2008 1 次提交
  31. 15 11月, 2008 1 次提交
  32. 01 8月, 2008 1 次提交
  33. 14 7月, 2008 2 次提交
  34. 26 1月, 2008 3 次提交