ff))
+pr_debug("Attempt to inject irq %d to offlined VCPU %d",
+ irq->intid, vcpu->vcpu_id);
+
/*
* We have to kick the VCPU here, because we could be
* queueing an edge-triggered interrupt for which we
--
1.8.3.1
On 2019/5/11 2:41, Marc Zyn
ch 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
Cc: Jason Cooper
Cc: Marc Zyngier
Signed-off-by: Heyi Guo
---
drivers/irqchip/ir
On 2019/5/11 21:34, Heyi Guo wrote:
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
homas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Signed-off-by: Heyi Guo
---
This patch has only been tested on 4.19.36, for my NIC device driver has
something wrong with mainline kernel, so I mark it as a RFC until test has been
done upon mainline kernel.
drivers/irqchip/irq-gic
Hi folks,
When guest OS calls PSCI CPU_OFF, the corresponding VCPU will be put in sleep
state. But if there is still IRQ remaining in this VCPU's ap_list, this will
block all the following triggers of this IRQ even to other VCPUs. Does it make
sense to flush the ap_list of the VCPU when it is
reports non-shareable, we must remove the
* cacheability attributes as well.
*/
Did I miss something?
Thanks,
Heyi
On 2019/5/9 15:58, Marc Zyngier wrote:
On Thu, 09 May 2019 08:10:09 +0100,
Heyi Guo wrote:
Hi Marc,
We can see in its_vpe_schedule() the shareability bits of
Thanks.
One more question about the cacheability of VPROPBASER, which is RaWb, while it
is RaWaWb for PROPBASER. Any special reason for this?
Heyi
On 2019/5/9 15:58, Marc Zyngier wrote:
On Thu, 09 May 2019 08:10:09 +0100,
Heyi Guo wrote:
Hi Marc,
We can see in its_vpe_schedule() the
Hi Marc,
We can see in its_vpe_schedule() the shareability bits of GICR_VPENDBASER are
set as non-shareable, But we set physical PENDBASER as inner-shareable. Is
there any special reason for doing this? If it is because the vpending table is
GICR specific, why don't we do the same for physical
Hi folks,
We observed deadlocks after enabling GICv4 and PCI passthrough on ARM64 virtual
machines, when not pinning VCPU to physical CPU.
We observed below warnings after enabling lockdep debug in kernel:
[ 362.847021] =
[ 362.855643] WARNI
On 2019/4/2 13:00, Marc Zyngier wrote:
On Mon, 01 Apr 2019 14:55:52 +0100,
Heyi Guo wrote:
Hi folks,
In current kernel implementation for ARM platform, all devices under
one PCI bridge share a same device ID and the total number of MSI
interrupts is fixed at the first time any child device
Hi folks,
In current kernel implementation for ARM platform, all devices under one PCI
bridge share a same device ID and the total number of MSI interrupts is fixed
at the first time any child device is allocating MSI. However, this may cause
failure of allocating MSI if the system supports de
Hi Marc,
Any comments?
Thanks,
Heyi
On 2019/1/24 21:37, Heyi Guo wrote:
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
causes memory corrupting. A new function
its_clear_vpend_valid() is added to reuse the code in
its_vpe_deschedule().
Signed-off-by: Heyi Guo
Signed-off-by: Heyi Guo
---
Notes:
v2:
- Also wait GICR_VPENDBASER.Dirty bit to be 0 in initialization [Marc]
- Add a new function to reuse the
On 2019/1/24 18:33, Marc Zyngier wrote:
On Wed, 23 Jan 2019 08:59:08 +,
Heyi Guo wrote:
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
causes memory corrupting.
Signed-off-by: Heyi Guo
Signed-off-by: Heyi Guo
---
drivers/irqchip/irq-gic-v3-its.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 3365d44..634c8a7 100644
--- a
Hi Marc,
Thanks for your feedback. Please see my comments below.
On 2019/1/22 17:53, Marc Zyngier wrote:
Hi Heyi,
On Mon, 21 Jan 2019 11:51:48 +,
Heyi Guo wrote:
Every VLPI will temporarily be mapped to the first CPU in system
(normally CPU0) and then moved to the real scheduled CPU
GICR will simply
drop the incoming VLPI, 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.
Signed-off-by: Heyi Guo
Signed-off-by: Heyi Guo
---
drivers
17 matches
Mail list logo
