1. 23 Dec, 2011 1 commit
  2. 12 Dec, 2011 1 commit
  3. 11 Dec, 2011 1 commit
  4. 09 Dec, 2011 3 commits
    • Matt Fleming's avatar
      x86, efi: Make efi_call_phys_{prelog,epilog} CONFIG_RELOCATABLE-aware · 6d3e32e6
      Matt Fleming authored
      efi_call_phys_prelog() sets up a 1:1 mapping of the physical address
      range in swapper_pg_dir. Instead of replacing then restoring entries
      in swapper_pg_dir we should be using initial_page_table which already
      contains the 1:1 mapping.
      It's safe to blindly switch back to swapper_pg_dir in the epilog
      because the physical EFI routines are only called before
      efi_enter_virtual_mode(), e.g. before any user processes have been
      forked. Therefore, we don't need to track which pgd was in %cr3 when
      we entered the prelog.
      The previous code actually contained a bug because it assumed that the
      kernel was loaded at a physical address within the first 8MB of ram,
      usually at 0x100000. However, this isn't the case with a
      CONFIG_RELOCATABLE=y kernel which could have been loaded anywhere in
      the physical address space.
      Also delete the ancient (and bogus) comments about the page table
      being restored after the lock is released. There is no locking.
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Darrent Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/1323346250.3894.74.camel@mfleming-mobl1.ger.corp.intel.com
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
    • Youquan Song's avatar
      thp: add compound tail page _mapcount when mapped · b6999b19
      Youquan Song authored
      With the 3.2-rc kernel, IOMMU 2M pages in KVM works.  But when I tried
      to use IOMMU 1GB pages in KVM, I encountered an oops and the 1GB page
      failed to be used.
      The root cause is that 1GB page allocation calls gup_huge_pud() while 2M
      page calls gup_huge_pmd.  If compound pages are used and the page is a
      tail page, gup_huge_pmd() increases _mapcount to record tail page are
      mapped while gup_huge_pud does not do that.
      So when the mapped page is relesed, it will result in kernel oops
      because the page is not marked mapped.
      This patch add tail process for compound page in 1GB huge page which
      keeps the same process as 2M page.
      Reproduce like:
      1. Add grub boot option: hugepagesz=1G hugepages=8
      2. mount -t hugetlbfs -o pagesize=1G hugetlbfs /dev/hugepages
      3. qemu-kvm -m 2048 -hda os-kvm.img -cpu kvm64 -smp 4 -mem-path /dev/hugepages
      	-net none -device pci-assign,host=07:00.1
        kernel BUG at mm/swap.c:114!
        invalid opcode: 0000 [#1] SMP
        Call Trace:
        RIP  put_compound_page+0xd4/0x168
      Signed-off-by: default avatarYouquan Song <youquan.song@intel.com>
      Reviewed-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Matt Fleming's avatar
      x86, efi: Calling __pa() with an ioremap()ed address is invalid · e8c71062
      Matt Fleming authored
      If we encounter an efi_memory_desc_t without EFI_MEMORY_WB set
      in ->attribute we currently call set_memory_uc(), which in turn
      calls __pa() on a potentially ioremap'd address.
      On CONFIG_X86_32 this is invalid, resulting in the following
      oops on some machines:
        BUG: unable to handle kernel paging request at f7f22280
        IP: [<c10257b9>] reserve_ram_pages_type+0x89/0x210
        Call Trace:
         [<c104f8ca>] ? page_is_ram+0x1a/0x40
         [<c1025aff>] reserve_memtype+0xdf/0x2f0
         [<c1024dc9>] set_memory_uc+0x49/0xa0
         [<c19334d0>] efi_enter_virtual_mode+0x1c2/0x3aa
         [<c19216d4>] start_kernel+0x291/0x2f2
         [<c19211c7>] ? loglevel+0x1b/0x1b
         [<c19210bf>] i386_start_kernel+0xbf/0xc8
      A better approach to this problem is to map the memory region
      with the correct attributes from the start, instead of modifying
      it after the fact. The uncached case can be handled by
      ioremap_nocache() and the cached by ioremap_cache().
      Despite first impressions, it's not possible to use
      ioremap_cache() to map all cached memory regions on
      CONFIG_X86_64 because EFI_RUNTIME_SERVICES_DATA regions really
      don't like being mapped into the vmalloc space, as detailed in
      the following bug report,
      Therefore, we need to ensure that any EFI_RUNTIME_SERVICES_DATA
      regions are covered by the direct kernel mapping table on
      CONFIG_X86_64. To accomplish this we now map E820_RESERVED_EFI
      regions via the direct kernel mapping with the initial call to
      init_memory_mapping() in setup_arch(), whereas previously these
      regions wouldn't be mapped if they were after the last E820_RAM
      region until efi_ioremap() was called. Doing it this way allows
      us to delete efi_ioremap() completely.
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Huang Ying <huang.ying.caritas@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console-pimps.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  5. 08 Dec, 2011 1 commit
  6. 07 Dec, 2011 1 commit
  7. 06 Dec, 2011 7 commits
  8. 05 Dec, 2011 24 commits
  9. 04 Dec, 2011 1 commit
    • Linus Torvalds's avatar
      x86: Fix boot failures on older AMD CPU's · 8e8da023
      Linus Torvalds authored
      People with old AMD chips are getting hung boots, because commit
       ("x86, microcode, AMD: Add microcode revision to
      /proc/cpuinfo") moved the microcode detection too early into
      At that point we are *so* early in the booth that the exception tables
      haven't even been set up yet, so the whole
      	rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
      doesn't actually work: if the rdmsr does a GP fault (due to non-existant
      MSR register on older CPU's), we can't fix it up yet, and the boot fails.
      Fix it by simply moving the code to a slightly later point in the boot
      (init_amd() instead of early_init_amd()), since the kernel itself
      doesn't even really care about the microcode patchlevel at this point
      (or really ever: it's made available to user space in /proc/cpuinfo, and
      updated if you do a microcode load).
      Reported-tested-and-bisected-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Tested-by: default avatarBob Tracy <rct@gherkin.frus.com>
      Acked-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>