16 Oct, 2014

1 commit

  • The EIRSR and ELRSR registers are 32-bit registers on GICv2, and we
    store these as an array of two such registers on the vgic vcpu struct.
    However, we access them as a single 64-bit value or as a bitmap pointer
    in the generic vgic code, which breaks BE support.

    Instead, store them as u64 values on the vgic structure and do the
    word-swapping in the assembly code, which already handles the byte order
    for BE systems.

    Tested-by: Victor Kamensky
    Acked-by: Marc Zyngier
    Signed-off-by: Christoffer Dall

    Christoffer Dall
     

07 Oct, 2014

1 commit

  • The vgic code can be disabled in Kconfig and there are dummy implementations
    of most of the provided API functions for the disabled case.

    However, the newly introduced kvm_vgic_destroy/kvm_vgic_vcpu_destroy
    functions are lacking those dummies, resulting in this build error:

    arch/arm/kvm/arm.c: In function 'kvm_arch_destroy_vm':
    arch/arm/kvm/arm.c:165:2: error: implicit declaration of function 'kvm_vgic_destroy' [-Werror=implicit-function-declaration]
    kvm_vgic_destroy(kvm);
    ^
    arch/arm/kvm/arm.c: In function 'kvm_arch_vcpu_free':
    arch/arm/kvm/arm.c:248:2: error: implicit declaration of function 'kvm_vgic_vcpu_destroy' [-Werror=implicit-function-declaration]
    kvm_vgic_vcpu_destroy(vcpu);
    ^

    This adds two inline helpers to get it to build again in this configuration.

    Signed-off-by: Arnd Bergmann
    Fixes: c1bfb577add ("arm/arm64: KVM: vgic: switch to dynamic allocation")
    Signed-off-by: Christoffer Dall

    Arnd Bergmann
     

19 Sep, 2014

9 commits

  • It is now quite easy to delay the allocation of the vgic tables
    until we actually require it to be up and running (when the first
    vcpu is kicking around, or someones tries to access the GIC registers).

    This allow us to allocate memory for the exact number of CPUs we
    have. As nobody configures the number of interrupts just yet,
    use a fallback to VGIC_NR_IRQS_LEGACY.

    Reviewed-by: Christoffer Dall
    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • Nuke VGIC_NR_IRQS entierly, now that the distributor instance
    contains the number of IRQ allocated to this GIC.

    Also add VGIC_NR_IRQS_LEGACY to preserve the current API.

    Reviewed-by: Christoffer Dall
    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • Now that we can (almost) dynamically size the number of interrupts,
    we're facing an interesting issue:

    We have to evaluate at runtime whether or not an access hits a valid
    register, based on the sizing of this particular instance of the
    distributor. Furthermore, the GIC spec says that accessing a reserved
    register is RAZ/WI.

    For this, add a new field to our range structure, indicating the number
    of bits a single interrupts uses. That allows us to find out whether or
    not the access is in range.

    Reviewed-by: Christoffer Dall
    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • We now have the information about the number of CPU interfaces in
    the distributor itself. Let's get rid of VGIC_MAX_CPUS, and just
    rely on KVM_MAX_VCPUS where we don't have the choice. Yet.

    Reviewed-by: Christoffer Dall
    Signed-off-by: Marc Zyngier

    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: Christoffer Dall
    Signed-off-by: Marc Zyngier

    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: Marc Zyngier

    Marc Zyngier
     
  • 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: Christoffer Dall

    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: Christoffer Dall

    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: Marc Zyngier
    Signed-off-by: Christoffer Dall

    Christoffer Dall
     

11 Jul, 2014

14 commits


06 Mar, 2014

1 commit

  • Add a stub for kvm_vgic_addr when compiling without
    CONFIG_KVM_ARM_VGIC. The usefulness of this configurarion is extremely
    doubtful, but let's fix it anyway (until we decide that we'll always
    support a VGIC).

    Reported-by: Michele Paolino
    Cc: Paolo Bonzini
    Cc: Christoffer Dall
    Signed-off-by: Marc Zyngier
    Signed-off-by: Paolo Bonzini

    Marc Zyngier
     

22 Dec, 2013

1 commit

  • Support setting the distributor and cpu interface base addresses in the
    VM physical address space through the KVM_{SET,GET}_DEVICE_ATTR API
    in addition to the ARM specific API.

    This has the added benefit of being able to share more code in user
    space and do things in a uniform manner.

    Also deprecate the older API at the same time, but backwards
    compatibility will be maintained.

    Acked-by: Marc Zyngier
    Signed-off-by: Christoffer Dall

    Christoffer Dall
     

30 Aug, 2013

1 commit

  • The Versatile Express TC2 board, which we use as our main emulated
    platform in QEMU, defines 160+32 == 192 interrupts, so limiting the
    number of interrupts to 128 is not quite going to cut it for real board
    emulation.

    Note that this didn't use to be a problem because QEMU was buggy and
    only defined 128 interrupts until recently.

    Signed-off-by: Christoffer Dall
    Signed-off-by: Marc Zyngier
    Signed-off-by: Gleb Natapov

    Christoffer Dall
     

27 Jun, 2013

1 commit

  • The arch_timer irq numbers (or PPI numbers) are implementation dependent,
    so the host virtual timer irq number can be different from guest virtual
    timer irq number.

    This patch ensures that host virtual timer irq number is read from DTB and
    guest virtual timer irq is determined based on vcpu target type.

    Signed-off-by: Anup Patel
    Signed-off-by: Pranavkumar Sawargaonkar
    Signed-off-by: Christoffer Dall

    Anup Patel
     

19 May, 2013

1 commit

  • 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: Marc Zyngier
    Signed-off-by: Gleb Natapov

    Marc Zyngier