1. 23 10月, 2015 1 次提交
  2. 05 9月, 2015 1 次提交
  3. 17 6月, 2015 1 次提交
    • L
      ARM: kvm: psci: fix handling of unimplemented functions · e2d99736
      Lorenzo Pieralisi 提交于
      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: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      e2d99736
  4. 27 5月, 2015 1 次提交
  5. 21 1月, 2015 1 次提交
  6. 13 12月, 2014 1 次提交
  7. 30 4月, 2014 7 次提交
  8. 22 12月, 2013 1 次提交
    • C
      arm: KVM: Don't return PSCI_INVAL if waitqueue is inactive · 478a8237
      Christoffer Dall 提交于
      The current KVM implementation of PSCI returns INVALID_PARAMETERS if the
      waitqueue for the corresponding CPU is not active.  This does not seem
      correct, since KVM should not care what the specific thread is doing,
      for example, user space may not have called KVM_RUN on this VCPU yet or
      the thread may be busy looping to user space because it received a
      signal; this is really up to the user space implementation.  Instead we
      should check specifically that the CPU is marked as being turned off,
      regardless of the VCPU thread state, and if it is, we shall
      simply clear the pause flag on the CPU and wake up the thread if it
      happens to be blocked for us.
      
      Further, the implementation seems to be racy when executing multiple
      VCPU threads.  There really isn't a reasonable user space programming
      scheme to ensure all secondary CPUs have reached kvm_vcpu_first_run_init
      before turning on the boot CPU.
      
      Therefore, set the pause flag on the vcpu at VCPU init time (which can
      reasonably be expected to be completed for all CPUs by user space before
      running any VCPUs) and clear both this flag and the feature (in case the
      feature can somehow get set again in the future) and ping the waitqueue
      on turning on a VCPU using PSCI.
      Reported-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      478a8237
  9. 08 11月, 2013 1 次提交
  10. 22 10月, 2013 1 次提交
  11. 27 6月, 2013 1 次提交
  12. 24 1月, 2013 1 次提交