1. 15 10月, 2015 12 次提交
  2. 12 10月, 2015 2 次提交
  3. 09 10月, 2015 2 次提交
  4. 06 10月, 2015 2 次提交
  5. 05 10月, 2015 6 次提交
  6. 02 10月, 2015 2 次提交
  7. 01 10月, 2015 6 次提交
    • M
      powerpc: Add ppc64le_defconfig · 2adc48a6
      Michael Ellerman 提交于
      Based directly on ppc64_defconfig using merge_config.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      2adc48a6
    • A
      powerpc/mm: Add virt_to_pfn and use this instead of opencoding · 65d3223a
      Aneesh Kumar K.V 提交于
      This add helper virt_to_pfn and remove the opencoded usage of the
      same.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      65d3223a
    • M
      powerpc/vdso: Avoid link stack corruption in __get_datapage() · c974809a
      Michael Neuling 提交于
      powerpc has a link register (lr) used for calling functions. We "bl
      <func>" to call a function, and "blr" to return back to the call site.
      
      The lr is only a single register, so if we call another function from
      inside this function (ie. nested calls), software must save away the
      lr on the software stack before calling the new function. Before
      returning (ie. before the "blr"), the lr is restored by software from
      the software stack.
      
      This makes branch prediction quite difficult for the processor as it
      will only know the branch target just before the "blr".
      
      To help with this, modern powerpc processors keep a (non-architected)
      hardware stack of lr called a "link stack". When a "bl <func>" is
      run, the lr is pushed onto this stack. When a "blr" is called, the
      branch predictor pops the lr value from the top of the link stack, and
      uses it to predict the branch target. Hence the processor pipeline
      knows a lot earlier the branch target.
      
      This works great but there are some cases where you call "bl" but
      without a matching "blr". Once such case is when trying to determine
      the program counter (which can't be read directly). Here you "bl+4;
      mflr" to get the program counter. If you do this, the link stack will
      get out of sync with reality, causing the branch predictor to
      mis-predict subsequent function returns.
      
      To avoid this, modern micro-architectures have a special case of bl.
      Using the form "bcl 20,31,+4", ensures the processor doesn't push to
      the link stack.
      
      The 32 and 64 bit variants of __get_datapage() use a "bl; mflr" to
      determine the loaded address of the VDSO. The current versions of
      these attempt to use this special bl variant.
      
      Unfortunately they use +8 rather than the required +4. Hence the
      current code results in the link stack getting out of sync with
      reality and hence the resulting performance degradation.
      
      This patch moves it to bcl+4 by moving __kernel_datapage_offset out of
      __get_datapage().
      
      With this patch, running a gettimeofday() (which uses
      __get_datapage()) microbenchmark we get a decent bump in performance
      on POWER7/8.
      
      For the benchmark in tools/testing/selftests/powerpc/benchmarks/gettimeofday.c
        POWER8:
          64bit gets ~4% improvement
          32bit gets ~9% improvement
        POWER7:
          64bit gets ~7% improvement
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Reported-by: NAaron Sawdey <sawdey@us.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c974809a
    • M
      powerpc/slb: Use a local to avoid multiple calls to get_slb_shadow() · 26cd835e
      Michael Ellerman 提交于
      For no reason other than it looks ugly.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      26cd835e
    • A
      powerpc/slb: Define an enum for the bolted indexes · 1d15010c
      Anshuman Khandual 提交于
      This patch defines macros for the three bolted SLB indexes we use.
      Switch the functions that take the indexes as an argument to use the
      enum.
      Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      1d15010c
    • M
      powerpc/vdso: Emit GNU & SysV hashes · 787b393c
      Michael Ellerman 提交于
      Andy Lutomirski says:
      
        Some dynamic loaders may be slightly faster if a GNU hash is
        available.
      
        This is unlikely to have any measurable effect on the time it takes
        to resolve vdso symbols (since there are so few of them).  In some
        contexts, it can be a win for a different reason: if every DSO has a
        GNU hash section, then libc can avoid calculating SysV hashes at
        all. Both musl and glibc appear to have this optimization.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      787b393c
  8. 29 9月, 2015 2 次提交
  9. 25 9月, 2015 6 次提交
    • D
      KVM: disable halt_poll_ns as default for s390x · 920552b2
      David Hildenbrand 提交于
      We observed some performance degradation on s390x with dynamic
      halt polling. Until we can provide a proper fix, let's enable
      halt_poll_ns as default only for supported architectures.
      
      Architectures are now free to set their own halt_poll_ns
      default value.
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      920552b2
    • P
      KVM: x86: fix off-by-one in reserved bits check · 58c95070
      Paolo Bonzini 提交于
      29ecd660 ("KVM: x86: avoid uninitialized variable warning",
      2015-09-06) introduced a not-so-subtle problem, which probably
      escaped review because it was not part of the patch context.
      
      Before the patch, leaf was always equal to iterator.level.  After,
      it is equal to iterator.level - 1 in the call to is_shadow_zero_bits_set,
      and when is_shadow_zero_bits_set does another "-1" the check on
      reserved bits becomes incorrect.  Using "iterator.level" in the call
      fixes this call trace:
      
      WARNING: CPU: 2 PID: 17000 at arch/x86/kvm/mmu.c:3385 handle_mmio_page_fault.part.93+0x1a/0x20 [kvm]()
      Modules linked in: tun sha256_ssse3 sha256_generic drbg binfmt_misc ipv6 vfat fat fuse dm_crypt dm_mod kvm_amd kvm crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd fam15h_power amd64_edac_mod k10temp edac_core amdkfd amd_iommu_v2 radeon acpi_cpufreq
      [...]
      Call Trace:
        dump_stack+0x4e/0x84
        warn_slowpath_common+0x95/0xe0
        warn_slowpath_null+0x1a/0x20
        handle_mmio_page_fault.part.93+0x1a/0x20 [kvm]
        tdp_page_fault+0x231/0x290 [kvm]
        ? emulator_pio_in_out+0x6e/0xf0 [kvm]
        kvm_mmu_page_fault+0x36/0x240 [kvm]
        ? svm_set_cr0+0x95/0xc0 [kvm_amd]
        pf_interception+0xde/0x1d0 [kvm_amd]
        handle_exit+0x181/0xa70 [kvm_amd]
        ? kvm_arch_vcpu_ioctl_run+0x68b/0x1730 [kvm]
        kvm_arch_vcpu_ioctl_run+0x6f6/0x1730 [kvm]
        ? kvm_arch_vcpu_ioctl_run+0x68b/0x1730 [kvm]
        ? preempt_count_sub+0x9b/0xf0
        ? mutex_lock_killable_nested+0x26f/0x490
        ? preempt_count_sub+0x9b/0xf0
        kvm_vcpu_ioctl+0x358/0x710 [kvm]
        ? __fget+0x5/0x210
        ? __fget+0x101/0x210
        do_vfs_ioctl+0x2f4/0x560
        ? __fget_light+0x29/0x90
        SyS_ioctl+0x4c/0x90
        entry_SYSCALL_64_fastpath+0x16/0x73
      ---[ end trace 37901c8686d84de6 ]---
      Reported-by: NBorislav Petkov <bp@alien8.de>
      Tested-by: NBorislav Petkov <bp@alien8.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      58c95070
    • P
      KVM: x86: use correct page table format to check nested page table reserved bits · 6fec2144
      Paolo Bonzini 提交于
      Intel CPUID on AMD host or vice versa is a weird case, but it can
      happen.  Handle it by checking the host CPU vendor instead of the
      guest's in reset_tdp_shadow_zero_bits_mask.  For speed, the
      check uses the fact that Intel EPT has an X (executable) bit while
      AMD NPT has NX.
      Reported-by: NBorislav Petkov <bp@alien8.de>
      Tested-by: NBorislav Petkov <bp@alien8.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6fec2144
    • P
      KVM: svm: do not call kvm_set_cr0 from init_vmcb · 79a8059d
      Paolo Bonzini 提交于
      kvm_set_cr0 may want to call kvm_zap_gfn_range and thus access the
      memslots array (SRCU protected).  Using a mini SRCU critical section
      is ugly, and adding it to kvm_arch_vcpu_create doesn't work because
      the VMX vcpu_create callback calls synchronize_srcu.
      
      Fixes this lockdep splat:
      
      ===============================
      [ INFO: suspicious RCU usage. ]
      4.3.0-rc1+ #1 Not tainted
      -------------------------------
      include/linux/kvm_host.h:488 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      rcu_scheduler_active = 1, debug_locks = 0
      1 lock held by qemu-system-i38/17000:
       #0:  (&(&kvm->mmu_lock)->rlock){+.+...}, at: kvm_zap_gfn_range+0x24/0x1a0 [kvm]
      
      [...]
      Call Trace:
       dump_stack+0x4e/0x84
       lockdep_rcu_suspicious+0xfd/0x130
       kvm_zap_gfn_range+0x188/0x1a0 [kvm]
       kvm_set_cr0+0xde/0x1e0 [kvm]
       init_vmcb+0x760/0xad0 [kvm_amd]
       svm_create_vcpu+0x197/0x250 [kvm_amd]
       kvm_arch_vcpu_create+0x47/0x70 [kvm]
       kvm_vm_ioctl+0x302/0x7e0 [kvm]
       ? __lock_is_held+0x51/0x70
       ? __fget+0x101/0x210
       do_vfs_ioctl+0x2f4/0x560
       ? __fget_light+0x29/0x90
       SyS_ioctl+0x4c/0x90
       entry_SYSCALL_64_fastpath+0x16/0x73
      Reported-by: NBorislav Petkov <bp@alien8.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      79a8059d
    • B
      ARM: sti: dt: adapt DT to fix probe/bind issues in DRM driver · 79a313f5
      Benjamin Gaignard 提交于
      STI drm drivers probe and bind using component framework was incorrect.
      In addition to drivers fix DT update is needed to make all sub-components
      become childs of sti-display-subsystem.
      Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
      Signed-off-by: NMaxime Coquelin <maxime.coquelin@st.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      79a313f5
    • K
      ARM: dts: fix omap2+ address translation for pbias · 9a5e3f27
      Kishon Vijay Abraham I 提交于
      "ARM: dts: <omap2/omap4/omap5/dra7>: add minimal l4 bus
      layout with control module support" moved pbias_regulator dt node
      from being a child node of ocp to be the child node of
      'syscon'. Since 'syscon' doesn't have the 'ranges' property,
      address translation fails while trying to convert the address
      to resource. Fix it here by populating 'ranges' property in
      syscon dt node.
      
      Fixes: 72b10ac0 ("ARM: dts: omap24xx: add minimal l4 bus
      layout with control module support")
      
      Fixes: 7415b0b4 ("ARM: dts: omap4: add minimal l4 bus layout
      with control module support")
      
      Fixes: ed8509ed ("ARM: dts: omap5: add minimal l4 bus
      layout with control module support")
      
      Fixes: d919501f ("ARM: dts: dra7: add minimal l4 bus
      layout with control module support")
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      [tony@atomide.com: fixed omap3 pbias to work]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      9a5e3f27
新手
引导
客服 返回
顶部