1. 28 Oct, 2008 8 commits
  2. 27 Oct, 2008 3 commits
    • Yinghai Lu's avatar
      x86: keep the /proc/meminfo page count correct · 3afa3949
      Yinghai Lu authored
      Impact: get correct page count in /proc/meminfo
      
      found page count in /proc/meminfo is nor correct on 1G system in VirtualBox 2.0.4
      
      # cat /proc/meminfo
      MemTotal:        1017508 kB
      MemFree:          822700 kB
      Buffers:            1456 kB
      Cached:            26632 kB
      SwapCached:            0 kB
      ...
      Hugepagesize:       2048 kB
      DirectMap4k:      4032 kB
      DirectMap2M:  18446744073709549568 kB
      
      with this patch get:
      ...
      DirectMap4k:      4032 kB
      DirectMap2M:   1044480 kB
      
      which is consistent to kernel_page_tables
      ---[ Low Kernel Mapping ]---
      0xffff880000000000-0xffff880000001000           4K     RW     PCD     GLB x  pte
      0xffff880000001000-0xffff88000009f000         632K     RW             GLB x  pte
      0xffff88000009f000-0xffff8800000a0000           4K     RW     PCD     GLB x  pte
      0xffff8800000a0000-0xffff880000200000        1408K     RW             GLB x  pte
      0xffff880000200000-0xffff88003fe00000        1020M     RW         PSE GLB x  pmd
      0xffff88003fe00000-0xffff88003fff0000        1984K     RW             GLB NX pte
      0xffff88003fff0000-0xffff880040000000          64K                           pte
      0xffff880040000000-0xffff888000000000         511G                           pud
      0xffff888000000000-0xffffc20000000000       58880G                           pgd
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3afa3949
    • Cliff Wickman's avatar
      x86/uv: memory allocation at initialization · ef020ab0
      Cliff Wickman authored
      Impact: on SGI UV platforms, fix boot crash
      
      UV initialization is currently called too late to call alloc_bootmem_pages().
      The current sequence is:
      
       start_kernel()
         mem_init()
           free_all_bootmem()           <--- discard of bootmem
         rest_init()
           kernel_init()
             smp_prepare_cpus()
             native_smp_prepare_cpus()
               uv_system_init()         <--- uses alloc_bootmem_pages()
      
      It should be calling kmalloc().
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ef020ab0
    • Chris Lalancette's avatar
      xen: fix Xen domU boot with batched mprotect · 9f32d21c
      Chris Lalancette authored
      Impact: fix guest kernel boot crash on certain configs
      
      Recent i686 2.6.27 kernels with a certain amount of memory (between
      736 and 855MB) have a problem booting under a hypervisor that supports
      batched mprotect (this includes the RHEL-5 Xen hypervisor as well as
      any 3.3 or later Xen hypervisor).
      
      The problem ends up being that xen_ptep_modify_prot_commit() is using
      virt_to_machine to calculate which pfn to update.  However, this only
      works for pages that are in the p2m list, and the pages coming from
      change_pte_range() in mm/mprotect.c are kmap_atomic pages.  Because of
      this, we can run into the situation where the lookup in the p2m table
      returns an INVALID_MFN, which we then try to pass to the hypervisor,
      which then (correctly) denies the request to a totally bogus pfn.
      
      The right thing to do is to use arbitrary_virt_to_machine, so that we
      can be sure we are modifying the right pfn.  This unfortunately
      introduces a performance penalty because of a full page-table-walk,
      but we can avoid that penalty for pages in the p2m list by checking if
      virt_addr_valid is true, and if so, just doing the lookup in the p2m
      table.
      
      The attached patch implements this, and allows my 2.6.27 i686 based
      guest with 768MB of memory to boot on a RHEL-5 hypervisor again.
      Thanks to Jeremy for the suggestions about how to fix this particular
      issue.
      Signed-off-by: default avatarChris Lalancette <clalance@redhat.com>
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Chris Lalancette <clalance@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9f32d21c
  3. 26 Oct, 2008 29 commits