Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4313376ybv; Tue, 25 Feb 2020 17:37:02 -0800 (PST) X-Google-Smtp-Source: APXvYqw7NKUVAyI9rzXjEyBn17O+G9wAWEeTEThWMo2UBVo0RxVdKxdzXGrFtpHoZvz9x4FeSLbK X-Received: by 2002:a05:6830:1615:: with SMTP id g21mr1196468otr.49.1582681022453; Tue, 25 Feb 2020 17:37:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582681022; cv=none; d=google.com; s=arc-20160816; b=WgTYLxjrgmTGnMmIxivjpA/D1nZX84n1jQGFU+77EzkYxYJMnPEaPPhSuak+3bJoin X82u1pHcNNWqrjKtJOGOaxfpl2IVYqNmVRG+1PPtDh1Xlxy3IHnWjL1QWi0nnebplmUE QZzjYf68qoqydfSWY2gVu6zgF5jj4Gk+p3zdkeSGQk/2pYlfaUUWendGAujeGHNcoSou q/KRNoPhhLsg0/zFzFR9QjsHQTq4bqeHT9DyuVM1SLDh2qvF2o8OAF46Fhk/tmX2jfGR vlV1vAD71LxmW89onRlNHqbVcSsNRbwqtuuVjN7ouvIplQIxVC3nfDXbSyn2vOP1LsuH y6mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=+Q28Vcc4BHD9nNhxItMn7sDKFdyJmETtH8N/sRSS4QM=; b=K04Fj+rYhryO97faY7H9rMpThQovf/9o8NguHZ92mtgPFn9Q/AODNYqT3Yf4k1+poE q0Py7buC9yEHiTDkIDgwj3uURbOIyT4j3xcXg+F0/Blc8qUH92CZYBHqmLjvZ+sF266I jJLd6RMxgCYvBysrGQ87XFvgoMiO3zf+nLPs6mZzd4lghh3Wbhvorx/Jwgp3jJSrPldY jPYL2HBjqGqkzjNYd7f+S6s1YZW5a31bRkO7hK/D4C+rtbQgUxFFJq9Yb+w3AEpWoLpi z2cwI53DXIPGWhGnE726/7t9JzUDEm148y+abccr6mrykeTT3Nf65p5gmbOH4SbXrCAe 1g+Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l5si350335otf.37.2020.02.25.17.36.49; Tue, 25 Feb 2020 17:37:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729653AbgBZBfj (ORCPT + 99 others); Tue, 25 Feb 2020 20:35:39 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:43918 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729346AbgBZBfj (ORCPT ); Tue, 25 Feb 2020 20:35:39 -0500 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 9BD9497D363A8F050052; Wed, 26 Feb 2020 09:35:37 +0800 (CST) Received: from [127.0.0.1] (10.173.222.27) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.439.0; Wed, 26 Feb 2020 09:35:28 +0800 Subject: Re: [PATCH] irqchip/gic-v3-its: Clear Valid before writing any bits else in VPENDBASER To: Marc Zyngier CC: , , , , Yanlei Jia References: <20200224025029.92-1-yuzenghui@huawei.com> <6ce5c751-6d17-b9ee-4054-edad7de075bf@huawei.com> From: Zenghui Yu Message-ID: <22aa4f88-6a32-1204-e428-de1ffc52b600@huawei.com> Date: Wed, 26 Feb 2020 09:35:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.173.222.27] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/2/26 3:45, Marc Zyngier wrote: > Hi Zenghui, > > On 2020-02-25 02:06, Zenghui Yu wrote: >> Hi Marc, >> >> On 2020/2/25 7:47, Marc Zyngier wrote: >>> Hi Zenghui, >>> >>> On 2020-02-24 02:50, Zenghui Yu wrote: >>>> The Valid bit must be cleared before changing anything else when >>>> writing >>>> GICR_VPENDBASER to avoid the UNPREDICTABLE behavior. This is exactly >>>> what >>>> we've done on 32bit arm, but not on arm64. >>> >>> I'm not quite sure how you decide that Valid must be cleared before >>> changing >>> anything else. The reason why we do it on 32bit is that we cannot update >>> the full 64bit register at once, so we start by clearing Valid so that >>> we can update the rest. arm64 doesn't require that. >> >> The problem came out from discussions with our GIC engineers and what we >> talked about at that time was IHI 0069E 9.11.36 - the description of the >> Valid field: >> >> "Writing a new value to any bit of GICR_VPENDBASER, other than >> GICR_VPENDBASER.Valid, when GICR_VPENDBASER.Valid==1 is UNPREDICTABLE." >> >> It looks like we should first clear the Valid and then write something >> else. We might have some mis-understanding about this statement.. > > So that's the v4.0 version of VPENDBASER. On v4.0, you start by clearing > Valid, not changing any other bit. Subsequent polling of the leads to > the PendingLast bit once Dirty clears. The current code follows this > principle. > >>> For the rest of discussion, let's ignore GICv4.1 32bit support (I'm >>> pretty sure nobody cares about that). >>> >>>> This works fine on GICv4 where we only clear Valid for a vPE >>>> deschedule. >>>> With the introduction of GICv4.1, we might also need to talk >>>> something else >>>> (e.g., PendingLast, Doorbell) to the redistributor when clearing the >>>> Valid. >>>> Let's port the 32bit gicr_write_vpendbaser() to arm64 so that >>>> hardware can >>>> do the right thing after descheduling the vPE. >>> >>> The spec says that: >>> >>> "For a write that writes GICR_VPENDBASER.Valid from 1 to 0, if >>> GICR_VPENDBASER.PendingLast is written as 1 then >>> GICR_VPENDBASER.PendingLast >>> takes an UNKNOWN value and GICR_VPENDBASER.Doorbell is treated as >>> being 0." >>> >>> and >>> >>> "When GICR_VPENDBASER.Valid is written from 1 to 0, if there are >>> outstanding >>> enabled pending interrupts GICR_VPENDBASER.Doorbell is treated as 0." >>> >>> which indicate that PendingLast/Doorbell have to be written at the >>> same time >>> as we clear Valid. >> >> Yes. I obviously missed these two points when writing this patch. >> >>> Can you point me to the bit of the v4.1 spec that makes >>> this "clear Valid before doing anything else" requirement explicit? >> >> No, nothing in v4.1 spec supports me :-(  The above has been forwarded >> to Hisilicon and I will confirm these with them. It would be easy for >> hardware to handle the PendingLast/DB when clearing Valid, I think. > > v4.1 changes the way VPENDBASER works in a number of way. Clearing Valid > allows > a "handshake": At the point of making the vPE non-resident, to specify the > expected behaviour of the redistributor once the residency has been > completed. > This includes requesting the doorbell or telling the GIC that we don't > care to > know about PendingLast. > > This is effectively a relaxation of the v4.0 behaviour. I believe the > current > state of the driver matches both specs (not using common code though). Yes, I agree with all of the above. Thanks for your confirmation and please ignore this patch. Thanks, Zenghui