1. 08 Feb, 2020 3 commits
  2. 03 Feb, 2020 1 commit
  3. 22 Jan, 2020 13 commits
  4. 10 Nov, 2019 12 commits
  5. 24 Oct, 2019 1 commit
    • Zenghui Yu's avatar
      irqchip/gic-v3-its: Use the exact ITSList for VMOVP · 84243125
      Zenghui Yu authored
      On a system without Single VMOVP support (say GITS_TYPER.VMOVP == 0),
      we will map vPEs only on ITSs that will actually control interrupts
      for the given VM.  And when moving a vPE, the VMOVP command will be
      issued only for those ITSs.
      But when issuing VMOVPs we seemed fail to present the exact ITSList
      to ITSs who are actually included in the synchronization operation.
      The its_list_map we're currently using includes all ITSs in the system,
      even though some of them don't have the corresponding vPE mapping at all.
      Introduce get_its_list() to get the per-VM its_list_map, to indicate
      which ITSs have vPE mappings for the given VM, and use this map as
      the expected ITSList when building VMOVP. This is hopefully a performance
      gain not to do some synchronization with those unsuspecting ITSs.
      And initialize the whole command descriptor to zero at beginning, since
      the seq_num and its_list should be RES0 when GITS_TYPER.VMOVP == 1.
      Signed-off-by: default avatarZenghui Yu <yuzenghui@huawei.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Link: https://lore.kernel.org/r/1571802386-2680-1-git-send-email-yuzenghui@huawei.com
  6. 05 Sep, 2019 1 commit
  7. 20 Aug, 2019 1 commit
  8. 07 Aug, 2019 1 commit
  9. 26 Jul, 2019 1 commit
  10. 10 Jul, 2019 1 commit
  11. 19 Jun, 2019 1 commit
  12. 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>
  13. 03 May, 2019 1 commit
  14. 29 Apr, 2019 2 commits