Skip to content
  1. Nov 23, 2014
  2. Nov 04, 2014
    • Fabio Estevam's avatar
      ARM: imx: Fix the removal of CONFIG_SPI option · 89fbec5b
      Fabio Estevam authored
      
      
      Since 64546e9f ("ARM: imx_v6_v7_defconfig updates") and commit
      0650f855 ("ARM: imx_v4_v5_defconfig: Select CONFIG_IMX_WEIM") CONFIG_SPI
      selection was dropped by savedefconfig for imx_v4_v5_defconfig and
      imx_v6_v7_defconfig.
      
      In order to keep the same behaviour as previous kernel versions and avoid
      regressions, let's add CONFIG_SPI option back.
      
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      89fbec5b
    • Stefan Agner's avatar
      ARM: imx: clk-vf610: define PLL's clock tree · c72c5532
      Stefan Agner authored
      
      
      So far, the required PLL's (PLL1/PLL2/PLL5) have been initialized
      by boot loader and the kernel code defined fixed rates according
      to those default configurations. Beginning with the USB PLL7 the
      code started to initialize the PLL's itself (using imx_clk_pllv3).
      
      However, since commit dc4805c2
      (ARM: imx: remove ENABLE and BYPASS bits from clk-pllv3 driver)
      imx_clk_pllv3 no longer takes care of the ENABLE and BYPASS bits,
      hence the USB PLL were not configured correctly anymore.
      
      This patch not only fixes those USB PLL's, but also makes use of
      the imx_clk_pllv3 for all PLL's and alignes the code with the PLL
      support of the i.MX6 series.
      
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      c72c5532
  3. Nov 03, 2014
  4. Nov 02, 2014
    • Paolo Bonzini's avatar
      KVM: vmx: defer load of APIC access page address during reset · a73896cb
      Paolo Bonzini authored
      
      
      Most call paths to vmx_vcpu_reset do not hold the SRCU lock.  Defer loading
      the APIC access page to the next vmentry.
      
      This avoids the following lockdep splat:
      
      [ INFO: suspicious RCU usage. ]
      3.18.0-rc2-test2+ #70 Not tainted
      -------------------------------
      include/linux/kvm_host.h:474 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-x86/2371:
       #0:  (&vcpu->mutex){+.+...}, at: [<ffffffffa037d800>] vcpu_load+0x20/0xd0 [kvm]
      
      stack backtrace:
      CPU: 4 PID: 2371 Comm: qemu-system-x86 Not tainted 3.18.0-rc2-test2+ #70
      Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A12 01/10/2013
       0000000000000001 ffff880209983ca8 ffffffff816f514f 0000000000000000
       ffff8802099b8990 ffff880209983cd8 ffffffff810bd687 00000000000fee00
       ffff880208a2c000 ffff880208a10000 ffff88020ef50040 ffff880209983d08
      Call Trace:
       [<ffffffff816f514f>] dump_stack+0x4e/0x71
       [<ffffffff810bd687>] lockdep_rcu_suspicious+0xe7/0x120
       [<ffffffffa037d055>] gfn_to_memslot+0xd5/0xe0 [kvm]
       [<ffffffffa03807d3>] __gfn_to_pfn+0x33/0x60 [kvm]
       [<ffffffffa0380885>] gfn_to_page+0x25/0x90 [kvm]
       [<ffffffffa038aeec>] kvm_vcpu_reload_apic_access_page+0x3c/0x80 [kvm]
       [<ffffffffa08f0a9c>] vmx_vcpu_reset+0x20c/0x460 [kvm_intel]
       [<ffffffffa039ab8e>] kvm_vcpu_reset+0x15e/0x1b0 [kvm]
       [<ffffffffa039ac0c>] kvm_arch_vcpu_setup+0x2c/0x50 [kvm]
       [<ffffffffa037f7e0>] kvm_vm_ioctl+0x1d0/0x780 [kvm]
       [<ffffffff810bc664>] ? __lock_is_held+0x54/0x80
       [<ffffffff812231f0>] do_vfs_ioctl+0x300/0x520
       [<ffffffff8122ee45>] ? __fget+0x5/0x250
       [<ffffffff8122f0fa>] ? __fget_light+0x2a/0xe0
       [<ffffffff81223491>] SyS_ioctl+0x81/0xa0
       [<ffffffff816fed6d>] system_call_fastpath+0x16/0x1b
      
      Reported-by: default avatarTakashi Iwai <tiwai@suse.de>
      Reported-by: default avatarAlexei Starovoitov <alexei.starovoitov@gmail.com>
      Reviewed-by: default avatarWanpeng Li <wanpeng.li@linux.intel.com>
      Tested-by: default avatarWanpeng Li <wanpeng.li@linux.intel.com>
      Fixes: 38b99173
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      a73896cb
    • Jan Kiszka's avatar
      KVM: nVMX: Disable preemption while reading from shadow VMCS · 282da870
      Jan Kiszka authored
      
      
      In order to access the shadow VMCS, we need to load it. At this point,
      vmx->loaded_vmcs->vmcs and the actually loaded one start to differ. If
      we now get preempted by Linux, vmx_vcpu_put and, on return, the
      vmx_vcpu_load will work against the wrong vmcs. That can cause
      copy_shadow_to_vmcs12 to corrupt the vmcs12 state.
      
      Fix the issue by disabling preemption during the copy operation.
      copy_vmcs12_to_shadow is safe from this issue as it is executed by
      vmx_vcpu_run when preemption is already disabled before vmentry.
      
      This bug is exposed by running Jailhouse within KVM on CPUs with
      shadow VMCS support.  Jailhouse never expects an interrupt pending
      vmexit, but the bug can cause it if, after copy_shadow_to_vmcs12
      is preempted, the active VMCS happens to have the virtual interrupt
      pending flag set in the CPU-based execution controls.
      
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      282da870