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.2 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 935F0C433DB for ; Fri, 8 Jan 2021 18:14:33 +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 310A32388A for ; Fri, 8 Jan 2021 18:14:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 310A32388A 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=N+zShGJ7xrqhdDZd97LCF7F8BFH6es4uDwcIqnO/hUk=; b=MAgZtf7zj7ubcjLn7rLyMwG5z HcyU6LgFVZYmI5LIqRyDt9W13R0+CjHvAlifT67tKhjVDZ08WGKkCeTUKi7S4GUYE0+YmHiXrDGZL l4yLzJM1nMo63soNOkmYsfCZWzLbSZVob4UYsmXA2KuYR5zMqCaOPSZW2lYBkPJ++vCxPzpDC/y6N G4vDqDUO55N8g/KAV/Jsvl6EXulqET02Bw+maWFPRb39WHCz/Hwau8YRh2Uq7iMQ/gl1WtU+fIciB 8U7eIbOm/6uHhGyXLMy7ur4um0lF+uJOLA20zC0Z5E688wMx/LScugKQi/2VFpqjCoAY+EBPXzIch zMahdZqlg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxwG0-0003fH-6I; Fri, 08 Jan 2021 18:13:04 +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 1kxwFx-0003ev-Sr for linux-arm-kernel@lists.infradead.org; Fri, 08 Jan 2021 18:13:02 +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 930E823A69; Fri, 8 Jan 2021 18:13:00 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kxwFu-0068SH-9D; Fri, 08 Jan 2021 18:12:58 +0000 MIME-Version: 1.0 Date: Fri, 08 Jan 2021 18:12:58 +0000 From: Marc Zyngier To: Ard Biesheuvel Subject: Re: [PATCH 2/2] KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3 compatibility In-Reply-To: References: <20210108171216.2310188-1-maz@kernel.org> <20210108171216.2310188-3-maz@kernel.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <72a1bea27a29d35413c193f81b7ba170@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: ardb@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, shameerali.kolothum.thodi@huawei.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kernel-team@android.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-20210108_131302_090515_D444A2CC X-CRM114-Status: GOOD ( 22.27 ) 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: Suzuki K Poulose , Shameerali Kolothum Thodi , James Morse , Linux ARM , Android Kernel Team , kvmarm , Julien Thierry 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 On 2021-01-08 17:59, Ard Biesheuvel wrote: > On Fri, 8 Jan 2021 at 18:12, Marc Zyngier wrote: >> >> It looks like we have broken firmware out there that wrongly >> advertises >> a GICv2 compatibility interface, despite the CPUs not being able to >> deal >> with it. >> >> To work around this, check that the CPU initialising KVM is actually >> able >> to switch to MMIO instead of system registers, and use that as a >> precondition to enable GICv2 compatibility in KVM. >> >> Note that the detection happens on a single CPU. If the firmware is >> lying *and* that the CPUs are asymetric, all hope is lost anyway. >> >> Reported-by: Shameerali Kolothum Thodi >> >> Signed-off-by: Marc Zyngier >> --- >> arch/arm64/kvm/hyp/vgic-v3-sr.c | 34 >> +++++++++++++++++++++++++++++++-- >> arch/arm64/kvm/vgic/vgic-v3.c | 8 ++++++-- >> 2 files changed, 38 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c >> b/arch/arm64/kvm/hyp/vgic-v3-sr.c >> index 005daa0c9dd7..d504499ab917 100644 >> --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c >> +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c >> @@ -408,11 +408,41 @@ void __vgic_v3_init_lrs(void) >> /* >> * Return the GIC CPU configuration: >> * - [31:0] ICH_VTR_EL2 >> - * - [63:32] RES0 >> + * - [62:32] RES0 >> + * - [63] MMIO (GICv2) capable >> */ >> u64 __vgic_v3_get_gic_config(void) >> { >> - return read_gicreg(ICH_VTR_EL2); >> + u64 sre = read_gicreg(ICC_SRE_EL1); >> + unsigned long flags = 0; >> + bool v2_capable; >> + >> + /* >> + * To check whether we have a MMIO-based (GICv2 compatible) >> + * CPU interface, we need to disable the system register >> + * view. To do that safely, we have to prevent any interrupt >> + * from firing (which would be deadly). >> + * >> + * Note that this only makes sense on VHE, as interrupts are >> + * already masked for nVHE as part of the exception entry to >> + * EL2. >> + */ >> + if (has_vhe()) >> + flags = local_daif_save(); >> + >> + write_gicreg(0, ICC_SRE_EL1); >> + isb(); >> + >> + v2_capable = !(read_gicreg(ICC_SRE_EL1) & ICC_SRE_EL1_SRE); >> + >> + write_gicreg(sre, ICC_SRE_EL1); >> + isb(); >> + >> + if (has_vhe()) >> + local_daif_restore(flags); >> + >> + return (read_gicreg(ICH_VTR_EL2) | >> + v2_capable ? (1ULL << 63) : 0); >> } >> > > Is it necessary to perform this check unconditionally? We only care > about this if the firmware claims v2 compat support. Indeed. But this is done exactly once per boot, and I see it as a way to extract the CPU configuration more than anything else. Extracting it *only* when we have some v2 compat info would mean sharing that information with EL2 (in the nVHE case), and it felt more hassle than it is worth. Do you foresee any issue with this, other than the whole thing being disgusting (which I wilfully admit)? Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel