From: Paolo Bonzini <pbonzini@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Sean Christopherson <seanjc@google.com>,
Jim Mattson <jmattson@google.com>, Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Raghavendra Rao Ananta <rananta@google.com>,
Eric Auger <eric.auger@redhat.com>, Kees Cook <kees@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Nathan Chancellor <nathan@kernel.org>,
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
Date: Mon, 11 May 2026 18:56:15 +0200 [thread overview]
Message-ID: <baff82ca-6321-4b16-aa61-b2d6d60b6535@redhat.com> (raw)
In-Reply-To: <57bc082f4824d6114d3156744c25986effc29aca.camel@infradead.org>
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 — 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.
>
> 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.
Yep, these are the "quirks"---if it's too early for Arm to commit to
that, I guess it's fine.
However, independent of this patch which I (obviously) believe is a good
idea, I'd like to understand how far it is, assuming 1) no quirks 2)
same CPU host.
By the way, you didn't Cc Marc...
Paolo
next prev parent reply other threads:[~2026-05-11 16:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 8:57 [PATCH] Documentation: KVM: Document guest-visible compatibility expectations David Woodhouse
2026-05-11 15:14 ` Paolo Bonzini
2026-05-11 16:38 ` David Woodhouse
2026-05-11 16:56 ` Paolo Bonzini [this message]
2026-05-11 17:53 ` David Woodhouse
2026-05-13 8:42 ` Marc Zyngier
2026-05-13 9:24 ` David Woodhouse
2026-05-13 12:43 ` Paolo Bonzini
2026-05-13 13:03 ` Eric Auger
2026-05-13 13:57 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=baff82ca-6321-4b16-aa61-b2d6d60b6535@redhat.com \
--to=pbonzini@redhat.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dwmw2@infradead.org \
--cc=eric.auger@redhat.com \
--cc=jmattson@google.com \
--cc=joey.gouly@arm.com \
--cc=kees@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=maz@kernel.org \
--cc=nathan@kernel.org \
--cc=oupton@kernel.org \
--cc=rananta@google.com \
--cc=seanjc@google.com \
--cc=skhan@linuxfoundation.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox