24 Mar, 2020

5 commits

  • Add the SGI configuration entry point for KVM to use.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Link: https://lore.kernel.org/r/20200304203330.4967-16-maz@kernel.org

    Marc Zyngier
     
  • Allocate per-VPE SGIs when initializing the GIC-specific part of the
    VPE data structure.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Link: https://lore.kernel.org/r/20200304203330.4967-15-maz@kernel.org

    Marc Zyngier
     
  • In order to hide some of the differences between v4.0 and v4.1, move
    the doorbell management out of the KVM code, and into the GICv4-specific
    layer. This allows the calling code to ask for the doorbell when blocking,
    and otherwise to leave the doorbell permanently disabled.

    This matches the v4.1 code perfectly, and only results in a minor
    refactoring of the v4.0 code.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Link: https://lore.kernel.org/r/20200304203330.4967-14-maz@kernel.org

    Marc Zyngier
     
  • Just like for vLPIs, there is some configuration information that cannot
    be directly communicated through the normal irqchip API, and we have to
    use our good old friend set_vcpu_affinity as a side-band communication
    mechanism.

    This is used to configure group and priority for a given vSGI.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Reviewed-by: Eric Auger
    Link: https://lore.kernel.org/r/20200304203330.4967-13-maz@kernel.org

    Marc Zyngier
     
  • Since GICv4.1 has the capability to inject 16 SGIs into each VPE,
    and that I'm keen not to invent too many specific interfaces to
    manipulate these interrupts, let's pretend that each of these SGIs
    is an actual Linux interrupt.

    For that matter, let's introduce a minimal irqchip and irqdomain
    setup that will get fleshed up in the following patches.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Reviewed-by: Eric Auger
    Link: https://lore.kernel.org/r/20200304203330.4967-9-maz@kernel.org

    Marc Zyngier
     

19 Mar, 2020

1 commit

  • Before GICv4.1, all operations would be serialized with the affinity
    changes by virtue of using the same ITS command queue. With v4.1, things
    change, as invalidations (and a number of other operations) are issued
    using the redistributor MMIO frame.

    We must thus make sure that these redistributor accesses cannot race
    against aginst the affinity change, or we may end-up talking to the
    wrong redistributor.

    To ensure this, we expand the irq_to_cpuid() helper to take a spinlock
    when the LPI is mapped to a vLPI (a new per-VPE lock) on each operation
    that requires mutual exclusion.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Link: https://lore.kernel.org/r/20200304203330.4967-4-maz@kernel.org

    Marc Zyngier
     

22 Jan, 2020

2 commits

  • Making a VPE resident on GICv4.1 is pretty simple, as it is just a
    single write to the local redistributor. We just need extra information
    about which groups to enable, which the KVM code will have to provide.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Link: https://lore.kernel.org/r/20191224111055.11836-12-maz@kernel.org

    Marc Zyngier
     
  • The ITS VMAPP command gains some new fields with GICv4.1:
    - a default doorbell, which allows a single doorbell to be used for
    all the VLPIs routed to a given VPE
    - a pointer to the configuration table (instead of having it in a register
    that gets context switched)
    - a flag indicating whether this is the first map or the last unmap for
    this particular VPE
    - a flag indicating whether the pending table is known to be zeroed, or not

    Plumb in the new fields in the VMAPP builder, and add the map/unmap
    refcounting so that the ITS can do the right thing.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Link: https://lore.kernel.org/r/20191224111055.11836-7-maz@kernel.org

    Marc Zyngier
     

08 Nov, 2019

1 commit

  • In order to find out whether a vcpu is likely to be the target of
    VLPIs (and to further optimize the way we deal with those), let's
    track the number of VLPIs a vcpu can receive.

    This gets implemented with an atomic variable that gets incremented
    or decremented on map, unmap and move of a VLPI.

    Signed-off-by: Marc Zyngier
    Reviewed-by: Zenghui Yu
    Reviewed-by: Christoffer Dall
    Link: https://lore.kernel.org/r/20191107160412.30301-2-maz@kernel.org

    Marc Zyngier
     

29 Oct, 2019

1 commit

  • When the VHE code was reworked, a lot of the vgic stuff was moved around,
    but the GICv4 residency code did stay untouched, meaning that we come
    in and out of residency on each flush/sync, which is obviously suboptimal.

    To address this, let's move things around a bit:

    - Residency entry (flush) moves to vcpu_load
    - Residency exit (sync) moves to vcpu_put
    - On blocking (entry to WFI), we "put"
    - On unblocking (exit from WFI), we "load"

    Because these can nest (load/block/put/load/unblock/put, for example),
    we now have per-VPE tracking of the residency state.

    Additionally, vgic_v4_put gains a "need doorbell" parameter, which only
    gets set to true when blocking because of a WFI. This allows a finer
    control of the doorbell, which now also gets disabled as soon as
    it gets signaled.

    Signed-off-by: Marc Zyngier
    Link: https://lore.kernel.org/r/20191027144234.8395-2-maz@kernel.org

    Marc Zyngier
     

19 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation this program is
    distributed in the hope that it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose see the gnu general public license
    for more details you should have received a copy of the gnu general
    public license along with this program if not see http www gnu org
    licenses

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 503 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Alexios Zavras
    Reviewed-by: Allison Randal
    Reviewed-by: Enrico Weigelt
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190602204653.811534538@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

14 Nov, 2017

1 commit


02 Nov, 2017

1 commit

  • So far, we require the hypervisor to update the VLPI properties
    once the the VLPI mapping has been established. While this
    makes it easy for the ITS driver, it creates a window where
    an incoming interrupt can be delivered with an unknown set
    of properties. Not very nice.

    Instead, let's add a "properties" field to the mapping structure,
    and use that to configure the VLPI before it actually gets mapped.

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

    Marc Zyngier
     

19 Oct, 2017

2 commits

  • So far, we map all VPEs on all ITSs. While this is not wrong,
    this is quite a big hammer, as moving a VPE around requires
    all ITSs to be synchronized. Needles to say, this is an
    expensive proposition.

    Instead, let's switch to a mode where we issue VMAPP commands
    only on ITSs that are actually involved in reporting interrupts
    to the given VM.

    For that purpose, we refcount the number of interrupts are are
    mapped for this VM on each ITS, performing the map/unmap
    operations as required. It then allows us to use this refcount
    to only issue VMOVP to the ITSs that need to know about this
    VM.

    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • As we're about to make use of the maximum number of ITSs in
    a GICv4 system, let's make this value global (and rename it to
    GICv4_ITS_LIST_MAX).

    Signed-off-by: Marc Zyngier

    Marc Zyngier
     

31 Aug, 2017

6 commits

  • Get the show on the road...

    Reviewed-by: Thomas Gleixner
    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • Add the required interfaces to map, unmap and update a VLPI.

    Reviewed-by: Eric Auger
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • Add the required interfaces to schedule a VPE and perform a
    VINVALL command.

    Reviewed-by: Thomas Gleixner
    Reviewed-by: Eric Auger
    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • When creating a VM, it is very convenient to have an irq domain
    containing all the doorbell interrupts associated with that VM
    (each interrupt representing a VPE).

    Reviewed-by: Thomas Gleixner
    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • When we don't have the DirectLPI feature, we must work around the
    architecture shortcomings to be able to perform the required
    maintenance (interrupt masking, clearing and injection).

    For this, we create a fake device whose sole purpose is to
    provide a way to issue commands as if we were dealing with LPIs
    coming from that device (while they actually originate from
    the ITS). This fake device doesn't have LPIs allocated to it,
    but instead uses the VPE LPIs.

    Of course, this could be a real bottleneck, and a naive
    implementation would require 6 commands to issue an invalidation.

    Instead, let's allocate at least one event per physical CPU
    (rounded up to the next power of 2), and opportunistically
    map the VPE doorbell to an event. This doorbell will be mapped
    until we roll over and need to reallocate this slot.

    This ensures that most of the time, we only need 2 commands
    to issue an INV, INT or CLEAR, making the performance a lot
    better, given that we always issue a CLEAR on entry, and
    an INV on each side of a trapped WFI.

    Signed-off-by: Marc Zyngier

    Marc Zyngier
     
  • Add a bunch of GICv4-specific data structures that will get used in
    subsequent patches.

    Reviewed-by: Thomas Gleixner
    Signed-off-by: Marc Zyngier

    Marc Zyngier