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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3266C32772 for ; Tue, 23 Aug 2022 18:42:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231127AbiHWSmv (ORCPT ); Tue, 23 Aug 2022 14:42:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230526AbiHWSmU (ORCPT ); Tue, 23 Aug 2022 14:42:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 042A713D54 for ; Tue, 23 Aug 2022 10:05:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9B6B8B81E97 for ; Tue, 23 Aug 2022 17:05:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55923C433D6; Tue, 23 Aug 2022 17:05:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661274331; bh=0KEk9eyCk+e/7a75LT1gz/v4Sl13Zo22sg/tvZwZqqY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GkpsUu+6a2iXvg5ycINNLtd6zRnVtz3CPSSoGlfRVpWAbNpVAs5/uml7vU06dPcA9 80+YkOESYIc4pc4uKz3xIkQaVksdo1Ced1iI57N4SIMvhvwpqfiq1esxGOxilsYn0W vp4guzNEGARVbyhuTkxKIUM06QjHc4Qf0SMaRNhTB1uIBlReXqexlyzNopb7R31m/7 mowCy6S3ChXQW8JBOILcJ9QKmgbw3jsy1pS67jkzRsO90O38pbWQarmXGbA7IRlNSC j3e3ItPXYsQznq8/QUKbJbqpsGdv9tcqAnQNnjCo2wjPwyFT6gCAMzCRztU3qNpuy6 ZjLr4U/WGtnug== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.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 1oQXLF-005FGX-3g; Tue, 23 Aug 2022 18:05:29 +0100 Date: Tue, 23 Aug 2022 18:05:28 +0100 Message-ID: <87czcqx547.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, will@kernel.org Subject: Re: [PATCH 5/6] KVM: arm64: Treat 32bit ID registers as RAZ/WI on 64bit-only system In-Reply-To: <20220817214818.3243383-6-oliver.upton@linux.dev> References: <20220817214818.3243383-1-oliver.upton@linux.dev> <20220817214818.3243383-6-oliver.upton@linux.dev> 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/27.1 (x86_64-pc-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.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 17 Aug 2022 22:48:17 +0100, Oliver Upton wrote: > > One of the oddities of the architecture is that the AArch64 views of the > AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any EL. > Nonetheless, KVM exposes these registers to userspace for the sake of > save/restore. It is possible that the UNKNOWN value could differ between > systems, leading to a rejected write from userspace. > > Avoid the issue altogether by handling the AArch32 ID registers as > RAZ/WI when on an AArch64-only system. > > Signed-off-by: Oliver Upton > --- > arch/arm64/kvm/sys_regs.c | 63 ++++++++++++++++++++++++++------------- > 1 file changed, 43 insertions(+), 20 deletions(-) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 9f06c85f26b8..5f6a633182c8 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1145,6 +1145,20 @@ static unsigned int id_visibility(const struct kvm_vcpu *vcpu, > return 0; > } > > +static unsigned int aa32_id_visibility(const struct kvm_vcpu *vcpu, > + const struct sys_reg_desc *r) > +{ > + /* > + * AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any > + * EL. Promote to RAZ/WI in order to guarantee consistency between > + * systems. > + */ > + if (!kvm_supports_32bit_el0()) > + return REG_RAZ | REG_USER_WI; This is probably only a nit, but why does one visibility has a _USER_ tag while the other doesn't? In other word, what sysregs are WI from userspace that aren't so from the guest? Also, do we have any cases where RAZ and WI would be used independently? My gut feeling is that RAZ implies WI in most (all?) cases. If this assumption holds, shouldn't we simply rename REG_RAZ to REG_RAZ_WI and be done with it? Thanks, M. -- Without deviation from the norm, progress is not possible.