From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C23C4DB561; Tue, 19 May 2026 12:39:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779194341; cv=none; b=UJ8gvdJ48czquhCbo2/KtoT+xOkIJfWz3wt54muhlmYG9+/N7W2uKp23GrsvYypIPnNBTQL7JNG3TmwVK34x2xbuI0NyZ8dLnHn3BVXzbwWUR9HETQpabJdciQItz80Ii/GlwSLYTqtkFENOwixSJWwwy0k59Lq4ZoOZyyvf+ms= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779194341; c=relaxed/simple; bh=8vDTP3D8eciTBIALrAZgpZD5nbooGrzE+oayZi9KF0E=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=W5x13tKsdR0QqBD4iXRtKWjlu1JMDaUiiAdlGxl8OPA6I2WAtrdLhBSz3FVab0Hs1y8ekea1nJzdgBFY107MpUNwqCJm1OW+Yv/3d7JBudvpe0QhV24MZLGIW7Xh8Lm0dcdPGL5N15crSWTapvKkTm7FAYq9vxpAEsmz3H7tA3c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X6t7ol7k; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X6t7ol7k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1AF6C2BCB3; Tue, 19 May 2026 12:39:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779194340; bh=8vDTP3D8eciTBIALrAZgpZD5nbooGrzE+oayZi9KF0E=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=X6t7ol7k8hXaTj/jPvLJ4LNh/i0SOJnXHIXk5IZvumO7d/mN1CRjiMLm+KSTcCp01 dpCgfb3aWuWfFvphoRRIUvocz42q1e+gPLCMrk98HK48+ExirdBV2p39MdspXradvs 1S8OGLvyb2+JpsVe931jV07V3TurIWCZCvnNvmG/z9BrJiOSkahYsYOo1ZSNsKo2ra Y+gehhYjrv12Lm3yC01nrnbTOX6dWDkJ5zl5bn1iOKENlNlOCBFUr/hY7y5DGNyIh8 j8dzCXa37aHLiHFr20/F7wIrW3FgI33uniFpprTdhEdwfVSdoMKI7k1UkTm0mh1dmW 8eH0eWogRBXPQ== 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 1wPJis-00000003wup-1KJo; Tue, 19 May 2026 12:38:58 +0000 Date: Tue, 19 May 2026 13:38:57 +0100 Message-ID: <86qzn7wp3y.wl-maz@kernel.org> From: Marc Zyngier To: Paolo Bonzini Cc: David Woodhouse , Will Deacon , Jonathan Corbet , Shuah Khan , kvm , Linux Doc Mailing List , "Kernel Mailing List, Linux" , Sean Christopherson , Jim Mattson , Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Raghavendra Rao Ananta , Eric Auger , Kees Cook , Arnd Bergmann , Nathan Chancellor , linux-arm-kernel , kvmarm@lists.linux.dev, linux-kselftest Subject: Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations In-Reply-To: References: <6856b269d2af706eae397e0cf9c1231f89d9a932.camel@infradead.org> <6afc4b95-3c15-4d71-877d-19b84e91ce05@redhat.com> <57bc082f4824d6114d3156744c25986effc29aca.camel@infradead.org> <86h5obya2r.wl-maz@kernel.org> <48b06e5655d56ff6eda30e563b34894fa0eb2f07.camel@infradead.org> <3f9d731c3d26b0367600f1069e6425099bc34eac.camel@infradead.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: pbonzini@redhat.com, dwmw2@infradead.org, will@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, seanjc@google.com, jmattson@google.com, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, rananta@google.com, eric.auger@redhat.com, kees@kernel.org, arnd@arndb.de, nathan@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 19 May 2026 13:13:41 +0100, Paolo Bonzini wrote: >=20 > On Tue, May 19, 2026 at 1:44=E2=80=AFPM David Woodhouse wrote: > > > > So... what next? Is one of the other KVM/arm64 maintainers going to > > > > speak up? Paolo would you consider taking the fixes through your tr= ee > > > > directly? >=20 > I admit that my knowledge of Arm is really limited, and I do not > understand which IIDR values have architecturally allowed behaviors > and which (if any) were made up by KVM; but even if I cannot honestly > remark on the code or even the approach, a compatibility knob is the > right thing to have. That's a userspace API design matter, not an Arm > or GIC matter. I agree that we can have the knob -- not having it is a userspace issue, and I have said that I was OK with preserving the userspace interface. >=20 > I hope that Marc provides a better explanation of why he believes > https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/ > shouldn't be accepted, because I am more than a bit puzzled about > *why* that patch is being rejected or (in v3) so far ignored. Marc in > this thread wrote: "If userspace is not a total joke, it will read all > the ID registers, and configure what it wants to see, assuming it is a > feature that can be configured (not everything can, because the > architecture itself is not fully backward compatible)". This was a more general comment on the full mechanism that we use to save/restore the state and at the same time configure the feature set. Which is what the GICD_IIDR does to some extent for the GIC. > But in this case there's an ID register that tells KVM if userspace > wants the old or the new behavior, independent of whether that old > behavior is architecturally valid or not. But the "old behaviour" makes no sense, and cannot be used by a guest: - either the guest doesn't use the alternative interrupt groups, then it wasn't affected by the bug. That's 100% of the guests. - or the guest did try to use the alternative groups, and it *NEVER* worked, as it wouldn't get any interrupt at all. What is the point of preserving a "feature" that only results in a non-working guest? Given that, re-introducing a behaviour that cannot be used makes zero sense to me. > I will certainly take this patch, but I won't override Marc. However > I'd like to better understand his point of view, because right now I > just don't get it. I don't get it either, but for different reasons. >=20 > > If KVM on arm64 doesn't aspire to maintain guest compatibility across > > host kernel changes =E2=80=94 regardless of whether the previous kernel= 's > > behaviour was "blessed" by the architecture specification or not =E2=80= =94 then > > it does not meet the expectation that we have of KVM implementations in > > the Linux kernel. >=20 > I agree with the "aspire" wording. Even if it's not going to be 100% > achievable, KVM *needs* to aspire to maintain both guest compatibility > and architecture precision. Sometimes it's impossible, sometimes there > are constraints that require you to trade off one for another (e.g. > via quirks, or by breaking behavior that no sane guest would have > cared about). But in general as a maintainer you don't *get* to > choose. >=20 > Paolo >=20 > > Or indeed the standards that we've held for Linux kernel ABIs for the > > last 35 years. As I said before, I'd be OK with something that would restore IIDR to REV1. But not something that actively breaks the GIC emulation by reintroducing a bug. That's, by construction, dead code that will only bitrot, because there is no SW that can make use of this nonsense. M. --=20 Without deviation from the norm, progress is not possible.