On Sat, 28 Nov 2020 07:19:48 +0000,
luojiaxing [off-list ref] 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:

quoted

From: Zenghui Yu <yuzenghui@huawei.com>

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? And that LPIs
have a radically different programming interface to the rest of the GIC?

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.

quoted

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@huawei.com>
Signed-off-by: Shenming Lu <redacted>
---
  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."

An implementation that wouldn't follow this simple rule would simply
be totally broken, and unsupported.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel