From: Like Xu <like.xu.linux@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] KVM: x86/pmu: Fix emulation on Intel counters' bit width
Date: Tue, 28 Mar 2023 18:04:45 +0800 [thread overview]
Message-ID: <7e84bfb4-b052-4c31-a319-1ea2dd52ae54@gmail.com> (raw)
In-Reply-To: <fce5c1ad-24a3-febf-127e-e97238492143@redhat.com>
On 28/3/2023 5:20 pm, Paolo Bonzini wrote:
> On 3/28/23 11:16, Like Xu wrote:
>>
>>
>> If IA32_PERF_CAPABILITIES.FW_WRITE[bit 13] =1, each IA32_PMCi is accompanied by a
>> corresponding alias address starting at 4C1H for IA32_A_PMC0.
>>
>> The bit width of the performance monitoring counters is specified in
>> CPUID.0AH:EAX[23:16].
>> If IA32_A_PMCi is present, the 64-bit input value (EDX:EAX) of WRMSR to
>> IA32_A_PMCi will cause
>> IA32_PMCi to be updated by:
>>
>> COUNTERWIDTH =
>> CPUID.0AH:EAX[23:16] bit width of the performance monitoring counter
>> IA32_PMCi[COUNTERWIDTH-1:32] := EDX[COUNTERWIDTH-33:0]);
>> IA32_PMCi[31:0] := EAX[31:0];
>> EDX[63:COUNTERWIDTH] are reserved
>>
>> ---
>>
>> Some might argue that this is all talking about GP counters, not
>> fixed counters. In fact, the full-width write hw behaviour is
>> presumed to do the same thing for all counters.
> But the above behavior, and the #GP, is only true for IA32_A_PMCi (the
> full-witdh MSR). Did I understand correctly that the behavior for fixed
> counters is changed without introducing an alias MSR?
>
> Paolo
>
If true, why introducing those alias MSRs ? My archaeological findings are:
a platform w/o full-witdh like Westmere (has 3-fixed counters already) is
declared to
have a counter width (R:48, W:32) and its successor Sandy Bridge has (R:48 , W:
32/48).
Thus I think the behaviour of the fixed counter has changed from there, and the
alias GP MSRs
were introduced to keep the support on 32-bit writes on #GP counters (via
original address).
[*] Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation
Changes
(252046-030, January 2011) Table 30-18 Core PMU Comparison.
next prev parent reply other threads:[~2023-03-28 10:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-22 9:31 [PATCH v2] KVM: x86/pmu: Fix emulation on Intel counters' bit width Like Xu
2023-03-27 14:30 ` Paolo Bonzini
2023-03-28 9:16 ` Like Xu
2023-03-28 9:20 ` Paolo Bonzini
2023-03-28 10:04 ` Like Xu [this message]
2023-05-24 20:33 ` Sean Christopherson
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=7e84bfb4-b052-4c31-a319-1ea2dd52ae54@gmail.com \
--to=like.xu.linux@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--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