1. 21 5月, 2012 4 次提交
  2. 08 5月, 2012 9 次提交
    • K
      Merge branch 'stable/autoballoon.v5.2' into stable/for-linus-3.5 · 4b3451ad
      Konrad Rzeszutek Wilk 提交于
      * stable/autoballoon.v5.2:
        xen/setup: update VA mapping when releasing memory during setup
        xen/setup: Combine the two hypercall functions - since they are quite similar.
        xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
        xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
        xen/p2m: An early bootup variant of set_phys_to_machine
        xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
        xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
        xen/p2m: Move code around to allow for better re-usage.
      4b3451ad
    • S
      xen: enter/exit lazy_mmu_mode around m2p_override calls · f62805f1
      Stefano Stabellini 提交于
      This patch is a significant performance improvement for the
      m2p_override: about 6% using the gntdev device.
      
      Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
      __flush_tlb_single if kmap_op != NULL.  Batching all the calls together
      is a great performance benefit because it means issuing one hypercall
      total rather than two hypercall per page.
      If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
      going to be batched together, otherwise they are issued one at a time.
      
      Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
      m2p_add/remove_override calls forces paravirt_lazy_mode to
      PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.
      
      However it is not safe to call arch_enter_lazy_mmu_mode if we are in
      interrupt context or if we are already in PARAVIRT_LAZY_MMU mode, so
      check for both conditions before doing so.
      
      Changes in v4:
      - rebased on 3.4-rc4: all the m2p_override users call gnttab_unmap_refs
      and gnttab_map_refs;
      - check whether we are in interrupt context and the lazy_mode we are in
      before calling arch_enter/leave_lazy_mmu_mode.
      
      Changes in v3:
      - do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
      can be called in interrupt context.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      [v5: s/int lazy/bool lazy/]
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      f62805f1
    • K
      xen/acpi/sleep: Enable ACPI sleep via the __acpi_os_prepare_sleep · 211063dc
      Konrad Rzeszutek Wilk 提交于
      Provide the registration callback to call in the Xen's
      ACPI sleep functionality. This means that during S3/S5
      we make a hypercall XENPF_enter_acpi_sleep with the
      proper PM1A/PM1B registers.
      
      Based of Ke Yu's <ke.yu@intel.com> initial idea.
      [ From http://xenbits.xensource.com/linux-2.6.18-xen.hg
      change c68699484a65 ]
      
      [v1: Added Copyright and license]
      [v2: Added check if PM1A/B the 16-bits MSB contain something. The spec
           only uses 16-bits but might have more in future]
      Signed-off-by: NLiang Tang <liang.tang@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      211063dc
    • L
      xen: implement IRQ_WORK_VECTOR handler · 1ff2b0c3
      Lin Ming 提交于
      Signed-off-by: NLin Ming <mlin@ss.pku.edu.cn>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      1ff2b0c3
    • B
      xen: implement apic ipi interface · f447d56d
      Ben Guthro 提交于
      Map native ipi vector to xen vector.
      Implement apic ipi interface with xen_send_IPI_one.
      Tested-by: NSteven Noonan <steven@uplinklabs.net>
      Signed-off-by: NBen Guthro <ben@guthro.net>
      Signed-off-by: NLin Ming <mlin@ss.pku.edu.cn>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      f447d56d
    • D
      xen/setup: update VA mapping when releasing memory during setup · 83d51ab4
      David Vrabel 提交于
      In xen_memory_setup(), if a page that is being released has a VA
      mapping this must also be updated.  Otherwise, the page will be not
      released completely -- it will still be referenced in Xen and won't be
      freed util the mapping is removed and this prevents it from being
      reallocated at a different PFN.
      
      This was already being done for the ISA memory region in
      xen_ident_map_ISA() but on many systems this was omitting a few pages
      as many systems marked a few pages below the ISA memory region as
      reserved in the e820 map.
      
      This fixes errors such as:
      
      (XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152
      (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17)
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      83d51ab4
    • K
      xen/setup: Combine the two hypercall functions - since they are quite similar. · 96dc08b3
      Konrad Rzeszutek Wilk 提交于
      They use the same set of arguments, so it is just the matter
      of using the proper hypercall.
      Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      96dc08b3
    • K
      xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM · 2e2fb754
      Konrad Rzeszutek Wilk 提交于
      When the Xen hypervisor boots a PV kernel it hands it two pieces
      of information: nr_pages and a made up E820 entry.
      
      The nr_pages value defines the range from zero to nr_pages of PFNs
      which have a valid Machine Frame Number (MFN) underneath it. The
      E820 mirrors that (with the VGA hole):
      BIOS-provided physical RAM map:
       Xen: 0000000000000000 - 00000000000a0000 (usable)
       Xen: 00000000000a0000 - 0000000000100000 (reserved)
       Xen: 0000000000100000 - 0000000080800000 (usable)
      
      The fun comes when a PV guest that is run with a machine E820 - that
      can either be the initial domain or a PCI PV guest, where the E820
      looks like the normal thing:
      
      BIOS-provided physical RAM map:
       Xen: 0000000000000000 - 000000000009e000 (usable)
       Xen: 000000000009ec00 - 0000000000100000 (reserved)
       Xen: 0000000000100000 - 0000000020000000 (usable)
       Xen: 0000000020000000 - 0000000020200000 (reserved)
       Xen: 0000000020200000 - 0000000040000000 (usable)
       Xen: 0000000040000000 - 0000000040200000 (reserved)
       Xen: 0000000040200000 - 00000000bad80000 (usable)
       Xen: 00000000bad80000 - 00000000badc9000 (ACPI NVS)
      ..
      With that overlaying the nr_pages directly on the E820 does not
      work as there are gaps and non-RAM regions that won't be used
      by the memory allocator. The 'xen_release_chunk' helps with that
      by punching holes in the P2M (PFN to MFN lookup tree) for those
      regions and tells us that:
      
      Freeing  20000-20200 pfn range: 512 pages freed
      Freeing  40000-40200 pfn range: 512 pages freed
      Freeing  bad80-badf4 pfn range: 116 pages freed
      Freeing  badf6-bae7f pfn range: 137 pages freed
      Freeing  bb000-100000 pfn range: 282624 pages freed
      Released 283999 pages of unused memory
      
      Those 283999 pages are subtracted from the nr_pages and are returned
      to the hypervisor. The end result is that the initial domain
      boots with 1GB less memory as the nr_pages has been subtracted by
      the amount of pages residing within the PCI hole. It can balloon up
      to that if desired using 'xl mem-set 0 8092', but the balloon driver
      is not always compiled in for the initial domain.
      
      This patch, implements the populate hypercall (XENMEM_populate_physmap)
      which increases the the domain with the same amount of pages that
      were released.
      
      The other solution (that did not work) was to transplant the MFN in
      the P2M tree - the ones that were going to be freed were put in
      the E820_RAM regions past the nr_pages. But the modifications to the
      M2P array (the other side of creating PTEs) were not carried away.
      As the hypervisor is the only one capable of modifying that and the
      only two hypercalls that would do this are: the update_va_mapping
      (which won't work, as during initial bootup only PFNs up to nr_pages
      are mapped in the guest) or via the populate hypercall.
      
      The end result is that the kernel can now boot with the
      nr_pages without having to subtract the 283999 pages.
      
      On a 8GB machine, with various dom0_mem= parameters this is what we get:
      
      no dom0_mem
      -Memory: 6485264k/9435136k available (5817k kernel code, 1136060k absent, 1813812k reserved, 2899k data, 696k init)
      +Memory: 7619036k/9435136k available (5817k kernel code, 1136060k absent, 680040k reserved, 2899k data, 696k init)
      
      dom0_mem=3G
      -Memory: 2616536k/9435136k available (5817k kernel code, 1136060k absent, 5682540k reserved, 2899k data, 696k init)
      +Memory: 2703776k/9435136k available (5817k kernel code, 1136060k absent, 5595300k reserved, 2899k data, 696k init)
      
      dom0_mem=max:3G
      -Memory: 2696732k/4281724k available (5817k kernel code, 1136060k absent, 448932k reserved, 2899k data, 696k init)
      +Memory: 2702204k/4281724k available (5817k kernel code, 1136060k absent, 443460k reserved, 2899k data, 696k init)
      
      And the 'xm list' or 'xl list' now reflect what the dom0_mem=
      argument is.
      Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
      [v2: Use populate hypercall]
      [v3: Remove debug printks]
      [v4: Simplify code]
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2e2fb754
    • K
      xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0 · ca118238
      Konrad Rzeszutek Wilk 提交于
      Otherwise we can get these meaningless:
      Freeing  bad80-badf4 pfn range: 0 pages freed
      
      We also can do this for the summary ones - no point of printing
      "Set 0 page(s) to 1-1 mapping"
      Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
      [v1: Extended to the summary printks]
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ca118238
  3. 18 4月, 2012 1 次提交
  4. 17 4月, 2012 1 次提交
  5. 16 4月, 2012 11 次提交
    • L
      Linux 3.4-rc3 · e816b57a
      Linus Torvalds 提交于
      e816b57a
    • L
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · 9a8e5d41
      Linus Torvalds 提交于
      Pull ARM fixes from Russell King:
       "Nothing too disasterous, the biggest thing being the removal of the
        regulator support for vcore in the AMBA driver; only one SoC was using
        this and it got broken during the last merge window, which then
        started causing problems for other people.  Mutual agreement was
        reached for it to be removed."
      
      * 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
        ARM: 7386/1: jump_label: fixup for rename to static_key
        ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE
        ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU
        ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus
        ARM: 7383/1: nommu: populate vectors page from paging_init
        ARM: 7381/1: nommu: fix typo in mm/Kconfig
        ARM: 7380/1: DT: do not add a zero-sized memory property
        ARM: 7379/1: DT: fix atags_to_fdt() second call site
        ARM: 7366/3: amba: Remove AMBA level regulator support
        ARM: 7377/1: vic: re-read status register before dispatching each IRQ handler
        ARM: 7368/1: fault.c: correct how the tsk->[maj|min]_flt gets incremented
      9a8e5d41
    • L
      x86-32: fix up strncpy_from_user() sign error · 12e993b8
      Linus Torvalds 提交于
      The 'max' range needs to be unsigned, since the size of the user address
      space is bigger than 2GB.
      
      We know that 'count' is positive in 'long' (that is checked in the
      caller), so we will truncate 'max' down to something that fits in a
      signed long, but before we actually do that, that comparison needs to be
      done in unsigned.
      
      Bug introduced in commit 92ae03f2 ("x86: merge 32/64-bit versions of
      'strncpy_from_user()' and speed it up").  On x86-64 you can't trigger
      this, since the user address space is much smaller than 63 bits, and on
      x86-32 it works in practice, since you would seldom hit the strncpy
      limits anyway.
      
      I had actually tested the corner-cases, I had only tested them on
      x86-64.  Besides, I had only worried about the case of a pointer *close*
      to the end of the address space, rather than really far away from it ;)
      
      This also changes the "we hit the user-specified maximum" to return
      'res', for the trivial reason that gcc seems to generate better code
      that way.  'res' and 'count' are the same in that case, so it really
      doesn't matter which one we return.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      12e993b8
    • R
      ARM: 7386/1: jump_label: fixup for rename to static_key · 708e5978
      Rabin Vincent 提交于
      c5905afb ("static keys: Introduce 'struct static_key'...") renamed
      struct jump_label_key to struct static_key.  Fixup ARM for this to
      eliminate these build warnings:
      
        include/linux/jump_label.h:113:2:
        warning: passing argument 1 of 'arch_static_branch' from incompatible pointer type
        include/asm/jump_label.h:17:82:
        note: expected 'struct jump_label_key *' but argument is of type 'struct static_key *'
      Signed-off-by: NRabin Vincent <rabin@rab.in>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      708e5978
    • J
      ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE · 078c0454
      Jonathan Austin 提交于
      Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE
      register states are not saved/restored at context switch. The default state
      of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the
      ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour
      when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing
      covert communication - eg between userspace tasks running inside chroot
      jails.
      
      This patch sets up TEECR in order to prevent user-space access to TEEHBR
      when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to
      access TEEHBR.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJonathan Austin <jonathan.austin@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      078c0454
    • W
      ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU · e5ab8580
      Will Deacon 提交于
      If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
      kernel then we will hang early during boot since the memory bank will
      have wrapped around to zero.
      
      This patch truncates memory banks for !LPAE configurations when the end
      address is not representable in 32 bits.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e5ab8580
    • L
      ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus · 9f855503
      Linus Walleij 提交于
      During booting of cpu1, there is a short window where cpu1
      is online, but not active where cpu1 is occupied by waiting
      to become active. If cpu0 then decides to schedule something
      on cpu1 and wait for it to complete, before cpu0 has set
      cpu1 active, we have a deadlock.
      
      Typically it's this CPU frequency transition that happens at
      this time, so let's just not wait for it to happen, it will
      happen whenever the CPU eventually comes online instead.
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@kernel.org
      Signed-off-by: NJonas Aaberg <jonas.aberg@stericsson.com>
      Reviewed-by: NRickard Andersson <rickard.andersson@stericsson.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9f855503
    • R
      PCI: Fix regression in pci_restore_state(), v3 · ebfc5b80
      Rafael J. Wysocki 提交于
      Commit 26f41062 ("PCI: check for pci bar restore completion and
      retry") attempted to address problems with PCI BAR restoration on
      systems where FLR had not been completed before pci_restore_state() was
      called, but it did that in an utterly wrong way.
      
      First off, instead of retrying the writes for the BAR registers only, it
      did that for all of the PCI config space of the device, including the
      status register (whose value after the write quite obviously need not be
      the same as the written one).  Second, it added arbitrary delay to
      pci_restore_state() even for systems where the PCI config space
      restoration was successful at first attempt.  Finally, the mdelay(10) it
      added to every iteration of the writing loop was way too much of a delay
      for any reasonable device.
      
      All of this actually caused resume failures for some devices on Mikko's
      system.
      
      To fix the regression, make pci_restore_state() only retry the writes
      for BAR registers and only wait if the first read from the register
      doesn't return the written value.  Additionaly, make it wait for 1 ms,
      instead of 10 ms, after every failing attempt to write into config
      space.
      Reported-by: NMikko Vinni <mmvinni@yahoo.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ebfc5b80
    • L
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 6c23b8e9
      Linus Torvalds 提交于
      Pull "ARM: a few more SoC fixes for 3.4-rc" from Olof Johansson:
       - A handful of warning and build fixes for Qualcomm MSM
       - Build/warning and bug fixes for Samsung Exynos
       - A fix from Rob Herring that removes misplaced interrupt-parent
         properties from a few device trees
       - A fix to OMAP dealing with cpufreq build errors, removing some of the
         offending code since it was redundant anyway
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: OMAP: clock: cleanup CPUfreq leftovers, fix build errors
        ARM: dts: remove blank interrupt-parent properties
        ARM: EXYNOS: Fix Kconfig dependencies for device tree enabled machine files
        ARM: EXYNOS: Remove broken config values for touchscren for NURI board
        ARM: EXYNOS: set fix xusbxti clock for NURI and Universal210 boards
        ARM: EXYNOS: fix regulator name for NURI board
        ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL
        ARM: msm: Fix section mismatches in proc_comm.c
        video: msm: Fix section mismatches in mddi.c
        arm: msm: trout: fix compile failure
        arm: msm: halibut: remove unneeded fixup
        ARM: EXYNOS: Add PDMA and MDMA physical base address defines
        ARM: S5PV210: Fix compiler warning in dma.c file
        ARM: EXYNOS: Fix compile error in exynos5250-cpufreq.c
        ARM: EXYNOS: Add missing definition for IRQ_I2S0
        ARM: S5PV210: fix unused LDO supply field from wm8994_pdata
      6c23b8e9
    • L
      Merge tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 218a8c2b
      Linus Torvalds 提交于
      Pull another round of sound fixes from Takashi Iwai:
       "A few regression fixes for Realtek HD-audio codecs, mainly specific to
        some laptop models."
      
      * tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: hda/realtek - Fix mem leak (and rid us of trailing whitespace).
        ALSA: hda/realtek - Add quirk for Mac Pro 5,1 machines
        ALSA: hda/realtek - Add a fixup entry for Acer Aspire 8940G
        ALSA: hda/realtek - Fix GPIO1 setup for Acer Aspire 4930 & co
        ALSA: hda/realtek - Add a few ALC882 model strings back
      218a8c2b
    • M
      SCSI: Fix error handling when no ULD is attached · 919f797a
      Martin K. Petersen 提交于
      Commit 18a4d0a2 ("[SCSI] Handle disk devices which can not process
      medium access commands") introduced a bug in which we would attempt to
      dereference the scsi driver even when the device had no ULD attached.
      
      Ensure that a driver is registered and make the driver accessor function
      more resilient to errors during device discovery.
      Reported-by: NElric Fu <elricfu1@gmail.com>
      Reported-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      919f797a
  6. 15 4月, 2012 4 次提交
  7. 14 4月, 2012 10 次提交