linux-kernel - Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <875z5p6ayp.wl-maz@kernel.org>
Date:   Sat, 28 Nov 2020 10:18:38 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     luojiaxing <luojiaxing@...wei.com>
Cc:     Shenming Lu <lushenming@...wei.com>,
        "James Morse" <james.morse@....com>,
        Julien Thierry <julien.thierry.kdev@...il.com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Eric Auger <eric.auger@...hat.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <kvmarm@...ts.cs.columbia.edu>, <kvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Christoffer Dall <christoffer.dall@....com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Kirti Wankhede <kwankhede@...dia.com>,
        Cornelia Huck <cohuck@...hat.com>, Neo Jia <cjia@...dia.com>,
        <wanghaibin.wang@...wei.com>, <yuzenghui@...wei.com>
Subject: Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback

On Sat, 28 Nov 2020 07:19:48 +0000,
luojiaxing <luojiaxing@...wei.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@...wei.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.

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

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.