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 DB582C02194 for ; Fri, 7 Feb 2025 19:46:37 +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=8fiYJOBuDsPAv4YjLBaRLOwTbINfg99vX0rBYmLWDOI=; b=cGGpvfHbYt6lRKQFi7rcplLu8f ow+EGsOIHVYDHb3myk9T2jEFihz7OPmh1owAP87SeBHNTi47CA8p4i3LIprq0nGkxLgTma0JKIT9d a+eYeyYvpKLw1tu3+oTtmxQ70LEgwcYR4mRyqgbTw4vTUpAXqr5g1wXpv264+Ay9QBQ2PWOGUJc1S ioPv6agIw6IqEchQJLXnwJeqMxPymc/hbNyWz/IwYfC1HrMmZ+HLts/vjLYJSFT0SCU4/sLUULBcd Zh2xkE7TMWtsbRnku8Ap46ZJWrg5CPGJoiNz+adzU5ytnMduGMKRM5BEBorrUXgXK/rPoxhvWkJRD mqlH0YTA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tgUJ4-0000000Axrr-0bm5; Fri, 07 Feb 2025 19:46:30 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tgTFE-0000000AjrI-0Gd4 for linux-arm-kernel@lists.infradead.org; Fri, 07 Feb 2025 18:38:29 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C70815C6E54; Fri, 7 Feb 2025 18:37:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F752C4CED1; Fri, 7 Feb 2025 18:38:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738953507; bh=IuEkWS/NeyEzfm3i6D8opFH8M053JN7Jz2y2irFVkzY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OA0YeZM/gCesGVQMq5OSI7dzXDnAk0M3rovFjYOuyL/hyjFGyvG50ZwhJsp38P/Uy zVGXs+cQ+a06nyAnNYBXHNuVY4S3AU3GSCwuPr2Ma1TMGpnX3dL1PjJtOIRBP16piH ZzA9SPl4Xdcz0r6T57miigab7WugY8M48s3IQcdnVIwjw+m0Hb6kGhI0XTqgoHtWRf oKaEydO7zmMO1beJUrVO8+X/6xoHGh8zPBv07EK5PhPwzsJT8YDHeMpj8/X2uj3VXJ 5x3LCFef46qEXYCX0wSUJyJUnU3q/q3UDv/w7xvCfVNYsJ34cnY+ms1tQ9mK9xv9Rb G6zfL1m58aELQ== 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 1tgTFA-001kXx-3e; Fri, 07 Feb 2025 18:38:24 +0000 Date: Fri, 07 Feb 2025 18:38:22 +0000 Message-ID: <86bjvdtxb5.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Eric Auger , Ganapatrao Kulkarni , kvmarm , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, christoffer.dall@arm.com, suzuki.poulose@arm.com, will@kernel.org, catalin.marinas@arm.com, coltonlewis@google.com, joey.gouly@arm.com, yuzenghui@huawei.com, darren@os.amperecomputing.com, vishnu@os.amperecomputing.com Subject: Re: [PATCH] KVM: arm64: nv: Set ISTATUS for emulated timers, If timer expired In-Reply-To: References: <86y10osr19.wl-maz@kernel.org> <4d443db1-85b1-4071-acd5-3187deb9cb17@redhat.com> <2f6b2cb1-3d32-480a-9801-9b993ae74e2d@os.amperecomputing.com> <152d262e-641d-4bb1-9656-a13e049d62c4@redhat.com> <86h661wje4.wl-maz@kernel.org> <4a9fbdd9-ad23-44bc-8ba5-399f08068db4@redhat.com> <86cygpwfy0.wl-maz@kernel.org> <86frkptzr6.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: oliver.upton@linux.dev, eauger@redhat.com, gankulkarni@os.amperecomputing.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, christoffer.dall@arm.com, suzuki.poulose@arm.com, will@kernel.org, catalin.marinas@arm.com, coltonlewis@google.com, joey.gouly@arm.com, yuzenghui@huawei.com, darren@os.amperecomputing.com, vishnu@os.amperecomputing.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-20250207_103828_237851_6BE0B97D X-CRM114-Status: GOOD ( 26.38 ) 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 Fri, 07 Feb 2025 18:09:58 +0000, Oliver Upton wrote: > > Hey, > > On Fri, Feb 07, 2025 at 05:45:33PM +0000, Marc Zyngier wrote: > > I found at least one issue that could fail the migration. Before the > > VM starts running, we limit the feature set to the subset we actually > > support with NV. > > > > By doing this, we also change the value of IDreg fields that are not > > writable, because they describe features that we don't support. > > Obviously, that fails on restore. > > > > I need to have a think... > > We spoke about this a while ago (and I forgot til now), but I was > wondering if we could use vCPU feature flags to describe NV, including > the selection between FEAT_E2H0 and FEAT_VHE. > > I think this might match userspace expectations a bit more closely where > the state of the ID registers after init gives the actual feature set > supported by the VM. I'm not sure that's enough. Let me give you an example: My host has FEAT_XNX, described in ID_AA64MMFR1_EL1.XNX. For whatever reason, we don't allow this field to be written to, even out of NV context. This is odd, because for an EL1 VM, this field means nothing at all. However, we don't yet support FEAT_XNX with NV (it requires some extra surgery in the S2 walker, in the S2 shadowing code and in AT). How would you manage this field if you had a vcpu flag saying E2H0 or not? I don't think it helps, at least not in that particular case. It may help for some things, but not all. It feels that we need to define the field limit (and what is writable or not) based on the NV/!NV support, and maybe E2H0/VHE as well. This is getting complicated... M. -- Without deviation from the norm, progress is not possible.