linux-kernel - Re: [PATCH v4 3/3] KVM: selftests: Test behavior of KVM_X86_DISABLE_EXITS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALMp9eSS09bzdUs2JPnaQKM6ALWjxJNqWTsNYM5LOnSJjyRanQ@mail.gmail.com>
Date: Tue, 10 Jun 2025 09:59:04 -0700
From: Jim Mattson <jmattson@...gle.com>
To: "Mi, Dapeng" <dapeng1.mi@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, 
	Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v4 3/3] KVM: selftests: Test behavior of KVM_X86_DISABLE_EXITS_APERFMPERF

On Tue, Jun 10, 2025 at 1:42 AM Mi, Dapeng <dapeng1.mi@...ux.intel.com> wrote:
>
>
> On 5/31/2025 2:52 AM, Jim Mattson wrote:
> > For a VCPU thread pinned to a single LPU, verify that interleaved host
> > and guest reads of IA32_[AM]PERF return strictly increasing values when
> > APERFMPERF exiting is disabled.

> Should we consider the possible overflow case of these 2 MSRs although it
> could be extremely rare? Thanks.

Unless someone moves the MSRs forward, at current frequencies, the
machine will have to be up for more than 100 years. I'll be long dead
by then.

Note that frequency invariant scheduling doesn't accommodate overflow
either. If the MSRs overflow, frequency invariant scheduling is
disabled.