1. 17 Jun, 2015 5 commits
    • Alex Bennée's avatar
      KVM: arm64: fix misleading comments in save/restore · 921ef1e1
      Alex Bennée authored
      The elr_el2 and spsr_el2 registers in fact contain the processor state
      before entry into EL2. In the case of guest state it could be in either
      el0 or el1.
      Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      921ef1e1
    • Kim Phillips's avatar
      KVM: arm/arm64: Enable the KVM-VFIO device · 8889583c
      Kim Phillips authored
      The KVM-VFIO device is used by the QEMU VFIO device. It is used to
      record the list of in-use VFIO groups so that KVM can manipulate
      them.
      Signed-off-by: default avatarKim Phillips <kim.phillips@linaro.org>
      Signed-off-by: default avatarEric Auger <eric.auger@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      8889583c
    • Christoffer Dall's avatar
      arm/arm64: KVM: Properly account for guest CPU time · 1b3d546d
      Christoffer Dall authored
      Until now we have been calling kvm_guest_exit after re-enabling
      interrupts when we come back from the guest, but this has the
      unfortunate effect that CPU time accounting done in the context of timer
      interrupts occurring while the guest is running doesn't properly notice
      that the time since the last tick was spent in the guest.
      
      Inspired by the comment in the x86 code, move the kvm_guest_exit() call
      below the local_irq_enable() call and change __kvm_guest_exit() to
      kvm_guest_exit(), because we are now calling this function with
      interrupts enabled.  We have to now explicitly disable preemption and
      not enable preemption before we've called kvm_guest_exit(), since
      otherwise we could be preempted and everything happening before we
      eventually get scheduled again would be accounted for as guest time.
      
      At the same time, move the trace_kvm_exit() call outside of the atomic
      section, since there is no reason for us to do that with interrupts
      disabled.
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      1b3d546d
    • Tiejun Chen's avatar
      kvm: remove one useless check extension · ea2c6d97
      Tiejun Chen authored
      We already check KVM_CAP_IRQFD in generic once enable CONFIG_HAVE_KVM_IRQFD,
      
      kvm_vm_ioctl_check_extension_generic()
          |
          + switch (arg) {
          +   ...
          +   #ifdef CONFIG_HAVE_KVM_IRQFD
          +       case KVM_CAP_IRQFD:
          +   #endif
          +   ...
          +   return 1;
          +   ...
          + }
          |
          + kvm_vm_ioctl_check_extension()
      
      So its not necessary to check this in arch again, and also fix one typo,
      s/emlation/emulation.
      Signed-off-by: default avatarTiejun Chen <tiejun.chen@intel.com>
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      ea2c6d97
    • Marc Zyngier's avatar
      arm: KVM: force execution of HCPTR access on VM exit · 85e84ba3
      Marc Zyngier authored
      On VM entry, we disable access to the VFP registers in order to
      perform a lazy save/restore of these registers.
      
      On VM exit, we restore access, test if we did enable them before,
      and save/restore the guest/host registers if necessary. In this
      sequence, the FPEXC register is always accessed, irrespective
      of the trapping configuration.
      
      If the guest didn't touch the VFP registers, then the HCPTR access
      has now enabled such access, but we're missing a barrier to ensure
      architectural execution of the new HCPTR configuration. If the HCPTR
      access has been delayed/reordered, the subsequent access to FPEXC
      will cause a trap, which we aren't prepared to handle at all.
      
      The same condition exists when trapping to enable VFP for the guest.
      
      The fix is to introduce a barrier after enabling VFP access. In the
      vmexit case, it can be relaxed to only takes place if the guest hasn't
      accessed its view of the VFP registers, making the access to FPEXC safe.
      
      The set_hcptr macro is modified to deal with both vmenter/vmexit and
      vmtrap operations, and now takes an optional label that is branched to
      when the guest hasn't touched the VFP registers.
      Reported-by: default avatarVikram Sethi <vikrams@codeaurora.org>
      Cc: stable@kernel.org	# v3.9+
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      85e84ba3
  2. 09 Jun, 2015 2 commits
  3. 19 May, 2015 16 commits
  4. 11 May, 2015 1 commit
  5. 08 May, 2015 15 commits
  6. 07 May, 2015 1 commit