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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 15962C5320E for ; Wed, 21 Aug 2024 11:12:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Dsso20vB8maHhHScgA8bl/xDHd8piLp9863Yt4qw2dQ=; b=QfPvQIx/RsBYjWcV168xlvdHV1 Z1ZoJSJk27mH6ZHX7yN/7dAz5vpeSiLPsGUrUnFCUWUE/r9DONJ89Z0VPap4pd2zP70CMWuXHh9U3 feRuPLBotRWu9Qvivf/qcmttvJM0j2OW0YDTwF6q1Y3TJtwCtGDgyT44w8LyQlub9jVdrLseqm0IM KPdjxu4QPAHdTqfobK307h/6TpLc6r3Lp9MB+Iqi3b0QXxUvLKwT2LT120/ZJs3xqs1osYWKSyqha WvHk3QOG5537l+Q/TFoYmuPfVk2DTPn9oP3iiyhGprO45LJvZyXI6tCvbZ9Ilw8e2AsaxxM4yFSuK 6ITO55cw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgjFu-00000008c1n-1iNN; Wed, 21 Aug 2024 11:11:58 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgj9p-00000008Zh9-2fAF for linux-arm-kernel@lists.infradead.org; Wed, 21 Aug 2024 11:05:43 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 48CF9A410EE; Wed, 21 Aug 2024 11:05:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BA4BC32782; Wed, 21 Aug 2024 11:05:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724238340; bh=lMBMESst7bCQ8jyHOpfcD43sVWhjcjmCuJ+vIN49mNI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Gi54C1GRfwslotpV/SidoL40SWzfZTuaW1N7B2/2+SPUBfuuAgcKqH2Gaaz82ffNp DVj3zMcAskSSoMQ+HWZH17Fy33kTl1EaK+zrHiaK4fDeOuKo4JnLNr7n7ltQBkqB3g pe+JSfJBqustD1e5ovNUML4Hn2P/wtov7hg1eSp+5I5sfLr5ptyeVIzt55dj6/NLUQ YZPVZAicQQvEH6TUTycx+CcLAHSVkVSfQ/O/dwY62S6xROA5njmRnlePCbQPtPdhZO JM1dHNbtLA5pQ2TcQd7FD30nw3KV/e+YLYRFen4Rch+SBuKU+Fn8gi8o2jZhB8Rj47 fNf1Zj0jKUf1A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1sgj9m-005YQT-7q; Wed, 21 Aug 2024 12:05:38 +0100 Date: Wed, 21 Aug 2024 12:05:37 +0100 Message-ID: <86jzgaxhj2.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Zenghui Yu , Alexander Potapenko Subject: Re: [PATCH 03/12] KVM: arm64: Force SRE traps when SRE access is not enabled In-Reply-To: References: <20240820100349.3544850-1-maz@kernel.org> <20240820100349.3544850-4-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, glider@google.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-20240821_040541_821665_7050F7EA X-CRM114-Status: GOOD ( 46.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 21 Aug 2024 00:19:32 +0100, Oliver Upton wrote: > > Hey, > > On Tue, Aug 20, 2024 at 11:03:40AM +0100, Marc Zyngier wrote: > > We so far only write the ICH_HCR_EL2 config in two situations: > > > > - when we need to emulate the GICv3 CPU interface due to HW bugs > > > > - when we do direct injection, as the virtual CPU interface needs > > to be enabled > > > > This is all good. But it also means that we don't do anything special > > when we emulate a GICv2, or that there is no GIC at all. > > > > What happens in this case when the guest uses the GICv3 system > > registers? The *guest* gets a trap for a sysreg access (EC=0x18) > > while we'd really like it to get an UNDEF. > > > > Fixing this is a bit involved: > > > > - we need to set all the required trap bits (TC, TALL0, TALL1, TDIR) > > > > - for these traps to take effect, we need to (counter-intuitively) > > set ICC_SRE_EL1.SRE to 1 so that the above traps take priority. > > > > Note that doesn't fully work when GICv2 emulation is enabled, as > > we cannot set ICC_SRE_EL1.SRE to 1 (it breaks Group0 delivery as > > IRQ). > > Just to make sure I'm following completely, GICv2-on-GICv3 guest sees > the (barf) architected behavior of sysreg traps going to EL1. Indeed. There isn't anything we can do about that, short of changing the behaviour of GICv2 emulation. I'll add something to that effect in the commit message. > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/hyp/vgic-v3-sr.c | 22 ++++++++++++++++------ > > arch/arm64/kvm/vgic/vgic-v3.c | 5 ++++- > > 2 files changed, 20 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c > > index 7b397fad26f2..a184def8f5ad 100644 > > --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c > > +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c > > @@ -268,8 +268,16 @@ void __vgic_v3_activate_traps(struct vgic_v3_cpu_if *cpu_if) > > * starting to mess with the rest of the GIC, and VMCR_EL2 in > > * particular. This logic must be called before > > * __vgic_v3_restore_state(). > > + * > > + * However, if the vgic is disabled (ICH_HCR_EL2.EN==0), no GIC is > > + * provisionned at all. In order to prevent illegal accesses to the > > typo: provisioned > > > + * system registers to trap to EL1 (duh), force ICC_SRE_EL1.SRE to 1 > > + * so that the trap bits can take effect. Yes, we *loves* the GIC. > > */ > > - if (!cpu_if->vgic_sre) { > > + if (!(cpu_if->vgic_hcr & ICH_HCR_EN)) { > > + write_gicreg(ICC_SRE_EL1_SRE, ICC_SRE_EL1); > > + isb(); > > + } else if (!cpu_if->vgic_sre) { > > write_gicreg(0, ICC_SRE_EL1); > > isb(); > > write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2); > > @@ -288,8 +296,9 @@ void __vgic_v3_activate_traps(struct vgic_v3_cpu_if *cpu_if) > > } > > > > /* > > - * Prevent the guest from touching the GIC system registers if > > - * SRE isn't enabled for GICv3 emulation. > > + * Prevent the guest from touching the ICC_SRE_EL1 system > > + * register. Note that this may not have any effect, as > > + * ICC_SRE_EL2.Enable being RAO/WI is a valid implementation. > > So this behavior is weird but still 'safe' as, ICC_SRE_EL1.SRE is also RAO/WI > and the HCR traps are still effective. Right? Exactly. All the traps are working, *except* for ICC_SRE_EL1 itself. A guest can then infer that it runs under a hypervisor, but not much more. > > > */ > > write_gicreg(read_gicreg(ICC_SRE_EL2) & ~ICC_SRE_EL2_ENABLE, > > ICC_SRE_EL2); > > @@ -297,10 +306,11 @@ void __vgic_v3_activate_traps(struct vgic_v3_cpu_if *cpu_if) > > /* > > * If we need to trap system registers, we must write > > * ICH_HCR_EL2 anyway, even if no interrupts are being > > - * injected, > > + * injected. Note that this also applies if we don't expect > > + * any system register access (GICv2 or no vgic at all). > > We don't expect the traps to come in the GICv2 case, though, right? Yup. I'll fix the comment, as it is misleading. > Looks alright to me otherwise, but blech! Yeah. It's the sort of code that makes you feel dirty just looking at it. Thanks, M. -- Without deviation from the norm, progress is not possible.