1. 19 Jun, 2015 1 commit
  2. 18 Jun, 2015 1 commit
  3. 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
  4. 09 Jun, 2015 2 commits
  5. 05 Jun, 2015 8 commits
  6. 04 Jun, 2015 10 commits
  7. 03 Jun, 2015 1 commit
  8. 02 Jun, 2015 2 commits
  9. 29 May, 2015 3 commits
    • Marcelo Tosatti's avatar
      KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock system MSR · b7e60c5a
      Marcelo Tosatti authored
      Initialize kvmclock base, on kvmclock system MSR write time,
      so that the guest sees kvmclock counting from zero.
      
      This matches baremetal behaviour when kvmclock in guest
      sets sched clock stable.
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      [Remove unnecessary comment. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b7e60c5a
    • Luiz Capitulino's avatar
      x86: kvmclock: set scheduler clock stable · 0ad83caa
      Luiz Capitulino authored
      If you try to enable NOHZ_FULL on a guest today, you'll get
      the following error when the guest tries to deactivate the
      scheduler tick:
      
       WARNING: CPU: 3 PID: 2182 at kernel/time/tick-sched.c:192 can_stop_full_tick+0xb9/0x290()
       NO_HZ FULL will not work with unstable sched clock
       CPU: 3 PID: 2182 Comm: kworker/3:1 Not tainted 4.0.0-10545-gb9bb6fb7 #204
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       Workqueue: events flush_to_ldisc
        ffffffff8162a0c7 ffff88011f583e88 ffffffff814e6ba0 0000000000000002
        ffff88011f583ed8 ffff88011f583ec8 ffffffff8104d095 ffff88011f583eb8
        0000000000000000 0000000000000003 0000000000000001 0000000000000001
       Call Trace:
        <IRQ>  [<ffffffff814e6ba0>] dump_stack+0x4f/0x7b
        [<ffffffff8104d095>] warn_slowpath_common+0x85/0xc0
        [<ffffffff8104d146>] warn_slowpath_fmt+0x46/0x50
        [<ffffffff810bd2a9>] can_stop_full_tick+0xb9/0x290
        [<ffffffff810bd9ed>] tick_nohz_irq_exit+0x8d/0xb0
        [<ffffffff810511c5>] irq_exit+0xc5/0x130
        [<ffffffff814f180a>] smp_apic_timer_interrupt+0x4a/0x60
        [<ffffffff814eff5e>] apic_timer_interrupt+0x6e/0x80
        <EOI>  [<ffffffff814ee5d1>] ? _raw_spin_unlock_irqrestore+0x31/0x60
        [<ffffffff8108bbc8>] __wake_up+0x48/0x60
        [<ffffffff8134836c>] n_tty_receive_buf_common+0x49c/0xba0
        [<ffffffff8134a6bf>] ? tty_ldisc_ref+0x1f/0x70
        [<ffffffff81348a84>] n_tty_receive_buf2+0x14/0x20
        [<ffffffff8134b390>] flush_to_ldisc+0xe0/0x120
        [<ffffffff81064d05>] process_one_work+0x1d5/0x540
        [<ffffffff81064c81>] ? process_one_work+0x151/0x540
        [<ffffffff81065191>] worker_thread+0x121/0x470
        [<ffffffff81065070>] ? process_one_work+0x540/0x540
        [<ffffffff8106b4df>] kthread+0xef/0x110
        [<ffffffff8106b3f0>] ? __kthread_parkme+0xa0/0xa0
        [<ffffffff814ef4f2>] ret_from_fork+0x42/0x70
        [<ffffffff8106b3f0>] ? __kthread_parkme+0xa0/0xa0
       ---[ end trace 06e3507544a38866 ]---
      
      However, it turns out that kvmclock does provide a stable
      sched_clock callback. So, let the scheduler know this which
      in turn makes NOHZ_FULL work in the guest.
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarLuiz Capitulino <lcapitulino@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      0ad83caa
    • Marcelo Tosatti's avatar
      x86: kvmclock: add flag to indicate pvclock counts from zero · 61191725
      Marcelo Tosatti authored
      Setting sched clock stable for kvmclock causes the printk timestamps
      to not start from zero, which is different from baremetal and
      can possibly break userspace. Add a flag to indicate that
      hypervisor sets clock base at zero when kvmclock is initialized.
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      61191725
  10. 28 May, 2015 3 commits