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. 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=-13.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 7D31EC63697 for ; Sat, 28 Nov 2020 10:18:48 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id A56DF222C2 for ; Sat, 28 Nov 2020 10:18:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="DX+4yz5L" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A56DF222C2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DA0AF4BAE0; Sat, 28 Nov 2020 05:18:46 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zl-7cfIwlAG; Sat, 28 Nov 2020 05:18:45 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9F25B4BAE3; Sat, 28 Nov 2020 05:18:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 704C84BA7B for ; Sat, 28 Nov 2020 05:18:44 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnK1qCi6e3ZW for ; Sat, 28 Nov 2020 05:18:43 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 330B34BA58 for ; Sat, 28 Nov 2020 05:18:43 -0500 (EST) 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 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") 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 Cc: Cornelia Huck , Neo Jia , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Kirti Wankhede , Shenming Lu , Alex Williamson , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 8B96DC63697 for ; Sat, 28 Nov 2020 10:20:20 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F2302222BA for ; Sat, 28 Nov 2020 10:20:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zxolIu3n"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="DX+4yz5L" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2302222BA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ZJRyvSY+hGfIeKMS8mgESmNee4zpyrYjLH8hadEBmIA=; b=zxolIu3nOlefYFL8hT/WoHZos eTaNZTChHGEWADxs+LPqkJpXp6zbyD79s4kj7zzZuy647TOmTXzMR+Y45pw5+7HsVIdR98zyyY1dd tmvxFNGo8h1B3YDxPJfiAZNsxdpg13J5vP6Miq6qK8k4JDkdkHNxS6PAN92dNUSPwYfHcYV2HkHCb 4UIqYx2kTkfDMpuGB8cfKumq7lTIhnEO7igCwCBPZfe8h9mRQH3hJgAUoMH6sGwiv4o+BBFAwFWgk CRXHGBO7Yvx3HVl23zgqBtFVAVnSqAPIitPCkGug8kr6cQQ+aVocEcpST5TcKarowOMViEHvf/Yg0 f7BrszXqg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kixJe-0006Zg-NU; Sat, 28 Nov 2020 10:18:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kixJS-0006Y2-Oi for linux-arm-kernel@lists.infradead.org; Sat, 28 Nov 2020 10:18:43 +0000 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 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") 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201128_051842_996371_6FD5A086 X-CRM114-Status: GOOD ( 32.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Cornelia Huck , Neo Jia , kvm@vger.kernel.org, Eric Auger , Suzuki K Poulose , linux-kernel@vger.kernel.org, Kirti Wankhede , Christoffer Dall , Shenming Lu , Alex Williamson , James Morse , Julien Thierry , yuzenghui@huawei.com, wanghaibin.wang@huawei.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel