From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F00FBC63777 for ; Sat, 28 Nov 2020 21:53:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 96F2720857 for ; Sat, 28 Nov 2020 21:53:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="DX+4yz5L" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403867AbgK1Vw6 (ORCPT ); Sat, 28 Nov 2020 16:52:58 -0500 Received: from mail.kernel.org ([198.145.29.99]:50828 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732956AbgK1TEl (ORCPT ); Sat, 28 Nov 2020 14:04:41 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AEC472227F; Sat, 28 Nov 2020 10:18:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606558721; bh=4K4X/pL32QVFFBl2rnovrBaaN+h/s2sY0/tghuUMP8s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DX+4yz5LojYRxgrgRN0cSxh4/25S2hC6Esddy5FCBbWqips6zrCKMUIGQS76mN3El gGbArn+vgKWdh8etIgtLknJAexa6jZjCpFx0g0cmeiZFtbQP1w1CHqy8GVDbrw+WNU yVl26lz/XrME1QvJHRvuMdChBRFxN70mgCCa5iRY= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kixJP-00EGFN-1l; Sat, 28 Nov 2020 10:18:39 +0000 Date: Sat, 28 Nov 2020 10:18:38 +0000 Message-ID: <875z5p6ayp.wl-maz@kernel.org> From: Marc Zyngier To: luojiaxing Cc: Shenming Lu , "James Morse" , Julien Thierry , Suzuki K Poulose , Eric Auger , , , , , Christoffer Dall , Alex Williamson , Kirti Wankhede , Cornelia Huck , Neo Jia , , Subject: Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback In-Reply-To: <869dbc36-c510-fd00-407a-b05e068537c8@huawei.com> References: <20201123065410.1915-1-lushenming@huawei.com> <20201123065410.1915-2-lushenming@huawei.com> <869dbc36-c510-fd00-407a-b05e068537c8@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: luojiaxing@huawei.com, lushenming@huawei.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, eric.auger@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, christoffer.dall@arm.com, alex.williamson@redhat.com, kwankhede@nvidia.com, cohuck@redhat.com, cjia@nvidia.com, wanghaibin.wang@huawei.com, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 28 Nov 2020 07:19:48 +0000, luojiaxing 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 > > > > 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 > > Signed-off-by: Shenming Lu > > --- > > 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.