1. 08 2月, 2017 9 次提交
  2. 01 2月, 2017 1 次提交
  3. 30 1月, 2017 5 次提交
  4. 25 1月, 2017 2 次提交
  5. 13 1月, 2017 3 次提交
    • M
      KVM: arm/arm64: vgic: Fix deadlock on error handling · 1193e6ae
      Marc Zyngier 提交于
      Dmitry Vyukov reported that the syzkaller fuzzer triggered a
      deadlock in the vgic setup code when an error was detected, as
      the cleanup code tries to take a lock that is already held by
      the setup code.
      
      The fix is to avoid retaking the lock when cleaning up, by
      telling the cleanup function that we already hold it.
      
      Cc: stable@vger.kernel.org
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      1193e6ae
    • J
      KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems · 488f94d7
      Jintack Lim 提交于
      Current KVM world switch code is unintentionally setting wrong bits to
      CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
      timer.  Bit positions of CNTHCTL_EL2 are changing depending on
      HCR_EL2.E2H bit.  EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
      not set, but they are 11th and 10th bits respectively when E2H is set.
      
      In fact, on VHE we only need to set those bits once, not for every world
      switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
      1, which makes those bits have no effect for the host kernel execution.
      So we just set those bits once for guests, and that's it.
      Signed-off-by: NJintack Lim <jintack@cs.columbia.edu>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      488f94d7
    • C
      KVM: arm/arm64: Fix occasional warning from the timer work function · 63e41226
      Christoffer Dall 提交于
      When a VCPU blocks (WFI) and has programmed the vtimer, we program a
      soft timer to expire in the future to wake up the vcpu thread when
      appropriate.  Because such as wake up involves a vcpu kick, and the
      timer expire function can get called from interrupt context, and the
      kick may sleep, we have to schedule the kick in the work function.
      
      The work function currently has a warning that gets raised if it turns
      out that the timer shouldn't fire when it's run, which was added because
      the idea was that in that case the work should never have been cancelled.
      
      However, it turns out that this whole thing is racy and we can get
      spurious warnings.  The problem is that we clear the armed flag in the
      work function, which may run in parallel with the
      kvm_timer_unschedule->timer_disarm() call.  This results in a possible
      situation where the timer_disarm() call does not call
      cancel_work_sync(), which effectively synchronizes the completion of the
      work function with running the VCPU.  As a result, the VCPU thread
      proceeds before the work function completees, causing changes to the
      timer state such that kvm_timer_should_fire(vcpu) returns false in the
      work function.
      
      All we do in the work function is to kick the VCPU, and an occasional
      rare extra kick never harmed anyone.  Since the race above is extremely
      rare, we don't bother checking if the race happens but simply remove the
      check and the clearing of the armed flag from the work function.
      Reported-by: NMatthias Brugger <mbrugger@suse.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      63e41226
  6. 25 12月, 2016 3 次提交
  7. 15 12月, 2016 1 次提交
    • L
      mm: unexport __get_user_pages_unlocked() · 8b7457ef
      Lorenzo Stoakes 提交于
      Unexport the low-level __get_user_pages_unlocked() function and replaces
      invocations with calls to more appropriate higher-level functions.
      
      In hva_to_pfn_slow() we are able to replace __get_user_pages_unlocked()
      with get_user_pages_unlocked() since we can now pass gup_flags.
      
      In async_pf_execute() and process_vm_rw_single_vec() we need to pass
      different tsk, mm arguments so get_user_pages_remote() is the sane
      replacement in these cases (having added manual acquisition and release
      of mmap_sem.)
      
      Additionally get_user_pages_remote() reintroduces use of the FOLL_TOUCH
      flag.  However, this flag was originally silently dropped by commit
      1e987790 ("mm/gup: Introduce get_user_pages_remote()"), so this
      appears to have been unintentional and reintroducing it is therefore not
      an issue.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Link: http://lkml.kernel.org/r/20161027095141.2569-3-lstoakes@gmail.comSigned-off-by: NLorenzo Stoakes <lstoakes@gmail.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krcmar <rkrcmar@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8b7457ef
  8. 09 12月, 2016 2 次提交
  9. 02 12月, 2016 1 次提交
  10. 01 12月, 2016 1 次提交
  11. 28 11月, 2016 1 次提交
    • S
      KVM: Export kvm module parameter variables · ec76d819
      Suraj Jitindar Singh 提交于
      The kvm module has the parameters halt_poll_ns, halt_poll_ns_grow, and
      halt_poll_ns_shrink. Halt polling was recently added to the powerpc kvm-hv
      module and these parameters were essentially duplicated for that. There is
      no benefit to this duplication and it can lead to confusion when trying to
      tune halt polling.
      
      Thus move the definition of these variables to kvm_host.h and export them.
      This will allow the kvm-hv module to use the same module parameters by
      accessing these variables, which will be implemented in the next patch,
      meaning that they will no longer be duplicated.
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      ec76d819
  12. 24 11月, 2016 1 次提交
  13. 22 11月, 2016 1 次提交
  14. 20 11月, 2016 1 次提交
    • P
      KVM: async_pf: avoid recursive flushing of work items · 22583f0d
      Paolo Bonzini 提交于
      This was reported by syzkaller:
      
          [ INFO: possible recursive locking detected ]
          4.9.0-rc4+ #49 Not tainted
          ---------------------------------------------
          kworker/2:1/5658 is trying to acquire lock:
           ([ 1644.769018] (&work->work)
          [<     inline     >] list_empty include/linux/compiler.h:243
          [<ffffffff8128dd60>] flush_work+0x0/0x660 kernel/workqueue.c:1511
      
          but task is already holding lock:
           ([ 1644.769018] (&work->work)
          [<ffffffff812916ab>] process_one_work+0x94b/0x1900 kernel/workqueue.c:2093
      
          stack backtrace:
          CPU: 2 PID: 5658 Comm: kworker/2:1 Not tainted 4.9.0-rc4+ #49
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
          Workqueue: events async_pf_execute
           ffff8800676ff630 ffffffff81c2e46b ffffffff8485b930 ffff88006b1fc480
           0000000000000000 ffffffff8485b930 ffff8800676ff7e0 ffffffff81339b27
           ffff8800676ff7e8 0000000000000046 ffff88006b1fcce8 ffff88006b1fccf0
          Call Trace:
          ...
          [<ffffffff8128ddf3>] flush_work+0x93/0x660 kernel/workqueue.c:2846
          [<ffffffff812954ea>] __cancel_work_timer+0x17a/0x410 kernel/workqueue.c:2916
          [<ffffffff81295797>] cancel_work_sync+0x17/0x20 kernel/workqueue.c:2951
          [<ffffffff81073037>] kvm_clear_async_pf_completion_queue+0xd7/0x400 virt/kvm/async_pf.c:126
          [<     inline     >] kvm_free_vcpus arch/x86/kvm/x86.c:7841
          [<ffffffff810b728d>] kvm_arch_destroy_vm+0x23d/0x620 arch/x86/kvm/x86.c:7946
          [<     inline     >] kvm_destroy_vm virt/kvm/kvm_main.c:731
          [<ffffffff8105914e>] kvm_put_kvm+0x40e/0x790 virt/kvm/kvm_main.c:752
          [<ffffffff81072b3d>] async_pf_execute+0x23d/0x4f0 virt/kvm/async_pf.c:111
          [<ffffffff8129175c>] process_one_work+0x9fc/0x1900 kernel/workqueue.c:2096
          [<ffffffff8129274f>] worker_thread+0xef/0x1480 kernel/workqueue.c:2230
          [<ffffffff812a5a94>] kthread+0x244/0x2d0 kernel/kthread.c:209
          [<ffffffff831f102a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
      
      The reason is that kvm_put_kvm is causing the destruction of the VM, but
      the page fault is still on the ->queue list.  The ->queue list is owned
      by the VCPU, not by the work items, so we cannot just add list_del to
      the work item.
      
      Instead, use work->vcpu to note async page faults that have been resolved
      and will be processed through the done list.  There is no need to flush
      those.
      
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      22583f0d
  15. 18 11月, 2016 1 次提交
    • W
      KVM: arm64: Fix the issues when guest PMCCFILTR is configured · b112c84a
      Wei Huang 提交于
      KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
      But this function can't deals with PMCCFILTR correctly because the evtCount
      bits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
      type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, this
      function shouldn't return immediately; instead it needs to check further
      if select_idx is ARMV8_PMU_CYCLE_IDX.
      
      Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
      blindly to attr.config. Instead it ought to convert the request to the
      "cpu cycle" event type (i.e. 0x11).
      
      To support this patch and to prevent duplicated definitions, a limited
      set of ARMv8 perf event types were relocated from perf_event.c to
      asm/perf_event.h.
      
      Cc: stable@vger.kernel.org # 4.6+
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NWei Huang <wei@redhat.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      b112c84a
  16. 15 11月, 2016 1 次提交
  17. 14 11月, 2016 2 次提交
  18. 05 11月, 2016 2 次提交
  19. 03 11月, 2016 1 次提交
  20. 26 10月, 2016 1 次提交
    • P
      KVM: fix OOPS on flush_work · 36343f6e
      Paolo Bonzini 提交于
      The conversion done by commit 3706feac ("KVM: Remove deprecated
      create_singlethread_workqueue") is broken.  It flushes a single work
      item &irqfd->shutdown instead of all of them, and even worse if there
      is no irqfd on the list then you get a NULL pointer dereference.
      Revert the virt/kvm/eventfd.c part of that patch; to avoid the
      deprecated function, just allocate our own workqueue---it does
      not even have to be unbound---with alloc_workqueue.
      
      Fixes: 3706feacReviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      36343f6e