[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZC9mtqxmqKAoelNO@google.com>
Date: Thu, 6 Apr 2023 17:41:26 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Like Xu <like.xu.linux@...il.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 10/12] KVM: x86/cpuid: Add X86_FEATURE_PERFMON_V2 as a
scattered flag
This shortlog is flat out wrong. This patch does not add X86_FEATURE_PERFMON_V2,
it adds a KVM-only leaf to redirect X86_FEATURE_PERFMON_V2 to its architectural
location when KVM queries the leaf, e.g. via guest_cpuid_has().
On Tue, Feb 14, 2023, Like Xu wrote:
> From: Like Xu <likexu@...cent.com>
>
> Considering that the core kernel may also want to know this flag, to avoid
Please write changelogs so that they do not depend on the shortlog for context.
I know the tip maintainers in particular like to make the changelog a continuation
of the shortlog, but I find it really annoying, especially when reviewing in mutt,
e.g. as I'm typing this, I don't even have the shortlog visible.
In the vast majority of cases, being more explicit rarely adds more than a few
chars, e.g. you'll save more by reducing the fluff in this changelog.
> confusion this needs to be a scattered flag rather than a pure KVM flag so
> that KVM can redirect it to the hardware-defined bit position, which is the
> role of __feature_translate() and KVM_X86_FEATURE_PERFMON_V2.
Like the shortlog, the changelog is best misleading, X86_FEATURE_PERFMON_V2 is
already a scattered flag.
Define a KVM-only leaf for AMD's PerfMonV2 feature flag to redirect the
kernel's scattered version to its architectural location, e.g. so that
KVM can query guest support via guest_cpuid_has().
Powered by blists - more mailing lists