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
|
|
|
|
|
|
|
|
|
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.
