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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 E682BC71155 for ; Sat, 28 Nov 2020 17:59:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BD626246EB for ; Sat, 28 Nov 2020 17:59:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725298AbgK1R7A (ORCPT ); Sat, 28 Nov 2020 12:59:00 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:8525 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733142AbgK1R4k (ORCPT ); Sat, 28 Nov 2020 12:56:40 -0500 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4CjjYP0G0Lzhgks; Sat, 28 Nov 2020 15:19:37 +0800 (CST) Received: from [127.0.0.1] (10.57.22.126) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Sat, 28 Nov 2020 15:19:49 +0800 Subject: Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback To: Shenming Lu , Marc Zyngier , "James Morse" , Julien Thierry , Suzuki K Poulose , Eric Auger , , , , , Christoffer Dall CC: Alex Williamson , Kirti Wankhede , Cornelia Huck , Neo Jia , , References: <20201123065410.1915-1-lushenming@huawei.com> <20201123065410.1915-2-lushenming@huawei.com> From: luojiaxing Message-ID: <869dbc36-c510-fd00-407a-b05e068537c8@huawei.com> Date: Sat, 28 Nov 2020 15:19:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20201123065410.1915-2-lushenming@huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.57.22.126] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. > > 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. Thanks Jiaxing > +} > + > +static int its_irq_get_irqchip_state(struct irq_data *d, > + enum irqchip_irq_state which, bool *val) > +{ > + struct its_device *its_dev = irq_data_get_irq_chip_data(d); > + struct its_vlpi_map *map = get_vlpi_map(d); > + > + if (which != IRQCHIP_STATE_PENDING) > + return -EINVAL; > + > + /* not intended for physical LPI's pending state */ > + if (!map) > + return -EINVAL; > + > + /* > + * In GICv4.1, a VMAPP with {V,Alloc}=={0,1} cleans and invalidates > + * any caching of the VPT associated with the vPEID held in the GIC. > + */ > + if (!is_v4_1(its_dev->its) || atomic_read(&map->vpe->vmapp_count)) > + return -EACCES; > + > + *val = its_peek_vpt(map->vpe, map->vintid); > + > + return 0; > +} > + > static int its_irq_set_irqchip_state(struct irq_data *d, > enum irqchip_irq_state which, > bool state) > @@ -1975,6 +2012,7 @@ static struct irq_chip its_irq_chip = { > .irq_eoi = irq_chip_eoi_parent, > .irq_set_affinity = its_set_affinity, > .irq_compose_msi_msg = its_irq_compose_msi_msg, > + .irq_get_irqchip_state = its_irq_get_irqchip_state, > .irq_set_irqchip_state = its_irq_set_irqchip_state, > .irq_retrigger = its_irq_retrigger, > .irq_set_vcpu_affinity = its_irq_set_vcpu_affinity, 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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 BCF55C63798 for ; Sat, 28 Nov 2020 10:38:37 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 2882022314 for ; Sat, 28 Nov 2020 10:38:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2882022314 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com 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 B28364D7BE; Sat, 28 Nov 2020 05:38:36 -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 YArPjVPYIxGH; Sat, 28 Nov 2020 05:38:35 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9B7694D7C6; Sat, 28 Nov 2020 05:38:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D16F64F271 for ; Sat, 28 Nov 2020 02:20:08 -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 ztlhMQB+ULmO for ; Sat, 28 Nov 2020 02:20:07 -0500 (EST) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id F2B034F270 for ; Sat, 28 Nov 2020 02:20:05 -0500 (EST) Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4CjjYP0G0Lzhgks; Sat, 28 Nov 2020 15:19:37 +0800 (CST) Received: from [127.0.0.1] (10.57.22.126) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Sat, 28 Nov 2020 15:19:49 +0800 Subject: Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback To: Shenming Lu , Marc Zyngier , "James Morse" , Julien Thierry , Suzuki K Poulose , Eric Auger , , , , , Christoffer Dall References: <20201123065410.1915-1-lushenming@huawei.com> <20201123065410.1915-2-lushenming@huawei.com> From: luojiaxing Message-ID: <869dbc36-c510-fd00-407a-b05e068537c8@huawei.com> Date: Sat, 28 Nov 2020 15:19:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20201123065410.1915-2-lushenming@huawei.com> Content-Language: en-US X-Originating-IP: [10.57.22.126] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Sat, 28 Nov 2020 05:38:32 -0500 Cc: Neo Jia , Cornelia Huck , Kirti Wankhede , Alex Williamson 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. 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. > > 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. Thanks Jiaxing > +} > + > +static int its_irq_get_irqchip_state(struct irq_data *d, > + enum irqchip_irq_state which, bool *val) > +{ > + struct its_device *its_dev = irq_data_get_irq_chip_data(d); > + struct its_vlpi_map *map = get_vlpi_map(d); > + > + if (which != IRQCHIP_STATE_PENDING) > + return -EINVAL; > + > + /* not intended for physical LPI's pending state */ > + if (!map) > + return -EINVAL; > + > + /* > + * In GICv4.1, a VMAPP with {V,Alloc}=={0,1} cleans and invalidates > + * any caching of the VPT associated with the vPEID held in the GIC. > + */ > + if (!is_v4_1(its_dev->its) || atomic_read(&map->vpe->vmapp_count)) > + return -EACCES; > + > + *val = its_peek_vpt(map->vpe, map->vintid); > + > + return 0; > +} > + > static int its_irq_set_irqchip_state(struct irq_data *d, > enum irqchip_irq_state which, > bool state) > @@ -1975,6 +2012,7 @@ static struct irq_chip its_irq_chip = { > .irq_eoi = irq_chip_eoi_parent, > .irq_set_affinity = its_set_affinity, > .irq_compose_msi_msg = its_irq_compose_msi_msg, > + .irq_get_irqchip_state = its_irq_get_irqchip_state, > .irq_set_irqchip_state = its_irq_set_irqchip_state, > .irq_retrigger = its_irq_retrigger, > .irq_set_vcpu_affinity = its_irq_set_vcpu_affinity, _______________________________________________ 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=-15.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 8DDF1C64E7A for ; Sat, 28 Nov 2020 07:22:06 +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 33BA6208CA for ; Sat, 28 Nov 2020 07:22:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fxz4rhWq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33BA6208CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=tAM/JcTLD0VVF4igLum4LdsttVPi0omMecfDlYUHWEQ=; b=fxz4rhWq1qACYCzD9+StD5Iv6 FFnkrMcVwaoA4q9QuJh2hji3kqCpo5W5ZY3a0gpC5HA9sjEfRcYKoO+KJJPOsLCIssP/NKEzDYLZQ IpUZWWxZM/ECJ9fNJlOb9Olv0viudNB/TQ2QcWaot7hbJlL+z08fOoy9Gvbzvt242ff2dxYtRdgXX dkrI2SS6+1rfMPz7DqGzDH6p7rqtHaWgNb6yTel5/zxcckw/3BO6AEoqTUMCXggrfAdC8ISBslvBO 3zoKx+ScVJ4CUKTRJXZJwfxqDtUXMou2lj72zabfeUaKO7gKT4kg3xRyfs1gvicN48Lq+MgmH0diq iYs3fiO1g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kiuWu-00020m-7R; Sat, 28 Nov 2020 07:20:24 +0000 Received: from szxga05-in.huawei.com ([45.249.212.191]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kiuWp-0001zC-7v for linux-arm-kernel@lists.infradead.org; Sat, 28 Nov 2020 07:20:20 +0000 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4CjjYP0G0Lzhgks; Sat, 28 Nov 2020 15:19:37 +0800 (CST) Received: from [127.0.0.1] (10.57.22.126) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Sat, 28 Nov 2020 15:19:49 +0800 Subject: Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback To: Shenming Lu , Marc Zyngier , "James Morse" , Julien Thierry , Suzuki K Poulose , Eric Auger , , , , , Christoffer Dall References: <20201123065410.1915-1-lushenming@huawei.com> <20201123065410.1915-2-lushenming@huawei.com> From: luojiaxing Message-ID: <869dbc36-c510-fd00-407a-b05e068537c8@huawei.com> Date: Sat, 28 Nov 2020 15:19:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20201123065410.1915-2-lushenming@huawei.com> Content-Language: en-US X-Originating-IP: [10.57.22.126] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201128_022019_904994_E743CEE5 X-CRM114-Status: GOOD ( 26.24 ) 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: Neo Jia , Cornelia Huck , Kirti Wankhede , Alex Williamson , yuzenghui@huawei.com, wanghaibin.wang@huawei.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. 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. > > 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. Thanks Jiaxing > +} > + > +static int its_irq_get_irqchip_state(struct irq_data *d, > + enum irqchip_irq_state which, bool *val) > +{ > + struct its_device *its_dev = irq_data_get_irq_chip_data(d); > + struct its_vlpi_map *map = get_vlpi_map(d); > + > + if (which != IRQCHIP_STATE_PENDING) > + return -EINVAL; > + > + /* not intended for physical LPI's pending state */ > + if (!map) > + return -EINVAL; > + > + /* > + * In GICv4.1, a VMAPP with {V,Alloc}=={0,1} cleans and invalidates > + * any caching of the VPT associated with the vPEID held in the GIC. > + */ > + if (!is_v4_1(its_dev->its) || atomic_read(&map->vpe->vmapp_count)) > + return -EACCES; > + > + *val = its_peek_vpt(map->vpe, map->vintid); > + > + return 0; > +} > + > static int its_irq_set_irqchip_state(struct irq_data *d, > enum irqchip_irq_state which, > bool state) > @@ -1975,6 +2012,7 @@ static struct irq_chip its_irq_chip = { > .irq_eoi = irq_chip_eoi_parent, > .irq_set_affinity = its_set_affinity, > .irq_compose_msi_msg = its_irq_compose_msi_msg, > + .irq_get_irqchip_state = its_irq_get_irqchip_state, > .irq_set_irqchip_state = its_irq_set_irqchip_state, > .irq_retrigger = its_irq_retrigger, > .irq_set_vcpu_affinity = its_irq_set_vcpu_affinity, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel