On 2020/11/28 18:18, Marc Zyngier wrote:
On Sat, 28 Nov 2020 07:19:48 +0000,
luojiaxing <luojiaxing@xxxxxxxxxx> wrote:
Hi, shenming
I got few questions about this patch.
Although it's a bit late and not very appropriate, I'd like to ask
before you send next version.
On 2020/11/23 14:54, Shenming Lu wrote:
From: Zenghui Yu <yuzenghui@xxxxxxxxxx>
Up to now, the irq_get_irqchip_state() callback of its_irq_chip
leaves unimplemented since there is no architectural way to get
the VLPI's pending state before GICv4.1. Yeah, there has one in
v4.1 for VLPIs.
I checked the invoking scenario of irq_get_irqchip_state and found no
scenario related to vLPI.
For example, synchronize_irq(), it pass IRQCHIP_STATE_ACTIVE to which,
so in your patch, you will directly return and other is for vSGI,
GICD_ISPENDR, GICD_ICPENDR and so on.
You do realise that LPIs have no active state, right?
yes, I know
And that LPIs
have a radically different programming interface to the rest of the GIC?
I found out that my mailbox software filtered out the other two patches,
which led me to look at the patch alone, so it was weird. I already got
the answer now.
The only one I am not sure is vgic_get_phys_line_level(), is it your
purpose to fill this callback, or some scenarios I don't know about
that use this callback.
LPIs only offer edge signalling, so the concept of "line level" means
absolutely nothing.
With GICv4.1, after unmapping the vPE, which cleans and invalidates
any caching of the VPT, we can get the VLPI's pending state by
peeking at the VPT. So we implement the irq_get_irqchip_state()
callback of its_irq_chip to do it.
Signed-off-by: Zenghui Yu <yuzenghui@xxxxxxxxxx>
Signed-off-by: Shenming Lu <lushenming@xxxxxxxxxx>
---
drivers/irqchip/irq-gic-v3-its.c | 38 ++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0fec31931e11..287003cacac7 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1695,6 +1695,43 @@ static void its_irq_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
iommu_dma_compose_msi_msg(irq_data_get_msi_desc(d), msg);
}
+static bool its_peek_vpt(struct its_vpe *vpe, irq_hw_number_t
hwirq)
+{
+ int mask = hwirq % BITS_PER_BYTE;
+ void *va;
+ u8 *pt;
+
+ va = page_address(vpe->vpt_page);
+ pt = va + hwirq / BITS_PER_BYTE;
+
+ return !!(*pt & (1U << mask));
How can you confirm that the interrupt pending status is the latest?
Is it possible that the interrupt pending status is still cached in
the GICR but not synchronized to the memory.
That's a consequence of the vPE having been unmapped:
"A VMAPP with {V,Alloc}=={0,1} cleans and invalidates any caching of
the Virtual Pending Table and Virtual Configuration Table associated
with the vPEID held in the GIC."
Yes, in addition to that, if a vPE is scheduled out of the PE, the cache
clearing and write-back to VPT are also performed, I think.
However, I feel a litter confusing to read this comment at first ,
because it is not only VMAPP that causes cache clearing.
I don't know why VMAPP was mentioned here until I check the other two
patches ("KVM: arm64: GICv4.1: Try to save hw pending state in
save_pending_tables").
So I think may be it's better to add some background description here.
Thanks
Jiaxing
An implementation that wouldn't follow this simple rule would simply
be totally broken, and unsupported.
M.
