1. 15 Dec, 2011 2 commits
    • Konrad Rzeszutek Wilk's avatar
      xen/swiotlb: Use page alignment for early buffer allocation. · 63a74175
      Konrad Rzeszutek Wilk authored
      This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
      (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
      would fail with:
      
      ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
      ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
      ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO
      
      The issue was the Xen-SWIOTLB was allocated such as that the end of
      buffer was stradling a page (and also above 4GB). The fix was
      spotted by Kalev Leonid  which was to piggyback on git commit
      e79f86b2 "swiotlb: Use page alignment
      for early buffer allocation" which:
      
      	We could call free_bootmem_late() if swiotlb is not used, and
      	it will shrink to page alignment.
      
      	So alloc them with page alignment at first, to avoid lose two pages
      
      And doing that fixes the outstanding issue.
      
      CC: stable@kernel.org
      Suggested-by: default avatar"Kalev, Leonid" <Leonid.Kalev@ca.com>
      Reported-and-Tested-by: default avatar"Taylor, Neal E" <Neal.Taylor@ca.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      63a74175
    • Ian Campbell's avatar
      xen: only limit memory map to maximum reservation for domain 0. · d3db7281
      Ian Campbell authored
      d312ae87 "xen: use maximum reservation to limit amount of usable RAM"
      clamped the total amount of RAM to the current maximum reservation. This is
      correct for dom0 but is not correct for guest domains. In order to boot a guest
      "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
      future memory expansion the guest must derive max_pfn from the e820 provided by
      the toolstack and not the current maximum reservation (which can reflect only
      the current maximum, not the guest lifetime max). The existing algorithm
      already behaves this correctly if we do not artificially limit the maximum
      number of pages for the guest case.
      
      For a guest booted with maxmem=512, memory=128 this results in:
       [    0.000000] BIOS-provided physical RAM map:
       [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
       [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
      -[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
      -[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
      +[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
      ...
       [    0.000000] NX (Execute Disable) protection: active
       [    0.000000] DMI not present or invalid.
       [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
       [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
      -[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
      +[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
       [    0.000000] initial memory mapped : 0 - 027ff000
       [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
      -[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
      -[    0.000000]  0000000000 - 0008100000 page 4k
      -[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
      +[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
      +[    0.000000]  0000000000 - 0020800000 page 4k
      +[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
       [    0.000000] xen: setting RW the range 27e8000 - 27ff000
       [    0.000000] 0MB HIGHMEM available.
      -[    0.000000] 129MB LOWMEM available.
      -[    0.000000]   mapped low ram: 0 - 08100000
      -[    0.000000]   low ram: 0 - 08100000
      +[    0.000000] 520MB LOWMEM available.
      +[    0.000000]   mapped low ram: 0 - 20800000
      +[    0.000000]   low ram: 0 - 20800000
      
      With this change "xl mem-set <domain> 512M" will successfully increase the
      guest RAM (by reducing the balloon).
      
      There is no change for dom0.
      Reported-and-Tested-by: default avatarGeorge Shuklin <george.shuklin@gmail.com>
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Cc: stable@kernel.org
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      d3db7281
  2. 16 Nov, 2011 7 commits
  3. 08 Nov, 2011 2 commits
    • Linus Torvalds's avatar
      Linux 3.2-rc1 · 1ea6b8f4
      Linus Torvalds authored
      .. with new name.  Because nothing says "really solid kernel release"
      like naming it after an extinct animal that just happened to be in the
      news lately.
      1ea6b8f4
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap · 075cb105
      Linus Torvalds authored
      * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (31 commits)
        ARM: OMAP: Fix export.h or module.h includes
        ARM: OMAP: omap_device: Include linux/export.h
        ARM: OMAP2: Fix H4 matrix keyboard warning
        ARM: OMAP1: Remove unused omap-alsa.h
        ARM: OMAP1: Fix warnings about enabling 32 KiHz timer
        ARM: OMAP2+: timer: Remove omap_device_pm_latency
        ARM: OMAP2+: clock data: Remove redundant timer clkdev
        ARM: OMAP: Devkit8000: Remove double omap_mux_init_gpio
        ARM: OMAP: usb: musb: OMAP: Delete unused function
        MAINTAINERS: Update linux-omap git repository
        ARM: OMAP: change get_context_loss_count ret value to int
        ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properly
        ARM: OMAP4: hsmmc: Fix Pbias configuration on regulator OFF
        ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list
        ARM: OMAP: I2C: Fix omap_register_i2c_bus() return value on success
        ARM: OMAP: dmtimer: Include linux/module.h
        ARM: OMAP2+: l3-noc: Include linux/module.h
        ARM: OMAP2+: devices: Fixes for McPDM
        ARM: OMAP: Fix errors and warnings when building for one board
        ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only
        ...
      075cb105
  4. 07 Nov, 2011 29 commits