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 lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) (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 00A5CCC6B38 for ; Fri, 16 Oct 2026 09:38:08 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1xHeO2-0006Zl-5u; Fri, 16 Oct 2026 05:38:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xHeO0-0006ZY-PB for qemu-arm@nongnu.org; Fri, 16 Oct 2026 05:38:00 -0400 Received: from tor.source.kernel.org ([172.105.4.254]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xHeNy-0006fW-Pu for qemu-arm@nongnu.org; Fri, 16 Oct 2026 05:38:00 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id B9E9D602C5; Fri, 16 Oct 2026 09:37:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 709311F000C4; Fri, 16 Oct 2026 09:37:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792143469; bh=W3NO0pJ/XcFPdXScblby7SDbvNRveDq8sYiOuPvPASU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=D2OChEEuB/8XOJNsUGNssDuFwg00B7kZOWyhI4ZY7rh9X0unK5dAMTuFZHImX/hch /4Yp5Z2euhk7BXffr1Ka/MUVv45aC9P6nR9pSDZX7T7nYk+g/o0ZYpolkPir4YReu1 miMeJN4ZUpdd+bm8hh97+A/Pp3v25GVdhXMIer7PkQY4HST+Jl1sT8FgNiExmzSNvE r3gdvyi3YGIHSjkzrJ8hdyIiK2iJDi9KDpdCGoO5tKXGs/zi+aCHse57LOx/2FLsKu jtxf1zjAHF13/zmTWHYVVtUcSdENBznzhEjB66uGPda1KpbfGzCJiat5ALkpN2+UAl z7hfjvL8EYMKA== 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.98.2) (envelope-from ) id 1xHeNn-00000003gIc-03gC; Fri, 16 Oct 2026 09:37:47 +0000 Date: Fri, 16 Oct 2026 10:37:46 +0100 Message-ID: <86fqy60yvp.wl-maz@kernel.org> From: Marc Zyngier To: Khushit Shah Cc: "kvmarm@lists.linux.dev" , "oupton@kernel.org" , "eric.auger@redhat.com" , "cohuck@redhat.com" , "peter.maydell@linaro.org" , "qemu-arm@nongnu.org" , Mark Cave-Ayland , Shaju Abraham , Shameer Kolothum , Sandesh Patel Subject: Re: [RFC] Exposing arm64 ID-register safe_rules semantics to userspace? In-Reply-To: <27B87634-9720-438E-8153-1918E6515230@nutanix.com> References: <86se6xthih.wl-maz@kernel.org> <86pl21t99k.wl-maz@kernel.org> <27B87634-9720-438E-8153-1918E6515230@nutanix.com> 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/30.1 (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: khushit.shah@nutanix.com, kvmarm@lists.linux.dev, oupton@kernel.org, eric.auger@redhat.com, cohuck@redhat.com, peter.maydell@linaro.org, qemu-arm@nongnu.org, mark.caveayland@nutanix.com, shaju.abraham@nutanix.com, skolothumtho@nvidia.com, sandesh.patel@nutanix.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Received-SPF: pass client-ip=172.105.4.254; envelope-from=maz@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -22 X-Spam_score: -2.3 X-Spam_bar: -- X-Spam_report: (-2.3 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.24, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-arm@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-arm-bounces+qemu-arm=archiver.kernel.org@nongnu.org Sender: qemu-arm-bounces+qemu-arm=archiver.kernel.org@nongnu.org On Fri, 16 Oct 2026 10:07:37 +0100, Khushit Shah wrote: > > I take your point that a named model cannot be a faithful Neoverse V2 > (or any other) TRM view: even on V2 hardware, a KVM guest only gets > the subset that the architecture and KVM can actually virtualise. We > are not trying to present a TRM-accurate Neoverse V2 to the guest. > > What we are after is a migration ABI: a fixed guest-visible ID register > contract that stays identical across all hosts capable of running it. That ABI exists. It is probably buggy as hell, but it is there at least in principles. > In my research so far, I have identified the following pitfalls with > this approach: > > - Guest errata: errata handling in the guest is driven by MIDR/REVIDR, > so if those do not match the real host, the guest can pick the wrong > workarounds or skip needed ones. > > Shameer's errata-management work, where the VMM gives the guest the > list of target implementations could address this. > > - PMU: events and counters are core-specific, so they cannot be > supported reliably across heterogeneous hosts. > > We currently leave PMU out of named models for that reason. This is a deal breaker IMO. Most interesting events are *architected*, and SW that relies on non-architectural events has bigger problems anyway (i.e. it is never able to migrate correctly). Removing PMU support from named models on these grounds is yet another nail on that coffin. The "better" thing to do is to list the events you want to support and use the event filter to reject anything else. > - IMP-DEF registers: ACTLR_EL1, AMAIR_EL1 and AFSR0/1_EL1 are the > trickiest in principle. A named model should only be allowed to boot > on hosts where these registers have the same semantics as on the > implementation the model's MIDR describes. > > Would it make sense for KVM to make them RAZ/WI instead? AFAIU, they > are rarely used by guests; mainline Linux does not touch them at all. ACTLR_EL1 is treated as WI already, but will report the value the physical CPU has. We don't know if it is safe to have anything else. It may have been yet another early misdesign to do so, but we can't change this behaviour now. Trapping the other registers to make them RAZ/WI requires trapping all VM related registers on CPUs that do not have FEAT_FGT (see the registers trapped by HCR_EL2.TVM to get an idea). The cost of that is simply not acceptable. And to be clear: an implementation that associates non-architectural behaviours to these registers is not virtualisable, and will break under migration. There is nothing that SW can do about it, because the hardware is fundamentally misdesigned when it comes to virtualisation. But we're pretty far from named models anyway. M. -- Without deviation from the norm, progress is not possible.