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=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 32305C3F68F for ; Fri, 20 Dec 2019 13:07:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 07302218AC for ; Fri, 20 Dec 2019 13:07:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576847235; bh=hSDUwdKW3yrFJVWxez/KM8OwO5W5CJyt4daJ1sfRKLI=; h=To:Subject:Date:From:Cc:In-Reply-To:References:List-ID:From; b=YUyzzujypkXta1jxJkQxpp00chuGW+yk1+e3IlzdSlfdkA12lXtudVyqyyRSKO9Mn GYSJbg5pWJIyJhhzhNZJZlx7cuVDEUpjFLyaRjsB/TCBQv34iXDf6kGQohku95vsLx YLVAq3JdYYhuPOxe0/KipzKNHJKttDy55L03qhCs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727411AbfLTNHN (ORCPT ); Fri, 20 Dec 2019 08:07:13 -0500 Received: from inca-roads.misterjones.org ([213.251.177.50]:45704 "EHLO inca-roads.misterjones.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727344AbfLTNHN (ORCPT ); Fri, 20 Dec 2019 08:07:13 -0500 Received: from www-data by cheepnis.misterjones.org with local (Exim 4.80) (envelope-from ) id 1iiHzl-0005uV-GW; Fri, 20 Dec 2019 14:07:05 +0100 To: Zenghui Yu Subject: Re: [PATCH] KVM: arm/arm64: vgic: Handle =?UTF-8?Q?GICR=5FPENDBAS?= =?UTF-8?Q?ER=2EPTZ=20filed=20as=20RAZ?= X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 20 Dec 2019 13:07:05 +0000 From: Marc Zyngier Cc: , , , , , In-Reply-To: <20191220111833.1422-1-yuzenghui@huawei.com> References: <20191220111833.1422-1-yuzenghui@huawei.com> Message-ID: <71e3dcc00ad5ab8dffd732bfe7381705@www.loen.fr> X-Sender: maz@kernel.org User-Agent: Roundcube Webmail/0.7.2 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: yuzenghui@huawei.com, andre.przywara@arm.com, eric.auger@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, wanghaibin.wang@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on cheepnis.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-12-20 11:18, Zenghui Yu wrote: > Although guest will hardly read and use the PTZ (Pending Table Zero) > bit in GICR_PENDBASER, let us emulate the architecture strictly. > As per IHI 0069E 9.11.30, PTZ field is WO, and reads as 0. > > Signed-off-by: Zenghui Yu > --- > > Noticed when checking all fields of GICR_PENDBASER register. > But _not_ sure whether it's worth a fix, as Linux never sets > the PTZ bit before enabling LPI (set GICR_CTLR_ENABLE_LPIS). > > And I wonder under which scenarios can this bit be written as 1. > It seems difficult for software to determine whether the pending > table contains all zeros when writing this bit. This is a useless HW optimization, where it can avoid reading the pending table the very first time you write to this register if it is told that it is all zero. A decent ITS implementation already has a mechanism to find out about the pending bits by looking into the IMPDEF area (the first 1kB) of the pending table. PTZ is just yet another way to do the same thing. This can only happen once in the lifetime of the system (when allocating the table), and Linux doesn't really care. As usual, the GIC is setting the level of useless complexity pretty high... > > virt/kvm/arm/vgic/vgic-mmio-v3.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c > b/virt/kvm/arm/vgic/vgic-mmio-v3.c > index 7dfd15dbb308..ebc218840fc2 100644 > --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c > +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c > @@ -414,8 +414,11 @@ static unsigned long > vgic_mmio_read_pendbase(struct kvm_vcpu *vcpu, > gpa_t addr, unsigned int len) > { > struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu; > + u64 value = vgic_cpu->pendbaser; > > - return extract_bytes(vgic_cpu->pendbaser, addr & 7, len); > + value &= ~GICR_PENDBASER_PTZ; > + > + return extract_bytes(value, addr & 7, len); > } > > static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu, Otherwise looks good. I'll queue it with Eric's correction to the subject line. Thanks, M. -- Jazz is not dead. It just smells funny...