Messages in this thread | | | Subject | Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback | From | luojiaxing <> | Date | Tue, 1 Dec 2020 17:38:12 +0800 |
| |
On 2020/11/28 18:18, Marc Zyngier wrote: > On Sat, 28 Nov 2020 07:19:48 +0000, > luojiaxing <luojiaxing@huawei.com> 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@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?
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@huawei.com> >>> Signed-off-by: Shenming Lu <lushenming@huawei.com> >>> --- >>> 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. >
| |