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 0D7ACD2A520 for ; Wed, 16 Oct 2024 14:45:56 +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=XVzpMeBv+WnYnKp6gqm5/7cphQTRPN/PH3q1rgq3cig=; b=lL5JLL3k3wj9bCnwhSZnRaVMID AHsgGByugkL5sdIfI7JvIBy5vfrnyK0LjGKr5Ra3mWmOIs6gB+d0at2GZp2Zs6PmTr68gYr558WXh zdjiRhDySw8yKSEmUDxhpQ8/nlgSg4H04nQU0xXEFt6hFizlcUumf+zBNSVkKyY+D7aNpIw3VQif7 BkX85tKMnYXCwg6F34WP31JThytFJx/d8tnJ7EaQSetkIhqelWFe65lot4W5iQNE+Mct6oT60wyug 6HrCr+xuaeF9VDVTG5ybRwTBkeO+5Mkdyjyv+4DZr//+Dd+LyG1kbdkhJvF0Or/leUP7sJc8u/fl9 5+zyYi5g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t15HV-0000000C800-3i6a; Wed, 16 Oct 2024 14:45:45 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t14HQ-0000000BxZl-3Be3 for linux-arm-kernel@lists.infradead.org; Wed, 16 Oct 2024 13:41:38 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B851D5C5F7C; Wed, 16 Oct 2024 13:41:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CFE09C4CEC5; Wed, 16 Oct 2024 13:41:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729086095; bh=tmglpRF6ockTWwBT1N80CsCLOq6CQEoYvcNiTLS5Vrc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OVFfD8PTrs+KPUz1TPjkkG41G8USdYp01IruRF/M/oBB0xCdeP6HX1gK5helfob1T ft4DHyJfkR1rmP3cVc5ENjt1YuwKSwqAlJgpfyPxLcFWC3LvsGCieZuYBxtr0TZitJ l3dgNZWSQxPonXrQ+qJJopq+yOeioBNS/01RhhUXDbuC00mBfiRFN3L/hT0kXHIKiY ngNOoIe9v7VOyOl+gueGpVzyowxH+PRrn8tJdq1QZdyAZuBaK9zZiGAQICPSZUB3l2 FJwSABVE6o8G/uyd6LQ2qp0pYFsfxTUagtTDZRQw5P4qzCT3+jnottDW/BlnGlY4uX ApLh4AlY83A7w== 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 1t14HN-0046Ou-IS; Wed, 16 Oct 2024 14:41:33 +0100 Date: Wed, 16 Oct 2024 14:41:33 +0100 Message-ID: <86zfn4412q.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Mark Brown Subject: Re: [PATCH v4 06/36] KVM: arm64: nv: Handle CNTHCTL_EL2 specially In-Reply-To: References: <20241009190019.3222687-1-maz@kernel.org> <20241009190019.3222687-7-maz@kernel.org> <861q0g5ls1.wl-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: alexandru.elisei@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, broonie@kernel.org 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-20241016_064136_944009_A48E7AA2 X-CRM114-Status: GOOD ( 34.94 ) 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, 16 Oct 2024 14:19:14 +0100, Alexandru Elisei wrote: > > > > > @@ -207,6 +222,19 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg) > > > > */ > > > > __vcpu_sys_reg(vcpu, reg) = val; > > > > > > > > + switch (reg) { > > > > + case CNTHCTL_EL2: > > > > + /* > > > > + * If E2H=0, CNHTCTL_EL2 is a pure shadow register. > > > > + * Otherwise, some of the bits are backed by > > > > + * CNTKCTL_EL1, while the rest is kept in memory. > > > > + * Yes, this is fun stuff. > > > > + */ > > > > + if (vcpu_el2_e2h_is_set(vcpu)) > > > > + write_sysreg_el1(val, SYS_CNTKCTL); > > > > > > Sorry, but I just can't seem to get my head around why the RES0 bits aren't > > > cleared. Is KVM relying on the guest to implement Should-Be-Zero-or-Preserved, > > > as per the RES0 definition? > > > > KVM isn't relying on anything. And it isn't about the RES0 bits not > > being cleared. It is about the HW not providing storage for some of > > the CNTHCTL_EL2 bits when the guest is using CNTKCTL_EL1 as a proxy > > for its own view of CNTHCTL_EL2. > > > > Namely, bits outside of CNTKCTL_VALID_BITS are not guaranteed to be > > stored until (IIRC) FEAT_NV2p1, which retrospectively fixes the > > architecture by mandating that the relevant bits have dedicated > > storage. > > The definition for RES0 says: > > 'A bit that is RES0 in a context is reserved for possible future use in that > context. To preserve forward compatibility, software: > * Must not rely on the bit reading as 0. > * Must use an SBZP policy to write to the bit.' > > where Should-Be-Zero-of-Preserved (SBZP): > > 'When writing this field, software must either write all 0s to this field or, if > the register is being restored from a previously read state, write the > previously read value to this field. If this is not done, then the result is > unpredictable.' And? I can quote the ARM ARM too, but that's not going to lead us anywhere if you don't explain why what you quote is related to the problem at hand (hint, I don't think it is). > And what about the rest of the RES0 bits from CNTKCTL_EL1, those that are RES0 > in both registers? What about them *what*? It would definitely help if you didn't write in riddles and actually spell out what you mean. If you think this code is wrong, please explain why you think it is wrong, and maybe we'll be able to make some progress. Thanks, M. -- Without deviation from the norm, progress is not possible.