* [PATCH] arch/x86/events/amd/core.c: Return -ENODEV when CPU does not have PERFCTL_CORE bit
@ 2022-10-27 13:35 Liang Yan
2022-10-31 12:59 ` Peter Zijlstra
0 siblings, 1 reply; 6+ messages in thread
From: Liang Yan @ 2022-10-27 13:35 UTC (permalink / raw)
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Thomas Gleixner, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, linux-perf-users, linux-kernel
After disabling cpu.perfctr_core in qemu, I noticed that the guest kernel
still loads the pmu driver while the cpuid does not have perfctl_core.
The test is running on an EPYC Rome machine.
root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# lscpu | grep perfctl
root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~#
root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
[ 0.732097] Performance Events: AMD PMU driver.
By further looking,
==> init_hw_perf_events
==> amd_pmu_init
==> amd_core_pmu_init
==>
if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
return 0;
With returning 0, it will bypass amd_pmu_init and return 0 to
init_hw_perf_events, and continue the initialization.
I am not a perf expert and not sure if it is expected for AMD PMU,
otherwise, it would be nice to return -ENODEV instead.
New output after the change:
root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
[ 0.531609] Performance Events: no PMU driver, software events only.
Signed-off-by: Liang Yan <lyan@digtalocean.com>
---
arch/x86/events/amd/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index 8b70237c33f7..34d3d2944020 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -1335,7 +1335,7 @@ static int __init amd_core_pmu_init(void)
int i;
if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
- return 0;
+ return -ENODEV;
/* Avoid calculating the value each time in the NMI handler */
perf_nmi_window = msecs_to_jiffies(100);
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] arch/x86/events/amd/core.c: Return -ENODEV when CPU does not have PERFCTL_CORE bit
2022-10-27 13:35 [PATCH] arch/x86/events/amd/core.c: Return -ENODEV when CPU does not have PERFCTL_CORE bit Liang Yan
@ 2022-10-31 12:59 ` Peter Zijlstra
2022-10-31 14:28 ` Sandipan Das
0 siblings, 1 reply; 6+ messages in thread
From: Peter Zijlstra @ 2022-10-31 12:59 UTC (permalink / raw)
To: Liang Yan, Ravi Bangoria
Cc: Ingo Molnar, Arnaldo Carvalho de Melo, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, Thomas Gleixner,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
linux-perf-users, linux-kernel
On Thu, Oct 27, 2022 at 09:35:11AM -0400, Liang Yan wrote:
> After disabling cpu.perfctr_core in qemu, I noticed that the guest kernel
> still loads the pmu driver while the cpuid does not have perfctl_core.
>
> The test is running on an EPYC Rome machine.
> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# lscpu | grep perfctl
> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~#
> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
> [ 0.732097] Performance Events: AMD PMU driver.
>
> By further looking,
>
> ==> init_hw_perf_events
> ==> amd_pmu_init
> ==> amd_core_pmu_init
> ==>
> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
> return 0;
>
> With returning 0, it will bypass amd_pmu_init and return 0 to
> init_hw_perf_events, and continue the initialization.
>
> I am not a perf expert and not sure if it is expected for AMD PMU,
> otherwise, it would be nice to return -ENODEV instead.
>
> New output after the change:
> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
> [ 0.531609] Performance Events: no PMU driver, software events only.
>
> Signed-off-by: Liang Yan <lyan@digtalocean.com>
Looks about right, Ravi?
> ---
> arch/x86/events/amd/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
> index 8b70237c33f7..34d3d2944020 100644
> --- a/arch/x86/events/amd/core.c
> +++ b/arch/x86/events/amd/core.c
> @@ -1335,7 +1335,7 @@ static int __init amd_core_pmu_init(void)
> int i;
>
> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
> - return 0;
> + return -ENODEV;
>
> /* Avoid calculating the value each time in the NMI handler */
> perf_nmi_window = msecs_to_jiffies(100);
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arch/x86/events/amd/core.c: Return -ENODEV when CPU does not have PERFCTL_CORE bit
2022-10-31 12:59 ` Peter Zijlstra
@ 2022-10-31 14:28 ` Sandipan Das
2022-11-12 22:33 ` Liang Yan
0 siblings, 1 reply; 6+ messages in thread
From: Sandipan Das @ 2022-10-31 14:28 UTC (permalink / raw)
To: Peter Zijlstra, Liang Yan
Cc: Ingo Molnar, Arnaldo Carvalho de Melo, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, Thomas Gleixner,
Borislav Petkov, Dave Hansen, Ravi Bangoria, x86, H. Peter Anvin,
linux-perf-users, linux-kernel
Hi Liang, Peter,
On 10/31/2022 6:29 PM, Peter Zijlstra wrote:
> On Thu, Oct 27, 2022 at 09:35:11AM -0400, Liang Yan wrote:
>> After disabling cpu.perfctr_core in qemu, I noticed that the guest kernel
>> still loads the pmu driver while the cpuid does not have perfctl_core.
>>
>> The test is running on an EPYC Rome machine.
>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# lscpu | grep perfctl
>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~#
>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
>> [ 0.732097] Performance Events: AMD PMU driver.
>>
>> By further looking,
>>
>> ==> init_hw_perf_events
>> ==> amd_pmu_init
>> ==> amd_core_pmu_init
>> ==>
>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>> return 0;
>>
>> With returning 0, it will bypass amd_pmu_init and return 0 to
>> init_hw_perf_events, and continue the initialization.
>>
>> I am not a perf expert and not sure if it is expected for AMD PMU,
>> otherwise, it would be nice to return -ENODEV instead.
>>
>> New output after the change:
>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
>> [ 0.531609] Performance Events: no PMU driver, software events only.
>>
>> Signed-off-by: Liang Yan <lyan@digtalocean.com>
>
> Looks about right, Ravi?
>
>> ---
>> arch/x86/events/amd/core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
>> index 8b70237c33f7..34d3d2944020 100644
>> --- a/arch/x86/events/amd/core.c
>> +++ b/arch/x86/events/amd/core.c
>> @@ -1335,7 +1335,7 @@ static int __init amd_core_pmu_init(void)
>> int i;
>>
>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>> - return 0;
>> + return -ENODEV;
>>
There are four legacy counters that are always available even when PERFCTR_CORE
is absent. This is why the code returns 0 here. I found this to be a bit confusing
as well during PerfMonV2 development so I wrote the following patch but forgot to
send it out.
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index 262e39a85031..d3eb7b2f4dda 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -1345,6 +1345,14 @@ static int __init amd_core_pmu_init(void)
u64 even_ctr_mask = 0ULL;
int i;
+ /*
+ * All processors support four PMCs even when X86_FEATURE_PERFCTR_CORE
+ * is unavailable. They are programmable via the PERF_LEGACY_CTLx and
+ * PERF_LEGACY_CTRx registers which have the same address as that of
+ * MSR_K7_EVNTSELx and MSR_K7_PERFCTRx. For Family 17h+, these are
+ * legacy aliases of PERF_CTLx and PERF_CTRx respectively. Hence, not
+ * returning -ENODEV here.
+ */
if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
return 0;
If this looks good to you, I will post it.
- Sandipan
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] arch/x86/events/amd/core.c: Return -ENODEV when CPU does not have PERFCTL_CORE bit
2022-10-31 14:28 ` Sandipan Das
@ 2022-11-12 22:33 ` Liang Yan
2022-11-14 10:52 ` Sandipan Das
0 siblings, 1 reply; 6+ messages in thread
From: Liang Yan @ 2022-11-12 22:33 UTC (permalink / raw)
To: Sandipan Das, Peter Zijlstra
Cc: Ingo Molnar, Arnaldo Carvalho de Melo, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, Thomas Gleixner,
Borislav Petkov, Dave Hansen, Ravi Bangoria, x86, H. Peter Anvin,
linux-perf-users, linux-kernel
On 10/31/22 10:28, Sandipan Das wrote:
> Hi Liang, Peter,
>
> On 10/31/2022 6:29 PM, Peter Zijlstra wrote:
>> On Thu, Oct 27, 2022 at 09:35:11AM -0400, Liang Yan wrote:
>>> After disabling cpu.perfctr_core in qemu, I noticed that the guest kernel
>>> still loads the pmu driver while the cpuid does not have perfctl_core.
>>>
>>> The test is running on an EPYC Rome machine.
>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# lscpu | grep perfctl
>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~#
>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
>>> [ 0.732097] Performance Events: AMD PMU driver.
>>>
>>> By further looking,
>>>
>>> ==> init_hw_perf_events
>>> ==> amd_pmu_init
>>> ==> amd_core_pmu_init
>>> ==>
>>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>>> return 0;
>>>
>>> With returning 0, it will bypass amd_pmu_init and return 0 to
>>> init_hw_perf_events, and continue the initialization.
>>>
>>> I am not a perf expert and not sure if it is expected for AMD PMU,
>>> otherwise, it would be nice to return -ENODEV instead.
>>>
>>> New output after the change:
>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
>>> [ 0.531609] Performance Events: no PMU driver, software events only.
>>>
>>> Signed-off-by: Liang Yan <lyan@digtalocean.com>
>> Looks about right, Ravi?
>>
>>> ---
>>> arch/x86/events/amd/core.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
>>> index 8b70237c33f7..34d3d2944020 100644
>>> --- a/arch/x86/events/amd/core.c
>>> +++ b/arch/x86/events/amd/core.c
>>> @@ -1335,7 +1335,7 @@ static int __init amd_core_pmu_init(void)
>>> int i;
>>>
>>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>>> - return 0;
>>> + return -ENODEV;
>>>
> There are four legacy counters that are always available even when PERFCTR_CORE
> is absent. This is why the code returns 0 here. I found this to be a bit confusing
> as well during PerfMonV2 development so I wrote the following patch but forgot to
> send it out.
Hi Sandipan,
Thanks for the classification.
Do these legacy counters belong to the AMD PMU property from a VM
perspective? I mean, if I want to disable PMU for an AMD vcpu for some
reason, is it possible to disable perfctr_core and the four counters, or
is this not logical since the four counters could not be disabled from
the bare-metal level?
I asked because I saw 'pmu' could be disabled for Intel and ARM, but it
seems not for AMD.
Also, could you please list the four legacy counters here?
Thanks,
Liang
> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
> index 262e39a85031..d3eb7b2f4dda 100644
> --- a/arch/x86/events/amd/core.c
> +++ b/arch/x86/events/amd/core.c
> @@ -1345,6 +1345,14 @@ static int __init amd_core_pmu_init(void)
> u64 even_ctr_mask = 0ULL;
> int i;
>
> + /*
> + * All processors support four PMCs even when X86_FEATURE_PERFCTR_CORE
> + * is unavailable. They are programmable via the PERF_LEGACY_CTLx and
> + * PERF_LEGACY_CTRx registers which have the same address as that of
> + * MSR_K7_EVNTSELx and MSR_K7_PERFCTRx. For Family 17h+, these are
> + * legacy aliases of PERF_CTLx and PERF_CTRx respectively. Hence, not
> + * returning -ENODEV here.
> + */
> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
> return 0;
>
>
> If this looks good to you, I will post it.
>
> - Sandipan
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arch/x86/events/amd/core.c: Return -ENODEV when CPU does not have PERFCTL_CORE bit
2022-11-12 22:33 ` Liang Yan
@ 2022-11-14 10:52 ` Sandipan Das
2022-11-23 5:41 ` Sandipan Das
0 siblings, 1 reply; 6+ messages in thread
From: Sandipan Das @ 2022-11-14 10:52 UTC (permalink / raw)
To: Liang Yan
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Thomas Gleixner, Borislav Petkov, Dave Hansen, Ravi Bangoria, x86,
H. Peter Anvin, linux-perf-users, linux-kernel
On 11/13/2022 4:03 AM, Liang Yan wrote:
>
> On 10/31/22 10:28, Sandipan Das wrote:
>> Hi Liang, Peter,
>>
>> On 10/31/2022 6:29 PM, Peter Zijlstra wrote:
>>> On Thu, Oct 27, 2022 at 09:35:11AM -0400, Liang Yan wrote:
>>>> After disabling cpu.perfctr_core in qemu, I noticed that the guest kernel
>>>> still loads the pmu driver while the cpuid does not have perfctl_core.
>>>>
>>>> The test is running on an EPYC Rome machine.
>>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# lscpu | grep perfctl
>>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~#
>>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
>>>> [ 0.732097] Performance Events: AMD PMU driver.
>>>>
>>>> By further looking,
>>>>
>>>> ==> init_hw_perf_events
>>>> ==> amd_pmu_init
>>>> ==> amd_core_pmu_init
>>>> ==>
>>>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>>>> return 0;
>>>>
>>>> With returning 0, it will bypass amd_pmu_init and return 0 to
>>>> init_hw_perf_events, and continue the initialization.
>>>>
>>>> I am not a perf expert and not sure if it is expected for AMD PMU,
>>>> otherwise, it would be nice to return -ENODEV instead.
>>>>
>>>> New output after the change:
>>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
>>>> [ 0.531609] Performance Events: no PMU driver, software events only.
>>>>
>>>> Signed-off-by: Liang Yan <lyan@digtalocean.com>
>>> Looks about right, Ravi?
>>>
>>>> ---
>>>> arch/x86/events/amd/core.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
>>>> index 8b70237c33f7..34d3d2944020 100644
>>>> --- a/arch/x86/events/amd/core.c
>>>> +++ b/arch/x86/events/amd/core.c
>>>> @@ -1335,7 +1335,7 @@ static int __init amd_core_pmu_init(void)
>>>> int i;
>>>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>>>> - return 0;
>>>> + return -ENODEV;
>>>>
>> There are four legacy counters that are always available even when PERFCTR_CORE
>> is absent. This is why the code returns 0 here. I found this to be a bit confusing
>> as well during PerfMonV2 development so I wrote the following patch but forgot to
>> send it out.
>
>
> Hi Sandipan,
>
> Thanks for the classification.
> Do these legacy counters belong to the AMD PMU property from a VM perspective? I mean, if I want to disable PMU for an AMD vcpu for some reason, is it possible to disable perfctr_core and the four counters, or is this not logical since the four counters could not be disabled from the bare-metal level?
> I asked because I saw 'pmu' could be disabled for Intel and ARM, but it seems not for AMD.
>
From what I see, the four legacy counters are not tied to any processor
properties (e.g. CPUID bits). Disabling "perfctr-core" only brings the
number of supported core counters down to 4 from 6. So guests exhibit
the same behaviour as bare-metal where the legacy counters are used if
CPUID 0x80000001[ECX].PerfCtrExtCore is not set.
The "pmu" property only overrides guest CPUID. Hence it is not possible
to prevent the discovery of the legacy counters using that.
> Also, could you please list the four legacy counters here?
>
The MSRs for the four legacy counters are:
0xc001000[0..3] known as PERF_LEGACY_CTL[0..3], alias of PERF_CTL[0..3]
0xc001000[4..7] known as PERF_LEGACY_CTR[0..3], alias of PERF_CTR[0..3]
You can find more details in the Processor Programming Reference (PPR) that
is appropriate for the AMD processor that you are using. PPRs can be found
at: https://bugzilla.kernel.org/show_bug.cgi?id=206537
>
>
>> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
>> index 262e39a85031..d3eb7b2f4dda 100644
>> --- a/arch/x86/events/amd/core.c
>> +++ b/arch/x86/events/amd/core.c
>> @@ -1345,6 +1345,14 @@ static int __init amd_core_pmu_init(void)
>> u64 even_ctr_mask = 0ULL;
>> int i;
>> + /*
>> + * All processors support four PMCs even when X86_FEATURE_PERFCTR_CORE
>> + * is unavailable. They are programmable via the PERF_LEGACY_CTLx and
>> + * PERF_LEGACY_CTRx registers which have the same address as that of
>> + * MSR_K7_EVNTSELx and MSR_K7_PERFCTRx. For Family 17h+, these are
>> + * legacy aliases of PERF_CTLx and PERF_CTRx respectively. Hence, not
>> + * returning -ENODEV here.
>> + */
>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>> return 0;
>>
>>
>> If this looks good to you, I will post it.
>>
>> - Sandipan
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arch/x86/events/amd/core.c: Return -ENODEV when CPU does not have PERFCTL_CORE bit
2022-11-14 10:52 ` Sandipan Das
@ 2022-11-23 5:41 ` Sandipan Das
0 siblings, 0 replies; 6+ messages in thread
From: Sandipan Das @ 2022-11-23 5:41 UTC (permalink / raw)
To: Liang Yan
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Thomas Gleixner, Borislav Petkov, Dave Hansen, Ravi Bangoria, x86,
H. Peter Anvin, linux-perf-users, linux-kernel
On 11/14/2022 4:22 PM, Sandipan Das wrote:
> On 11/13/2022 4:03 AM, Liang Yan wrote:
>>
>> On 10/31/22 10:28, Sandipan Das wrote:
>>> Hi Liang, Peter,
>>>
>>> On 10/31/2022 6:29 PM, Peter Zijlstra wrote:
>>>> On Thu, Oct 27, 2022 at 09:35:11AM -0400, Liang Yan wrote:
>>>>> After disabling cpu.perfctr_core in qemu, I noticed that the guest kernel
>>>>> still loads the pmu driver while the cpuid does not have perfctl_core.
>>>>>
>>>>> The test is running on an EPYC Rome machine.
>>>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# lscpu | grep perfctl
>>>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~#
>>>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
>>>>> [ 0.732097] Performance Events: AMD PMU driver.
>>>>>
>>>>> By further looking,
>>>>>
>>>>> ==> init_hw_perf_events
>>>>> ==> amd_pmu_init
>>>>> ==> amd_core_pmu_init
>>>>> ==>
>>>>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>>>>> return 0;
>>>>>
>>>>> With returning 0, it will bypass amd_pmu_init and return 0 to
>>>>> init_hw_perf_events, and continue the initialization.
>>>>>
>>>>> I am not a perf expert and not sure if it is expected for AMD PMU,
>>>>> otherwise, it would be nice to return -ENODEV instead.
>>>>>
>>>>> New output after the change:
>>>>> root@ubuntu-s-4vcpu-8gb-amd-nyc1-01:~# dmesg | grep PMU
>>>>> [ 0.531609] Performance Events: no PMU driver, software events only.
>>>>>
>>>>> Signed-off-by: Liang Yan <lyan@digtalocean.com>
>>>> Looks about right, Ravi?
>>>>
>>>>> ---
>>>>> arch/x86/events/amd/core.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
>>>>> index 8b70237c33f7..34d3d2944020 100644
>>>>> --- a/arch/x86/events/amd/core.c
>>>>> +++ b/arch/x86/events/amd/core.c
>>>>> @@ -1335,7 +1335,7 @@ static int __init amd_core_pmu_init(void)
>>>>> int i;
>>>>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>>>>> - return 0;
>>>>> + return -ENODEV;
>>>>>
>>> There are four legacy counters that are always available even when PERFCTR_CORE
>>> is absent. This is why the code returns 0 here. I found this to be a bit confusing
>>> as well during PerfMonV2 development so I wrote the following patch but forgot to
>>> send it out.
>>
>>
>> Hi Sandipan,
>>
>> Thanks for the classification.
>> Do these legacy counters belong to the AMD PMU property from a VM perspective? I mean, if I want to disable PMU for an AMD vcpu for some reason, is it possible to disable perfctr_core and the four counters, or is this not logical since the four counters could not be disabled from the bare-metal level?
>> I asked because I saw 'pmu' could be disabled for Intel and ARM, but it seems not for AMD.
>>
>
> From what I see, the four legacy counters are not tied to any processor
> properties (e.g. CPUID bits). Disabling "perfctr-core" only brings the
> number of supported core counters down to 4 from 6. So guests exhibit
> the same behaviour as bare-metal where the legacy counters are used if
> CPUID 0x80000001[ECX].PerfCtrExtCore is not set.
>
> The "pmu" property only overrides guest CPUID. Hence it is not possible
> to prevent the discovery of the legacy counters using that.
>
Following up on this:
KVM has an "enable_pmu" parameter which when disabled can turn off guest PMC
access completely.
Here's how it works:
Upon setting enable_pmu=0, the PMC MSR interceptions fail. The SVM code also
takes care of clearing the PerfCtrExtCore bit for the guest CPUID (see
svm_set_cpu_caps() in arch/x86/kvm/svm/svm.c).
During PMU initialization, check_hw_exists() from arch/x86/events/core.c tests
if all the required PMC MSRs are accessible by reading them. For a guest, this
fails due to an exception and stops hardware PMU initialization. At this point,
the guest kernel continues with just software events.
>> Also, could you please list the four legacy counters here?
>>
>
> The MSRs for the four legacy counters are:
> 0xc001000[0..3] known as PERF_LEGACY_CTL[0..3], alias of PERF_CTL[0..3]
> 0xc001000[4..7] known as PERF_LEGACY_CTR[0..3], alias of PERF_CTR[0..3]
>
> You can find more details in the Processor Programming Reference (PPR) that
> is appropriate for the AMD processor that you are using. PPRs can be found
> at: https://bugzilla.kernel.org/show_bug.cgi?id=206537
>
>>
>>
>>> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
>>> index 262e39a85031..d3eb7b2f4dda 100644
>>> --- a/arch/x86/events/amd/core.c
>>> +++ b/arch/x86/events/amd/core.c
>>> @@ -1345,6 +1345,14 @@ static int __init amd_core_pmu_init(void)
>>> u64 even_ctr_mask = 0ULL;
>>> int i;
>>> + /*
>>> + * All processors support four PMCs even when X86_FEATURE_PERFCTR_CORE
>>> + * is unavailable. They are programmable via the PERF_LEGACY_CTLx and
>>> + * PERF_LEGACY_CTRx registers which have the same address as that of
>>> + * MSR_K7_EVNTSELx and MSR_K7_PERFCTRx. For Family 17h+, these are
>>> + * legacy aliases of PERF_CTLx and PERF_CTRx respectively. Hence, not
>>> + * returning -ENODEV here.
>>> + */
>>> if (!boot_cpu_has(X86_FEATURE_PERFCTR_CORE))
>>> return 0;
>>>
>>>
>>> If this looks good to you, I will post it.
>>>
>>> - Sandipan
>>>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-11-23 5:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-27 13:35 [PATCH] arch/x86/events/amd/core.c: Return -ENODEV when CPU does not have PERFCTL_CORE bit Liang Yan
2022-10-31 12:59 ` Peter Zijlstra
2022-10-31 14:28 ` Sandipan Das
2022-11-12 22:33 ` Liang Yan
2022-11-14 10:52 ` Sandipan Das
2022-11-23 5:41 ` Sandipan Das
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).