From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <seanjc@google.com>,
Jim Mattson <jmattson@google.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Provide a capability to disable APERF/MPERF read intercepts
Date: Fri, 14 Mar 2025 16:07:01 +0100 [thread overview]
Message-ID: <2fd1f956-3c6c-4d96-ad16-7c8a6803120c@redhat.com> (raw)
In-Reply-To: <Z9Q2Tl50AjxpwAKG@google.com>
On 3/14/25 14:59, Sean Christopherson wrote:
> On Thu, Mar 13, 2025, Jim Mattson wrote:
>> On Mon, Feb 24, 2025 at 4:47 PM Jim Mattson <jmattson@google.com> wrote:
>>>
>>> Allow a guest to read the physical IA32_APERF and IA32_MPERF MSRs
>>> without interception.
>>>
>>> The IA32_APERF and IA32_MPERF MSRs are not virtualized. Writes are not
>>> handled at all. The MSR values are not zeroed on vCPU creation, saved
>>> on suspend, or restored on resume. No accommodation is made for
>>> processor migration or for sharing a logical processor with other
>>> tasks. No adjustments are made for non-unit TSC multipliers. The MSRs
>>> do not account for time the same way as the comparable PMU events,
>>> whether the PMU is virtualized by the traditional emulation method or
>>> the new mediated pass-through approach.
>>>
>>> Nonetheless, in a properly constrained environment, this capability
>>> can be combined with a guest CPUID table that advertises support for
>>> CPUID.6:ECX.APERFMPERF[bit 0] to induce a Linux guest to report the
>>> effective physical CPU frequency in /proc/cpuinfo. Moreover, there is
>>> no performance cost for this capability.
>>>
>>> Signed-off-by: Jim Mattson <jmattson@google.com>
>>> ---
>
> ...
>
>> Any thoughts?
>
> It's absolutely absurd, but I like it. I would much rather provide functionality
> that is flawed in obvious ways, as opposed to functionality that is flawed in
> subtle and hard-to-grok ways. Especially when the former is orders of magnitude
> less complex.
>
> I have no objections, so long as we add very explicit disclaimers in the docs.
>
> FWIW, the only reason my response was delayed is because I was trying to figure
> out if there's a clean way to avoid adding a large number of a capabilities for
> things like this.
True but it's not even a capability, it's just a new bit in the existing
KVM_CAP_X86_DISABLE_EXITS.
Just one question:
> - u64 r = KVM_X86_DISABLE_EXITS_PAUSE;
> + u64 r = KVM_X86_DISABLE_EXITS_PAUSE | KVM_X86_DISABLE_EXITS_APERFMPERF;
Should it be conditional on the host having the APERFMPERF feature
itself? As is the patch _does_ do something sensible, i.e. #GP, but
this puts the burden on userspace of checking the host CPUID and
figuring out whether it makes sense to expose the feature to the guest.
It would be simpler for userspace to be able to say "if the bit is there
then enable it and make it visible through CPUID".
Paolo
next prev parent reply other threads:[~2025-03-14 15:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-25 0:45 Jim Mattson
2025-03-13 20:40 ` Jim Mattson
2025-03-14 13:59 ` Sean Christopherson
2025-03-14 15:07 ` Paolo Bonzini [this message]
2025-03-14 15:33 ` Jim Mattson
2025-03-14 15:34 ` Paolo Bonzini
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=2fd1f956-3c6c-4d96-ad16-7c8a6803120c@redhat.com \
--to=pbonzini@redhat.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seanjc@google.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
all inboxes | Powered by JetHome®