1. 19 9月, 2014 5 次提交
    • M
      arm/arm64: KVM: vgic: Parametrize VGIC_NR_SHARED_IRQS · fb65ab63
      Marc Zyngier 提交于
      Having a dynamic number of supported interrupts means that we
      cannot relly on VGIC_NR_SHARED_IRQS being fixed anymore.
      
      Instead, make it take the distributor structure as a parameter,
      so it can return the right value.
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      fb65ab63
    • M
      arm/arm64: KVM: vgic: switch to dynamic allocation · c1bfb577
      Marc Zyngier 提交于
      So far, all the VGIC data structures are statically defined by the
      *maximum* number of vcpus and interrupts it supports. It means that
      we always have to oversize it to cater for the worse case.
      
      Start by changing the data structures to be dynamically sizeable,
      and allocate them at runtime.
      
      The sizes are still very static though.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      c1bfb577
    • C
      arm/arm64: KVM: vgic: Improve handling of GICD_I{CS}PENDRn · faa1b46c
      Christoffer Dall 提交于
      Writes to GICD_ISPENDRn and GICD_ICPENDRn are currently not handled
      correctly for level-triggered interrupts.  The spec states that for
      level-triggered interrupts, writes to the GICD_ISPENDRn activate the
      output of a flip-flop which is in turn or'ed with the actual input
      interrupt signal.  Correspondingly, writes to GICD_ICPENDRn simply
      deactivates the output of that flip-flop, but does not (of course) affect
      the external input signal.  Reads from GICC_IAR will also deactivate the
      flip-flop output.
      
      This requires us to track the state of the level-input separately from
      the state in the flip-flop.  We therefore introduce two new variables on
      the distributor struct to track these two states.  Astute readers may
      notice that this is introducing more state than required (because an OR
      of the two states gives you the pending state), but the remaining vgic
      code uses the pending bitmap for optimized operations to figure out, at
      the end of the day, if an interrupt is pending or not on the distributor
      side.  Refactoring the code to consider the two state variables all the
      places where we currently access the precomputed pending value, did not
      look pretty.
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      faa1b46c
    • C
      arm/arm64: KVM: Rename irq_active to irq_queued · dbf20f9d
      Christoffer Dall 提交于
      We have a special bitmap on the distributor struct to keep track of when
      level-triggered interrupts are queued on the list registers.  This was
      named irq_active, which is confusing, because the active state of an
      interrupt as per the GIC spec is a different thing, not specifically
      related to edge-triggered/level-triggered configurations but rather
      indicates an interrupt which has been ack'ed but not yet eoi'ed.
      
      Rename the bitmap and the corresponding accessor functions to irq_queued
      to clarify what this is actually used for.
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      dbf20f9d
    • C
      arm/arm64: KVM: Rename irq_state to irq_pending · 227844f5
      Christoffer Dall 提交于
      The irq_state field on the distributor struct is ambiguous in its
      meaning; the comment says it's the level of the input put, but that
      doesn't make much sense for edge-triggered interrupts.  The code
      actually uses this state variable to check if the interrupt is in the
      pending state on the distributor so clarify the comment and rename the
      actual variable and accessor methods.
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      227844f5
  2. 11 7月, 2014 13 次提交
  3. 06 3月, 2014 1 次提交
  4. 22 12月, 2013 1 次提交
  5. 30 8月, 2013 1 次提交
  6. 19 5月, 2013 1 次提交
    • M
      ARM: KVM: move GIC/timer code to a common location · 7275acdf
      Marc Zyngier 提交于
      As KVM/arm64 is looming on the horizon, it makes sense to move some
      of the common code to a single location in order to reduce duplication.
      
      The code could live anywhere. Actually, most of KVM is already built
      with a bunch of ugly ../../.. hacks in the various Makefiles, so we're
      not exactly talking about style here. But maybe it is time to start
      moving into a less ugly direction.
      
      The include files must be in a "public" location, as they are accessed
      from non-KVM files (arch/arm/kernel/asm-offsets.c).
      
      For this purpose, introduce two new locations:
      - virt/kvm/arm/ : x86 and ia64 already share the ioapic code in
        virt/kvm, so this could be seen as a (very ugly) precedent.
      - include/kvm/  : there is already an include/xen, and while the
        intent is slightly different, this seems as good a location as
        any
      
      Eventually, we should probably have independant Makefiles at every
      levels (just like everywhere else in the kernel), but this is just
      the first step.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      7275acdf
  7. 07 3月, 2013 1 次提交
  8. 12 2月, 2013 6 次提交