1. 03 3月, 2009 1 次提交
  2. 12 2月, 2009 4 次提交
  3. 16 1月, 2009 1 次提交
    • J
      x86: fix assumed to be contiguous leaf page tables for kmap_atomic region (take 2) · a3c6018e
      Jan Beulich 提交于
      Debugging and original patch from Nick Piggin <npiggin@suse.de>
      
      The early fixmap pmd entry inserted at the very top of the KVA is causing the
      subsequent fixmap mapping code to not provide physically linear pte pages over
      the kmap atomic portion of the fixmap (which relies on said property to
      calculate pte addresses).
      
      This has caused weird boot failures in kmap_atomic much later in the boot
      process (initial userspace faults) on a 32-bit PAE system with a larger number
      of CPUs (smaller CPU counts tend not to run over into the next page so don't
      show up the problem).
      
      Solve this by attempting to clear out the page table, and copy any of its
      entries to the new one. Also, add a bug if a nonlinear condition is encountered
      and can't be resolved, which might save some hours of debugging if this fragile
      scheme ever breaks again...
      
      Once we have such logic, we can also use it to eliminate the early ioremap
      trickery around the page table setup for the fixmap area. This also fixes
      potential issues with FIX_* entries sharing the leaf page table with the early
      ioremap ones getting discarded by early_ioremap_clear() and not restored by
      early_ioremap_reset(). It at once eliminates the temporary (and configuration,
      namely NR_CPUS, dependent) unavailability of early fixed mappings during the
      time the fixmap area page tables get constructed.
      
      Finally, also replace the hard coded calculation of the initial table space
      needed for the fixmap area with a proper one, allowing kernels configured for
      large CPU counts to actually boot.
      
      Based-on: Nick Piggin <npiggin@suse.de>
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a3c6018e
  4. 08 1月, 2009 1 次提交
    • A
      resource: allow MMIO exclusivity for device drivers · e8de1481
      Arjan van de Ven 提交于
      Device drivers that use pci_request_regions() (and similar APIs) have a
      reasonable expectation that they are the only ones accessing their device.
      As part of the e1000e hunt, we were afraid that some userland (X or some
      bootsplash stuff) was mapping the MMIO region that the driver thought it
      had exclusively via /dev/mem or via various sysfs resource mappings.
      
      This patch adds the option for device drivers to cause their reserved
      regions to the "banned from /dev/mem use" list, so now both kernel memory
      and device-exclusive MMIO regions are banned.
      NOTE: This is only active when CONFIG_STRICT_DEVMEM is set.
      
      In addition to the config option, a kernel parameter iomem=relaxed is
      provided for the cases where developers want to diagnose, in the field,
      drivers issues from userspace.
      Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      e8de1481
  5. 07 1月, 2009 2 次提交
    • J
      x86: smp.h move zap_low_mappings declartion to tlbflush.h · dacf7333
      Jaswinder Singh Rajput 提交于
      Impact: cleanup, moving NON-SMP stuff from smp.h
      Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dacf7333
    • G
      mm: show node to memory section relationship with symlinks in sysfs · c04fc586
      Gary Hade 提交于
      Show node to memory section relationship with symlinks in sysfs
      
      Add /sys/devices/system/node/nodeX/memoryY symlinks for all
      the memory sections located on nodeX.  For example:
      /sys/devices/system/node/node1/memory135 -> ../../memory/memory135
      indicates that memory section 135 resides on node1.
      
      Also revises documentation to cover this change as well as updating
      Documentation/ABI/testing/sysfs-devices-memory to include descriptions
      of memory hotremove files 'phys_device', 'phys_index', and 'state'
      that were previously not described there.
      
      In addition to it always being a good policy to provide users with
      the maximum possible amount of physical location information for
      resources that can be hot-added and/or hot-removed, the following
      are some (but likely not all) of the user benefits provided by
      this change.
      Immediate:
        - Provides information needed to determine the specific node
          on which a defective DIMM is located.  This will reduce system
          downtime when the node or defective DIMM is swapped out.
        - Prevents unintended onlining of a memory section that was
          previously offlined due to a defective DIMM.  This could happen
          during node hot-add when the user or node hot-add assist script
          onlines _all_ offlined sections due to user or script inability
          to identify the specific memory sections located on the hot-added
          node.  The consequences of reintroducing the defective memory
          could be ugly.
        - Provides information needed to vary the amount and distribution
          of memory on specific nodes for testing or debugging purposes.
      Future:
        - Will provide information needed to identify the memory
          sections that need to be offlined prior to physical removal
          of a specific node.
      
      Symlink creation during boot was tested on 2-node x86_64, 2-node
      ppc64, and 2-node ia64 systems.  Symlink creation during physical
      memory hot-add tested on a 2-node x86_64 system.
      Signed-off-by: NGary Hade <garyhade@us.ibm.com>
      Signed-off-by: NBadari Pulavarty <pbadari@us.ibm.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c04fc586
  6. 03 1月, 2009 1 次提交
  7. 02 1月, 2009 1 次提交
    • I
      x86: convert permanent_kmaps_init() from macro to inline · a9067d53
      Ingo Brueckl 提交于
      Impact: cleanup
      
      This compiler warning:
      
        arch/x86/mm/init_32.c:515: warning: unused variable 'pgd_base'
      
      triggers because permanent_kmaps_init() is a CPP macro in the
      !CONFIG_HIGHMEM case, that does not tell the compiler that the
      'pgd_base' parameter is used.
      
      Convert permanent_kmaps_init() (and set_highmem_pages_init()) to
      C inline functions - which gives the parameter a proper type and
      which gets rid of the compiler warning as well.
      Signed-off-by: NIngo Brueckl <ib@wupperonline.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a9067d53
  8. 18 12月, 2008 1 次提交
  9. 17 12月, 2008 2 次提交
  10. 31 10月, 2008 2 次提交
  11. 28 10月, 2008 1 次提交
  12. 16 10月, 2008 2 次提交
  13. 13 10月, 2008 1 次提交
    • J
      x86: add _PAGE_IOMAP pte flag for IO mappings · be43d728
      Jeremy Fitzhardinge 提交于
      Use one of the software-defined PTE bits to indicate that a mapping is
      intended for an IO address.  On native hardware this is irrelevent,
      since a physical address is a physical address.  But in a virtual
      environment, physical addresses are also virtualized, so there needs
      to be some way to distinguish between pseudo-physical addresses and
      actual hardware addresses; _PAGE_IOMAP indicates this intent.
      
      By default, __supported_pte_mask masks out _PAGE_IOMAP, so it doesn't
      even appear in the final pagetable.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      be43d728
  14. 12 10月, 2008 1 次提交
  15. 11 10月, 2008 3 次提交
  16. 15 9月, 2008 1 次提交
  17. 07 9月, 2008 1 次提交
  18. 05 9月, 2008 1 次提交
  19. 23 7月, 2008 1 次提交
  20. 18 7月, 2008 1 次提交
  21. 16 7月, 2008 1 次提交
  22. 11 7月, 2008 1 次提交
  23. 08 7月, 2008 9 次提交