1. 17 Jun, 2015 9 commits
    • Marc Zyngier's avatar
      KVM: arm/arm64: vgic: Avoid injecting reserved IRQ numbers · 4839ddc2
      Marc Zyngier authored
      Commit fd1d0ddf (KVM: arm/arm64: check IRQ number on userland
      injection) rightly limited the range of interrupts userspace can
      inject in a guest, but failed to consider the (unlikely) case where
      a guest is configured with 1024 interrupts.
      
      In this case, interrupts ranging from 1020 to 1023 are unuseable,
      as they have a special meaning for the GIC CPU interface.
      
      Make sure that these number cannot be used as an IRQ. Also delete
      a redundant (and similarily buggy) check in kvm_set_irq.
      Reported-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: <stable@vger.kernel.org> # 4.1, 4.0, 3.19, 3.18
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      4839ddc2
    • Marc Zyngier's avatar
      arm/arm64: KVM: vgic: Do not save GICH_HCR / ICH_HCR_EL2 · 4642019d
      Marc Zyngier authored
      The GIC Hypervisor Configuration Register is used to enable
      the delivery of virtual interupts to a guest, as well as to
      define in which conditions maintenance interrupts are delivered
      to the host.
      
      This register doesn't contain any information that we need to
      read back (the EOIcount is utterly useless for us).
      
      So let's save ourselves some cycles, and not save it before
      writing zero to it.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      4642019d
    • Marc Zyngier's avatar
      KVM: arm: vgic: Drop useless Group0 warning · f5a202db
      Marc Zyngier authored
      If a GICv3-enabled guest tries to configure Group0, we print a
      warning on the console (because we don't support Group0 interrupts).
      
      This is fairly pointless, and would allow a guest to spam the
      console. Let's just drop the warning.
      Acked-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      f5a202db
    • Lorenzo Pieralisi's avatar
      ARM: kvm: psci: fix handling of unimplemented functions · e2d99736
      Lorenzo Pieralisi authored
      According to the PSCI specification and the SMC/HVC calling
      convention, PSCI function_ids that are not implemented must
      return NOT_SUPPORTED as return value.
      
      Current KVM implementation takes an unhandled PSCI function_id
      as an error and injects an undefined instruction into the guest
      if PSCI implementation is called with a function_id that is not
      handled by the resident PSCI version (ie it is not implemented),
      which is not the behaviour expected by a guest when calling a
      PSCI function_id that is not implemented.
      
      This patch fixes this issue by returning NOT_SUPPORTED whenever
      the kvm PSCI call is executed for a function_id that is not
      implemented by the PSCI kvm layer.
      
      Cc: <stable@vger.kernel.org> # 3.18+
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Acked-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      e2d99736
    • 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 12 commits