1. 05 Sep, 2019 1 commit
  2. 20 Aug, 2019 1 commit
  3. 07 Aug, 2019 1 commit
  4. 26 Jul, 2019 1 commit
  5. 10 Jul, 2019 1 commit
  6. 19 Jun, 2019 1 commit
  7. 05 Jun, 2019 1 commit
    • Heyi Guo's avatar
      irqchip/gic-v3-its: Fix command queue pointer comparison bug · a050fa54
      Heyi Guo authored
      When we run several VMs with PCI passthrough and GICv4 enabled, not
      pinning vCPUs, we will occasionally see below warnings in dmesg:
      ITS queue timeout (65440 65504 480)
      ITS cmd its_build_vmovp_cmd failed
      The reason for the above issue is that in BUILD_SINGLE_CMD_FUNC:
      1. Post the write command.
      2. Release the lock.
      3. Start to read GITS_CREADR to get the reader pointer.
      4. Compare the reader pointer to the target pointer.
      5. If reader pointer does not reach the target, sleep 1us and continue
      to try.
      If we have several processors running the above concurrently, other
      CPUs will post write commands while the 1st CPU is waiting the
      completion. So we may have below issue:
      phase 1:
      wait 1us:
      phase 2:
      That is the rd_idx may fly ahead of to_idx, and if in case to_idx is
      near the wrap point, rd_idx will wrap around. So the below condition
      will not be met even after 1s:
      if (from_idx < to_idx && rd_idx >= to_idx)
      There is another theoretical issue. For a slow and busy ITS, the
      initial rd_idx may fall behind from_idx a lot, just as below:
      This will cause the wait function exit too early.
      Actually, it does not make much sense to use from_idx to judge if
      to_idx is wrapped, but we need a initial rd_idx when lock is still
      acquired, and it can be used to judge whether to_idx is wrapped and
      the current rd_idx is wrapped.
      We switch to a method of calculating the delta of two adjacent reads
      and accumulating it to get the sum, so that we can get the real rd_idx
      from the wrapped value even when the queue is almost full.
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarHeyi Guo <guoheyi@huawei.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  8. 03 May, 2019 1 commit
  9. 29 Apr, 2019 4 commits
  10. 04 Apr, 2019 1 commit
  11. 20 Mar, 2019 1 commit
  12. 21 Feb, 2019 1 commit
  13. 14 Feb, 2019 1 commit
  14. 29 Jan, 2019 2 commits
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Gracefully fail on LPI exhaustion · 45725e0f
      Marc Zyngier authored
      In the unlikely event that we cannot find any available LPI in the
      system, we should gracefully return an error instead of carrying
      on with no LPI allocated at all.
      Fixes: 38dd7c49
       ("irqchip/gic-v3-its: Drop chunk allocation compatibility")
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Plug allocation race for devices sharing a DevID · 9791ec7d
      Marc Zyngier authored
      On systems or VMs where multiple devices share a single DevID
      (because they sit behind a PCI bridge, or because the HW is
      broken in funky ways), we reuse the save its_device structure
      in order to reflect this.
      It turns out that there is a distinct lack of locking when looking
      up the its_device, and two device being probed concurrently can result
      in double allocations. That's obviously not nice.
      A solution for this is to have a per-ITS mutex that serializes device
      A similar issue exists on the freeing side, which can run concurrently
      with the allocation. On top of now taking the appropriate lock, we
      also make sure that a shared device is never freed, as we have no way
      to currently track the life cycle of such object.
      Reported-by: default avatarZheng Xiang <zhengxiang9@huawei.com>
      Tested-by: default avatarZheng Xiang <zhengxiang9@huawei.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  15. 28 Jan, 2019 1 commit
    • Heyi Guo's avatar
      irqchip/gic-v4: Fix occasional VLPI drop · 6479450f
      Heyi Guo authored
      1. In current implementation, every VLPI will temporarily be mapped to
      the first CPU in system (normally CPU0) and then moved to the real
      scheduled CPU later.
      2. So there is a time window and a VLPI may be sent to CPU0 instead of
      the real scheduled vCPU, in a multi-CPU virtual machine.
      3. However, CPU0 may have not been scheduled as a virtual CPU after
      system boots up, so the value of its GICR_VPROPBASER is unknown at
      that moment.
      4. If the INTID of VLPI is larger than 2^(GICR_VPROPBASER.IDbits+1),
      while IDbits is also in unknown state, GIC will behave as if the VLPI
      is out of range and simply drop it, which results in interrupt missing
      in Guest.
      As no code will clear GICR_VPROPBASER at runtime, we can safely
      initialize the IDbits field at boot time for each CPU to get rid of
      this issue.
      We also clear Valid bit of GICR_VPENDBASER in case any ancient
      programming gets left in and causes memory corrupting. A new function
      its_clear_vpend_valid() is added to reuse the code in
      Fixes: e643d803
       ("irqchip/gic-v3-its: Add VPE scheduling")
      Signed-off-by: default avatarHeyi Guo <guoheyi@huawei.com>
      Signed-off-by: default avatarHeyi Guo <heyi.guo@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  16. 18 Jan, 2019 1 commit
  17. 03 Oct, 2018 1 commit
  18. 02 Oct, 2018 9 commits
  19. 06 Sep, 2018 1 commit
  20. 06 Aug, 2018 1 commit
  21. 16 Jul, 2018 6 commits
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Honor hypervisor enforced LPI range · 12b2905a
      Marc Zyngier authored
      A recent extension to the GIC architecture allows a hypervisor to
      arbitrarily reduce the number of LPIs available to a guest, no
      matter what the GIC says about the valid range of IntIDs.
      Let's factor in this information when computing the number of
      available LPIs
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Marc Zyngier's avatar
      irqchip/gic-v3: Expose GICD_TYPER in the rdist structure · a4f9edb2
      Marc Zyngier authored
      Instead of exposing the GIC distributor IntID field in the rdist
      structure that is passed to the ITS, let's replace it with a
      copy of the whole GICD_TYPER register. We are going to need
      some of this information at a later time.
      No functionnal change.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Drop chunk allocation compatibility · 38dd7c49
      Marc Zyngier authored
      The chunk allocation system is now officially dead, so let's
      remove it.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Move minimum LPI requirements to individual busses · 147c8f37
      Marc Zyngier authored
      At the moment, the core ITS driver imposes the allocation to be
      in chunks of 32. As we want to relax this on a per bus basis, let's
      move the the the allocation constraints to each bus.
      No functionnal change.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Use full range of LPIs · fe8e9350
      Marc Zyngier authored
      As we used to represent the LPI range using a bitmap, we were reducing
      the number of LPIs to at most 64k in order to preserve memory.
      With our new allocator, there is no such need, as dealing with 2^16
      or 2^32 LPIs takes the same amount of memory.
      So let's use the number of IntID bits reported by the GIC instead of
      an arbitrary limit.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Refactor LPI allocator · 880cb3cd
      Marc Zyngier authored
      Our current LPI allocator relies on a bitmap, each bit representing
      a chunk of 32 LPIs, meaning that each device gets allocated LPIs
      in multiple of 32. It served us well so far, but new use cases now
      require much more finer grain allocations, down the the individual
      Given the size of the IntID space (up to 32bit), it isn't practical
      to continue using a bitmap, so let's use a different data structure
      We switch to a list, where each element represent a contiguous range
      of LPIs. On allocation, we simply grab the first group big enough to
      satisfy the allocation, and substract what we need from it. If the
      group becomes empty, we just remove it. On freeing interrupts, we
      insert a new group of interrupt in the list, sort it and fuse the
      adjacent groups.
      This makes freeing interrupt much more expensive than allocating
      them (an unusual behaviour), but that's fine as long as we consider
      that freeing interrupts is an extremely rare event.
      We still allocate interrupts in blocks of 32 for the time being,
      but subsequent patches will relax this.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  22. 22 Jun, 2018 2 commits