Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 1月, 2020 3 次提交
  3. 11 11月, 2019 12 次提交
  5. 25 10月, 2019 1 次提交
    • Z
      irqchip/gic-v3-its: Use the exact ITSList for VMOVP · 84243125
      由 Zenghui Yu 提交于 
      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: NZenghui Yu <yuzenghui@huawei.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1571802386-2680-1-git-send-email-yuzenghui@huawei.com
      84243125
  7. 05 9月, 2019 1 次提交
  9. 20 8月, 2019 1 次提交
  11. 07 8月, 2019 1 次提交
  13. 26 7月, 2019 1 次提交
  15. 10 7月, 2019 1 次提交
  17. 19 6月, 2019 1 次提交
  19. 05 6月, 2019 1 次提交
    • H
      irqchip/gic-v3-its: Fix command queue pointer comparison bug · a050fa54
      由 Heyi Guo 提交于 
      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:
---rd_idx-----from_idx-----to_idx--0---------

wait 1us:

phase 2:
--------------from_idx-----to_idx--0-rd_idx--

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:

---rd_idx---0--from_idx-----to_idx-----------

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: NHeyi Guo <guoheyi@huawei.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      a050fa54
  21. 03 5月, 2019 1 次提交
  23. 29 4月, 2019 4 次提交
  25. 05 4月, 2019 1 次提交
  27. 21 3月, 2019 1 次提交
  29. 21 2月, 2019 1 次提交
  31. 14 2月, 2019 1 次提交
  33. 29 1月, 2019 3 次提交
    • M
      irqchip/gic-v3-its: Gracefully fail on LPI exhaustion · 45725e0f
      由 Marc Zyngier 提交于 
      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: NMarc Zyngier <marc.zyngier@arm.com>
      45725e0f
    • M
      irqchip/gic-v3-its: Plug allocation race for devices sharing a DevID · 9791ec7d
      由 Marc Zyngier 提交于 
      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
allocation.

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: NZheng Xiang <zhengxiang9@huawei.com>
Tested-by: NZheng Xiang <zhengxiang9@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      9791ec7d
    • H
      irqchip/gic-v4: Fix occasional VLPI drop · 6479450f
      由 Heyi Guo 提交于 
      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
its_vpe_deschedule().

Fixes: e643d803 ("irqchip/gic-v3-its: Add VPE scheduling")
Signed-off-by: NHeyi Guo <guoheyi@huawei.com>
Signed-off-by: NHeyi Guo <heyi.guo@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      6479450f
  35. 18 1月, 2019 1 次提交
  37. 03 10月, 2018 1 次提交
  39. 02 10月, 2018 3 次提交