1. 02 1月, 2018 5 次提交
    • C
      KVM: arm/arm64: vgic: Support level-triggered mapped interrupts · e40cc57b
      Christoffer Dall 提交于
      Level-triggered mapped IRQs are special because we only observe rising
      edges as input to the VGIC, and we don't set the EOI flag and therefore
      are not told when the level goes down, so that we can re-queue a new
      interrupt when the level goes up.
      
      One way to solve this problem is to side-step the logic of the VGIC and
      special case the validation in the injection path, but it has the
      unfortunate drawback of having to peak into the physical GIC state
      whenever we want to know if the interrupt is pending on the virtual
      distributor.
      
      Instead, we can maintain the current semantics of a level triggered
      interrupt by sort of treating it as an edge-triggered interrupt,
      following from the fact that we only observe an asserting edge.  This
      requires us to be a bit careful when populating the LRs and when folding
      the state back in though:
      
       * We lower the line level when populating the LR, so that when
         subsequently observing an asserting edge, the VGIC will do the right
         thing.
      
       * If the guest never acked the interrupt while running (for example if
         it had masked interrupts at the CPU level while running), we have
         to preserve the pending state of the LR and move it back to the
         line_level field of the struct irq when folding LR state.
      
         If the guest never acked the interrupt while running, but changed the
         device state and lowered the line (again with interrupts masked) then
         we need to observe this change in the line_level.
      
         Both of the above situations are solved by sampling the physical line
         and set the line level when folding the LR back.
      
       * Finally, if the guest never acked the interrupt while running and
         sampling the line reveals that the device state has changed and the
         line has been lowered, we must clear the physical active state, since
         we will otherwise never be told when the interrupt becomes asserted
         again.
      
      This has the added benefit of making the timer optimization patches
      (https://lists.cs.columbia.edu/pipermail/kvmarm/2017-July/026343.html) a
      bit simpler, because the timer code doesn't have to clear the active
      state on the sync anymore.  It also potentially improves the performance
      of the timer implementation because the GIC knows the state or the LR
      and only needs to clear the
      active state when the pending bit in the LR is still set, where the
      timer has to always clear it when returning from running the guest with
      an injected timer interrupt.
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      e40cc57b
    • C
      KVM: arm/arm64: Don't cache the timer IRQ level · 70450a9f
      Christoffer Dall 提交于
      The timer logic was designed after a strict idea of modeling an
      interrupt line level in software, meaning that only transitions in the
      level need to be reported to the VGIC.  This works well for the timer,
      because the arch timer code is in complete control of the device and can
      track the transitions of the line.
      
      However, as we are about to support using the HW bit in the VGIC not
      just for the timer, but also for VFIO which cannot track transitions of
      the interrupt line, we have to decide on an interface between the GIC
      and other subsystems for level triggered mapped interrupts, which both
      the timer and VFIO can use.
      
      VFIO only sees an asserting transition of the physical interrupt line,
      and tells the VGIC when that happens.  That means that part of the
      interrupt flow is offloaded to the hardware.
      
      To use the same interface for VFIO devices and the timer, we therefore
      have to change the timer (we cannot change VFIO because it doesn't know
      the details of the device it is assigning to a VM).
      
      Luckily, changing the timer is simple, we just need to stop 'caching'
      the line level, but instead let the VGIC know the state of the timer
      every time there is a potential change in the line level, and when the
      line level should be asserted from the timer ISR.  The VGIC can ignore
      extra notifications using its validate mechanism.
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: NJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      70450a9f
    • C
      KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu · 6c1b7521
      Christoffer Dall 提交于
      We are about to distinguish between userspace accesses and mmio traps
      for a number of the mmio handlers.  When the requester vcpu is NULL, it
      means we are handling a userspace access.
      
      Factor out the functionality to get the request vcpu into its own
      function, mostly so we have a common place to document the semantics of
      the return value.
      
      Also take the chance to move the functionality outside of holding a
      spinlock and instead explicitly disable and enable preemption.  This
      supports PREEMPT_RT kernels as well.
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      6c1b7521
    • C
      KVM: arm/arm64: Remove redundant preemptible checks · 5a245750
      Christoffer Dall 提交于
      The __this_cpu_read() and __this_cpu_write() functions already implement
      checks for the required preemption levels when using
      CONFIG_DEBUG_PREEMPT which gives you nice error messages and such.
      Therefore there is no need to explicitly check this using a BUG_ON() in
      the code (which we don't do for other uses of per cpu variables either).
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      5a245750
    • V
      KVM: arm: Use PTR_ERR_OR_ZERO() · 4404b336
      Vasyl Gomonovych 提交于
      Fix ptr_ret.cocci warnings:
      virt/kvm/arm/vgic/vgic-its.c:971:1-3: WARNING: PTR_ERR_OR_ZERO can be used
      
      Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
      
      Generated by: scripts/coccinelle/api/ptr_ret.cocci
      Signed-off-by: NVasyl Gomonovych <gomonovych@gmail.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      4404b336
  2. 06 12月, 2017 1 次提交
  3. 04 12月, 2017 1 次提交
  4. 01 12月, 2017 2 次提交
  5. 30 11月, 2017 2 次提交
  6. 29 11月, 2017 8 次提交
  7. 28 11月, 2017 1 次提交
    • J
      KVM: Let KVM_SET_SIGNAL_MASK work as advertised · 20b7035c
      Jan H. Schönherr 提交于
      KVM API says for the signal mask you set via KVM_SET_SIGNAL_MASK, that
      "any unblocked signal received [...] will cause KVM_RUN to return with
      -EINTR" and that "the signal will only be delivered if not blocked by
      the original signal mask".
      
      This, however, is only true, when the calling task has a signal handler
      registered for a signal. If not, signal evaluation is short-circuited for
      SIG_IGN and SIG_DFL, and the signal is either ignored without KVM_RUN
      returning or the whole process is terminated.
      
      Make KVM_SET_SIGNAL_MASK behave as advertised by utilizing logic similar
      to that in do_sigtimedwait() to avoid short-circuiting of signals.
      Signed-off-by: NJan H. Schönherr <jschoenh@amazon.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      20b7035c
  8. 10 11月, 2017 20 次提交