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 60D473D88F2; Wed, 13 May 2026 08:42:41 +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=1778661761; cv=none; b=N2Ij63777qvXLBJjN0VCNLY6zVeAJQez72KQ4PSEmKDQDoj6uaVaUa51rlTkKs5e1YRNOpKTQhC81oyMpBpwy/NLWF7G5oAMjBaoQ0rbXuhIgJSWSnPvf54U9rUQ2PvJPKVmnQQWEhkPqrMt5HfWQdlbTOptmUhjFjXWPjISvzs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778661761; c=relaxed/simple; bh=wFcKZ8r+riP6MbTu1qKedhOQzdDog9eWtDtPnYzMQ3M=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=f23OkHI8J4/OGbFtunfG2XFa9RjZXNjUFgvFP/Ob6imDdWEMdjQAYPz9ADyYwwvmmOIM8UPl7QRwbQwOVc5nwodxDI3uY6oQ3sG6ULsFmmoORCN+Ped1VkoJA4GXkCzi/epVPP0oEag13+9Wnm256SWk49TV2PfjJ7XrRLwXZEg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dL+mOThU; 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="dL+mOThU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84068C2BCB7; Wed, 13 May 2026 08:42:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778661759; bh=wFcKZ8r+riP6MbTu1qKedhOQzdDog9eWtDtPnYzMQ3M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dL+mOThUrXXyro0zysDBR2vEzgp8njYPG1rem/bvEEarfzI4iharQP8kiFEIKGWaO BHC2NCndirUymlaSj6KAce8B5EZxGXgzcfRa+OZ31J5WQ/9sdMZj04KRg8N/0hViDM BiYRDaGtS7PSjr/2AZSYl1pbysNuRImlxZmCLm/iJygUT75bszXrPh40/kbhpG2xVg W/4pZTcI3aTR2oNvh9IMHpKk8dcE9XaDVTHHiiEzHR/szG1HNqvxTIUKl8GRm38PrK vhLQTJINE+wstMdsHbuNTyEGAUSqg+6yLOHCDFGOo/AKESMMycUcs2RijMsMGULODX nIVCQR0pSPbpg== 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 1wN5Ar-00000001tMH-0Xjc; Wed, 13 May 2026 08:42:37 +0000 Date: Wed, 13 May 2026 09:42:36 +0100 Message-ID: <86h5obya2r.wl-maz@kernel.org> From: Marc Zyngier To: Paolo Bonzini Cc: David Woodhouse , Jonathan Corbet , Shuah Khan , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Sean Christopherson , Jim Mattson , Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Raghavendra Rao Ananta , Eric Auger , Kees Cook , Arnd Bergmann , Nathan Chancellor , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org 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> 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, 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, will@kernel.org, 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 Mon, 11 May 2026 17:56:15 +0100, Paolo Bonzini wrote: >=20 > On 5/11/26 18:38, David Woodhouse wrote: > > Not *everything* is in CPUID; one recent exception that comes to mind > > is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the > > existing behaviour of older kernels =E2=80=94 even when that behaviour = doesn't > > make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would > > *advertise* the feature, but not actually *implement* it. Nevertheless, > > that remains the default behaviour of future kernels unless userspace > > explicitly opts in to fully enable (or disable) the feature. > >=20 > > But this documentation update isn't even asking for that compatible-by- > > default behaviour, even though that is the right thing to do. It's only > > asking that it be *possible* to reinstate the old behaviour, for > > userspace that *knows* about the change and explicitly wants to go back > > to the old way to remain compatible. >=20 > Yep, these are the "quirks"---if it's too early for Arm to commit to > that, I guess it's fine. Compatible by default means nothing, because userspace needs to discover the combined capabilities of the host and KVM. This is not a "CPU model" architecture. 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). Yes, this is buggy at times, because the combinatorial explosion of CPU capabilities and supported features makes it pretty hard to test (and really nobody actually does). But overall, it works, and QEMU is growing an infrastructure to manage it in a "user friendly" way. But really, this isn't what David is asking. He's demanding "bug for bug" compatibility. For that, we have two possible cases: - this is a behaviour that, while undesirable, is allowed by the architecture: fine, we preserve the behaviour and add another way to expose the one we really want. it is ugly, but we manage. - this is a behaviour that is not allowed by the architecture: we fix it for good. We do that on every release. Some minor, some much more visible. And there is no way we will add this sort of "bring the bugs back" type of behaviours. Specially when it is really obvious that no SW can make any reasonable use of the defect. We allow userspace to keep behaving as before, but the guest will not see a non-compliant behaviour. That being said, there is a way out of that: convince people in charge of the architecture that the non-compliant KVM behaviour is actually valuable, and deserves to be tolerated. This has happened before (VHE only and NV2 only, just to name two recent changes). Other terrible hacks (such as GICv3's GICD_TYPER.num_LPIs which KVM doesn't support) were added at the request of cloud vendors that David might be familiar with, so it isn't like it is a brand new process. And once it is in the architecture, it becomes a behaviour that is allowed to be exposed to a guest, for better or worse. These are the rules we have followed since we started KVM/arm, and I intend to stick to them. Thanks, M. --=20 Without deviation from the norm, progress is not possible.