1. 10 Oct, 2008 16 commits
    • Ingo Molnar's avatar
      Merge branches 'core/iommu', 'x86/amd-iommu' and 'x86/iommu' into x86-v28-for-linus-phase3-B · 725c2581
      Ingo Molnar authored
      Conflicts:
      	arch/x86/kernel/pci-gart_64.c
      	include/asm-x86/dma-mapping.h
      725c2581
    • Ingo Molnar's avatar
      Merge branch 'linus' into x86/pat2 · 3dd392a4
      Ingo Molnar authored
      Conflicts:
      	arch/x86/mm/init_64.c
      3dd392a4
    • Suresh Siddha's avatar
      x86, cpa: make the kernel physical mapping initialization a two pass sequence, fix · b27a43c1
      Suresh Siddha authored
      Jeremy Fitzhardinge wrote:
      
      > I'd noticed that current tip/master hasn't been booting under Xen, and I
      > just got around to bisecting it down to this change.
      >
      > commit 065ae73c5462d42e9761afb76f2b52965ff45bd6
      > Author: Suresh Siddha <suresh.b.siddha@intel.com>
      >
      >    x86, cpa: make the kernel physical mapping initialization a two pass sequence
      >
      > This patch is causing Xen to fail various pagetable updates because it
      > ends up remapping pagetables to RW, which Xen explicitly prohibits (as
      > that would allow guests to make arbitrary changes to pagetables, rather
      > than have them mediated by the hypervisor).
      
      Instead of making init a two pass sequence, to satisfy the Intel's TLB
      Application note (developer.intel.com/design/processor/applnots/317080.pdf
      Section 6 page 26), we preserve the original page permissions
      when fragmenting the large mappings and don't touch the existing memory
      mapping (which satisfies Xen's requirements).
      
      Only open issue is: on a native linux kernel, we will go back to mapping
      the first 0-1GB kernel identity mapping as executable (because of the
      static mapping setup in head_64.S). We can fix this in a different
      patch if needed.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b27a43c1
    • Ingo Molnar's avatar
      x86, pat: cleanups · ad2cde16
      Ingo Molnar authored
      clean up recently added code to be more consistent with other x86 code.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ad2cde16
    • Suresh Siddha's avatar
      x86: fix pagetable init 64-bit breakage · 28dd033f
      Suresh Siddha authored
      Fix _end alignment check - can trigger a crash if _end happens to be
      on a page boundary.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      28dd033f
    • Suresh Siddha's avatar
      x86: track memtype for RAM in page struct · 9542ada8
      Suresh Siddha authored
      Track the memtype for RAM pages in page struct instead of using the
      memtype list. This avoids the explosion in the number of entries in
      memtype list (of the order of 20,000 with AGP) and makes the PAT
      tracking simpler.
      
      We are using PG_arch_1 bit in page->flags.
      
      We still use the memtype list for non RAM pages.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9542ada8
    • Suresh Siddha's avatar
      x86, cpa: srlz cpa(), global flush tlb after splitting big page and before doing cpa · ad5ca55f
      Suresh Siddha authored
      Do a global flush tlb after splitting the large page and before we do the
      actual change page attribute in the PTE.
      
      With out this, we violate the TLB application note, which says
          "The TLBs may contain both ordinary and large-page translations for
           a 4-KByte range of linear addresses. This may occur if software
           modifies the paging structures so that the page size used for the
           address range changes. If the two translations differ with respect
           to page frame or attributes (e.g., permissions), processor behavior
           is undefined and may be implementation-specific."
      
      And also serialize cpa() (for !DEBUG_PAGEALLOC which uses large identity
      mappings) using cpa_lock. So that we don't allow any other cpu, with stale
      large tlb entries change the page attribute in parallel to some other cpu
      splitting a large page entry along with changing the attribute.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: arjan@linux.intel.com
      Cc: venkatesh.pallipadi@intel.com
      Cc: jeremy@goop.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ad5ca55f
    • Suresh Siddha's avatar
      x86, cpa: remove cpa pool code · 8311eb84
      Suresh Siddha authored
      Interrupt context no longer splits large page in cpa(). So we can do away
      with cpa memory pool code.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: arjan@linux.intel.com
      Cc: venkatesh.pallipadi@intel.com
      Cc: jeremy@goop.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8311eb84
    • Suresh Siddha's avatar
      x86, cpa: no need to check alias for __set_pages_p/__set_pages_np · 55121b43
      Suresh Siddha authored
      No alias checking needed for setting present/not-present mapping. Otherwise,
      we may need to break large pages for 64-bit kernel text mappings (this adds to
      complexity if we want to do this from atomic context especially, for ex:
      with CONFIG_DEBUG_PAGEALLOC). Let's keep it simple!
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: arjan@linux.intel.com
      Cc: venkatesh.pallipadi@intel.com
      Cc: jeremy@goop.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      55121b43
    • Suresh Siddha's avatar
      x86, cpa: dont use large pages for kernel identity mapping with DEBUG_PAGEALLOC · 0b8fdcbc
      Suresh Siddha authored
      Don't use large pages for kernel identity mapping with DEBUG_PAGEALLOC.
      This will remove the need to split the large page for the
      allocated kernel page in the interrupt context.
      
      This will simplify cpa code(as we don't do the split any more from the
      interrupt context). cpa code simplication in the subsequent patches.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: arjan@linux.intel.com
      Cc: venkatesh.pallipadi@intel.com
      Cc: jeremy@goop.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0b8fdcbc
    • Suresh Siddha's avatar
      x86, cpa: make the kernel physical mapping initialization a two pass sequence · a2699e47
      Suresh Siddha authored
      In the first pass, kernel physical mapping will be setup using large or
      small pages but uses the same PTE attributes as that of the early
      PTE attributes setup by early boot code in head_[32|64].S
      
      After flushing TLB's, we go through the second pass, which setups the
      direct mapped PTE's with the appropriate attributes (like NX, GLOBAL etc)
      which are runtime detectable.
      
      This two pass mechanism conforms to the TLB app note which says:
      
      "Software should not write to a paging-structure entry in a way that would
       change, for any linear address, both the page size and either the page frame
       or attributes."
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: arjan@linux.intel.com
      Cc: venkatesh.pallipadi@intel.com
      Cc: jeremy@goop.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a2699e47
    • Suresh Siddha's avatar
      x86, cpa: remove USER permission from the very early identity mapping attribute · 3a85e770
      Suresh Siddha authored
      remove USER from the PTE/PDE attributes for the very early identity
      mapping. We overwrite these mappings with KERNEL attribute later
      in the boot. Just being paranoid here as there is no need for USER bit
      to be set.
      
      If this breaks something(don't know the history), then we can simply drop
      this change.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: arjan@linux.intel.com
      Cc: venkatesh.pallipadi@intel.com
      Cc: jeremy@goop.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3a85e770
    • Suresh Siddha's avatar
      x86, cpa: rename PTE attribute macros for kernel direct mapping in early boot · b2bc2731
      Suresh Siddha authored
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: arjan@linux.intel.com
      Cc: venkatesh.pallipadi@intel.com
      Cc: jeremy@goop.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b2bc2731
    • Linus Torvalds's avatar
      Merge phase #1 of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip · d403a648
      Linus Torvalds authored
      This merges phase 1 of the x86 tree, which is a collection of branches:
      
        x86/alternatives, x86/cleanups, x86/commandline, x86/crashdump,
        x86/debug, x86/defconfig, x86/doc, x86/exports, x86/fpu, x86/gart,
        x86/idle, x86/mm, x86/mtrr, x86/nmi-watchdog, x86/oprofile,
        x86/paravirt, x86/reboot, x86/sparse-fixes, x86/tsc, x86/urgent and
        x86/vmalloc
      
      and as Ingo says: "these are the easiest, purely independent x86 topics
      with no conflicts, in one nice Octopus merge".
      
      * 'x86-v28-for-linus-phase1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (147 commits)
        x86: mtrr_cleanup: treat WRPROT as UNCACHEABLE
        x86: mtrr_cleanup: first 1M may be covered in var mtrrs
        x86: mtrr_cleanup: print out correct type v2
        x86: trivial printk fix in efi.c
        x86, debug: mtrr_cleanup print out var mtrr before change it
        x86: mtrr_cleanup try gran_size to less than 1M, v3
        x86: mtrr_cleanup try gran_size to less than 1M, cleanup
        x86: change MTRR_SANITIZER to def_bool y
        x86, debug printouts: IOMMU setup failures should not be KERN_ERR
        x86: export set_memory_ro and set_memory_rw
        x86: mtrr_cleanup try gran_size to less than 1M
        x86: mtrr_cleanup prepare to make gran_size to less 1M
        x86: mtrr_cleanup safe to get more spare regs now
        x86_64: be less annoying on boot, v2
        x86: mtrr_cleanup hole size should be less than half of chunk_size, v2
        x86: add mtrr_cleanup_debug command line
        x86: mtrr_cleanup optimization, v2
        x86: don't need to go to chunksize to 4G
        x86_64: be less annoying on boot
        x86, olpc: fix endian bug in openfirmware workaround
        ...
      d403a648
    • Linus Torvalds's avatar
      PnP: move pnpacpi/pnpbios_init to after PCI init · ed458df4
      Linus Torvalds authored
      We already did that a long time ago for pnp_system_init, but
      pnpacpi_init and pnpbios_init remained as subsys_initcalls, and get
      linked into the kernel before the arch-specific routines that finalize
      the PCI resources (pci_subsys_init).
      
      This means that the PnP routines would either register their resources
      before the PCI layer could, or would be unable to check whether a PCI
      resource had already been registered.  Both are problematic.
      
      I wanted to do this before 2.6.27, but every time we change something
      like this, something breaks.  That said, _every_ single time we trust
      some firmware (like PnP tables) more than we trust the hardware itself
      (like PCI probing), the problems have been worse.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ed458df4
    • Linus Torvalds's avatar
      Merge branch 'upstream-2.6.28' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev · 82219fce
      Linus Torvalds authored
      * 'upstream-2.6.28' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        ata_piix: IDE Mode SATA patch for Intel Ibex Peak DeviceIDs
        libata-eh: clear UNIT ATTENTION after reset
        ata_piix: add Hercules EC-900 mini-notebook to ich_laptop short cable list
        libata: reorder ata_device to remove 8 bytes of padding on 64 bits
        [libata] pata_bf54x: Add proper PM operation
        pata_sil680: convert CONFIG_PPC_MERGE to CONFIG_PPC
        libata: Implement disk shock protection support
        [libata] Introduce ata_id_has_unload()
        PATA: RPC now selects HAVE_PATA_PLATFORM for pata platform driver
        ata_piix: drop merged SCR access and use slave_link instead
        libata: implement slave_link
        libata: misc updates to prepare for slave link
        libata: reimplement link iterator
        libata: make SCR access ops per-link
      82219fce
  2. 09 Oct, 2008 12 commits
  3. 08 Oct, 2008 3 commits
  4. 07 Oct, 2008 7 commits
  5. 06 Oct, 2008 2 commits
    • Linus Torvalds's avatar
      Linux 2.6.27-rc9 · 4330ed8e
      Linus Torvalds authored
      4330ed8e
    • Mathieu Desnoyers's avatar
      Marker depmod fix core kernel list · 87f3b6b6
      Mathieu Desnoyers authored
      * Theodore Ts'o (tytso@mit.edu) wrote:
      >
      > I've been playing with adding some markers into ext4 to see if they
      > could be useful in solving some problems along with Systemtap.  It
      > appears, though, that as of 2.6.27-rc8, markers defined in code which is
      > compiled directly into the kernel (i.e., not as modules) don't show up
      > in Module.markers:
      >
      > kvm_trace_entryexit arch/x86/kvm/kvm-intel  %u %p %u %u %u %u %u %u
      > kvm_trace_handler arch/x86/kvm/kvm-intel  %u %p %u %u %u %u %u %u
      > kvm_trace_entryexit arch/x86/kvm/kvm-amd  %u %p %u %u %u %u %u %u
      > kvm_trace_handler arch/x86/kvm/kvm-amd  %u %p %u %u %u %u %u %u
      >
      > (Note the lack of any of the kernel_sched_* markers, and the markers I
      > added for ext4_* and jbd2_* are missing as wel.)
      >
      > Systemtap apparently depends on in-kernel trace_mark being recorded in
      > Module.markers, and apparently it's been claimed that it used to be
      > there.  Is this a bug in systemtap, or in how Module.markers is getting
      > built?   And is there a file that contains the equivalent information
      > for markers located in non-modules code?
      
      I think the problem comes from "markers: fix duplicate modpost entry"
      (commit d35cb360)
      
      Especially :
      
        -   add_marker(mod, marker, fmt);
        +   if (!mod->skip)
        +     add_marker(mod, marker, fmt);
          }
          return;
         fail:
      
      Here is a fix that should take care if this problem.
      
      Thanks for the bug report!
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Tested-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      CC: Greg KH <greg@kroah.com>
      CC: David Smith <dsmith@redhat.com>
      CC: Roland McGrath <roland@redhat.com>
      CC: Sam Ravnborg <sam@ravnborg.org>
      CC: Wenji Huang <wenji.huang@oracle.com>
      CC: Takashi Nishiie <t-nishiie@np.css.fujitsu.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      87f3b6b6