From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladimir Murzin Subject: Re: [PATCH v2 7/7] ARM: KVM: Unlock vgic-v3 support Date: Wed, 7 Sep 2016 11:48:52 +0100 Message-ID: <57CFF094.5000704@arm.com> References: <1471344418-19568-1-git-send-email-vladimir.murzin@arm.com> <1471344418-19568-8-git-send-email-vladimir.murzin@arm.com> <20160905112927.GL26366@cbox> <57CEC344.7030706@arm.com> <20160906165527.GG23592@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 38A9449B47 for ; Wed, 7 Sep 2016 06:40:33 -0400 (EDT) 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 hE-W0695ri2O for ; Wed, 7 Sep 2016 06:40:28 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D2A1F49B40 for ; Wed, 7 Sep 2016 06:40:28 -0400 (EDT) In-Reply-To: <20160906165527.GG23592@cbox> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Christoffer Dall Cc: marc.zyngier@arm.com, andre.przywara@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org List-Id: kvmarm@lists.cs.columbia.edu On 06/09/16 17:55, Christoffer Dall wrote: > On Tue, Sep 06, 2016 at 02:23:16PM +0100, Vladimir Murzin wrote: >> >> Sorry, missed this one >> >> On 05/09/16 12:29, Christoffer Dall wrote: >>>> >>>>> +static bool __hyp_text __has_useable_gicv3_cpuif(void) >>>>> +{ >>>>> + if (IS_ENABLED(CONFIG_ARM_GIC_V3) && (read_sysreg(ID_PFR1) >> 28)) >>> Do we have a define for bit 28 we could use? >> >> I'll check it. >> >>> >>> Does this actually work on all v7 boards? The v7 ARM ARM seems to state >>> that this bitfield is Reserved, UNK. Does that somehow mean 'is going >>> to be zero'? >> >> It is how v7ARM ARM I have defines UNK >> >> An abbreviation indicating that software must treat a field as >> containing an UNKNOWN value. Hardware must implement the bit as read as >> 0, or all 0s for a bit field. Software must not rely on the field >> reading as zero. >> >> It seems goes under 'is going to be zero' case, no? >> > The last sentence is disturbing to me, and feels slightly contradicting > itself. Reading the UNKNOWN description doesn't help much either. > > Perhaps you can ask around internally and figure out what the precise > answer to this is? Since it is kind of implementation dependant thing the precise answer from here hardly help, IMO. We still have non-zero chance to see something scary. OTOH, why do we care of all v7 boards if none of them have CONFIG_ARM_GIC_V3 defined? Cheers Vladimir > > Thanks, > -Christoffer > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: vladimir.murzin@arm.com (Vladimir Murzin) Date: Wed, 7 Sep 2016 11:48:52 +0100 Subject: [PATCH v2 7/7] ARM: KVM: Unlock vgic-v3 support In-Reply-To: <20160906165527.GG23592@cbox> References: <1471344418-19568-1-git-send-email-vladimir.murzin@arm.com> <1471344418-19568-8-git-send-email-vladimir.murzin@arm.com> <20160905112927.GL26366@cbox> <57CEC344.7030706@arm.com> <20160906165527.GG23592@cbox> Message-ID: <57CFF094.5000704@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/09/16 17:55, Christoffer Dall wrote: > On Tue, Sep 06, 2016 at 02:23:16PM +0100, Vladimir Murzin wrote: >> >> Sorry, missed this one >> >> On 05/09/16 12:29, Christoffer Dall wrote: >>>> >>>>> +static bool __hyp_text __has_useable_gicv3_cpuif(void) >>>>> +{ >>>>> + if (IS_ENABLED(CONFIG_ARM_GIC_V3) && (read_sysreg(ID_PFR1) >> 28)) >>> Do we have a define for bit 28 we could use? >> >> I'll check it. >> >>> >>> Does this actually work on all v7 boards? The v7 ARM ARM seems to state >>> that this bitfield is Reserved, UNK. Does that somehow mean 'is going >>> to be zero'? >> >> It is how v7ARM ARM I have defines UNK >> >> An abbreviation indicating that software must treat a field as >> containing an UNKNOWN value. Hardware must implement the bit as read as >> 0, or all 0s for a bit field. Software must not rely on the field >> reading as zero. >> >> It seems goes under 'is going to be zero' case, no? >> > The last sentence is disturbing to me, and feels slightly contradicting > itself. Reading the UNKNOWN description doesn't help much either. > > Perhaps you can ask around internally and figure out what the precise > answer to this is? Since it is kind of implementation dependant thing the precise answer from here hardly help, IMO. We still have non-zero chance to see something scary. OTOH, why do we care of all v7 boards if none of them have CONFIG_ARM_GIC_V3 defined? Cheers Vladimir > > Thanks, > -Christoffer > >