RE: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when virtualised

["Katz, Jonathan" <jonathan.katz@xxxxxxxxx>]

Tested on xcp-ng vm on esx 8 that previously failed to boot when performance counters were not enabled.

- patched host
- rebooted host
- host still came up normally
- shut host down
- turned off performance counters on vm
- booted host
- host still came up normally and no issues running vms

Thanks!
jonathan

Jonathan​​​​

Katz

IS Senior Specialist, Infrastructure Operations Engineer

AptarGroup

265 Exchange Drive, Suite 100

,

Crystal Lake

,

Illinois

60014

,

United States

(phone) +1 779 220 4484

|

(mobile) +1 847 525 8441

jonathan.katz@xxxxxxxxx

|

www.aptar.com

AptarOnlineSignature

-----Original Message-----
From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Sent: Monday, January 27, 2025 6:42 AM
To: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>; Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
Cc: Katz, Jonathan <jonathan.katz@xxxxxxxxx>; Jan Beulich <JBeulich@xxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>
Subject: Re: [PATCH for-4.20] x86/intel: Fix PERF_GLOBAL fixup when virtualised


EXTERNAL MAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.


On 21/01/2025 4:57 pm, Oleksii Kurochko wrote:
>
> On 1/21/25 3:25 PM, Andrew Cooper wrote:
>> Logic using performance counters needs to look at
>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>
>> When virtualised under ESX, Xen dies with a #GP fault trying to read
>> MSR_CORE_PERF_GLOBAL_CTRL.
>>
>> Factor this logic out into a separate function (it's already too
>> squashed to the RHS), and insert a check of
>> MSR_MISC_ENABLE.PERF_AVAILABLE.
>>
>> This also limits setting X86_FEATURE_ARCH_PERFMON, although oprofile
>> (the only consumer of this flag) cross-checks too.
>>
>> Reported-by: Jonathan Katz <jonathan.katz@xxxxxxxxx>
>> Link:
>> https://nam02.safelinks.protection.outlook.com/?url=""> >> -ng.org%2Fforum%2Ftopic%2F10286%2Fnesting-xcp-ng-on-esx-8&data=""> >> 2%7Cjonathan.katz%40aptar.com%7Cc036df18462d402eda5608dd3ed01147%7C5f
>> d74a3ed57a410e8d7c02c4df062234%7C0%7C0%7C638735785584484308%7CUnknown
>> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW
>> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jG5dfAjyXvB
>> JRrtNklKp8MjGOUoYGntpD14eRP5GCcI%3D&reserved=0
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> ---
>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> CC: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
>>
>> Untested, but this is the same pattern used by oprofile and watchdog
>> setup.
>
> Probably it will make sense to wait for a response on the forum (you
> mentioned in the Link:) that the current one patch works?

It's been a week. At this point it needs to go in for the release. As I said, this is exactly the same pattern as used elsewhere in Xen, so I'm confident it's a good fix, and Roger agrees too.

~Andrew

This e-mail may contain confidential information. If you are not the intended recipient, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Aptar’s Privacy Policy explains how Aptar may use your personal information or data and any personal information or data provided or made available to us.