Re: [PATCH v2 11/16] KVM: x86/pmu: Emulate the GLOBAL_STATUS_SET and GLOBAL_INUSE MSRs

[Chen, Zide]

On 11/2/2026 12:49 PM, Yosry Ahmed wrote:
>>>> OTOH, what about PerfMon v4 bits 58 (GLOBAL_STATUS_LBRS_FROZEN), 59
>>>> (GLOBAL_STATUS_COUNTERS_FROZEN), and 61 (GLOBAL_STATUS_OVF_UNCORE)?  Per
>>>> Intel SDM Vol. 4, Table 2-2, those bits are valid in
>>>> IA32_PERF_GLOBAL_STATUS, IA32_PERF_GLOBAL_STATUS_RESET, and
>>>> IA32_PERF_GLOBAL_STATUS_SET when CPUID.0AH:EAX[7:0] > 3.
>>>>
>>>> When those MSRs are passed through in mediated mode, the guest can set bits
>>>> 58, 59, or 61 in hardware via IA32_PERF_GLOBAL_STATUS_SET. Leaving those
>>>> bits set in pmu->global_status_rsvd for pmu->version >= 4 will break
>>>> KVM_SET_MSRS(MSR_CORE_PERF_GLOBAL_STATUS) as well as any intercepted guest
>>>> writes to GLOBAL_OVF_CTRL / GLOBAL_STATUS_SET.
>>>>
>>>> As I pointed out in patch 04/16, we can't pass through the PMU global
>>>> controls unless their reserved bits match hardware.
>>>
>>> I think there are two other relevant (but pre-existing) problems here:
>>>
>>> 1. GLOBAL_STATUS_TRACE_TOPAPMI_BIT can leak from the host into the
>>> guest. If a host PT PMI arrives while the guest context is loaded, bit
>>> 55 will be set for the guest, and the guest won't be able to clear it if
>>> OVF_CTRL is intercepted (it will #GP as it is reserved for the guest).
>>> Similarly, the value can't be restored through KVM_SET_MSRS.
>>
>> I think mediated vPMU assumes that no host PMIs can be generated while
>> guest PMU state is loaded.
>>
>> If PT state can leak into the guest via bit 55, similar leakage can also
>> occur for other status bits, e.g. when the guest exposes fewer
>> general-purpose or fixed counters than the host.
>>
>> The scenario where both host and guest can be active simultaneously is
>> handled by the perfmon_mask case, where intel_mediated_pmu_{load,put}()
>> filter guest-owned status bits.
> 
> Looking at the code:
> 
> kvm_mediated_pmu_load() -> perf_load_guest_context() ->
> perf_ctx_disable() will iterate PMUs with for_each_epc() and disable
> them, which skips PMUs without PERF_PMU_CAP_MEDIATED_VPMU.
> 
> Same for kvm_mediated_pmu_load() -> perf_load_guest_context()
> ->ctx_sched_out(), it also uses for_each_epc() to iterate PMUs and
> schedule them out.
> 
> pt_init() does not set PERF_PMU_CAP_MEDIATED_VPMU on pt_pmu.pmu.capabilities
> 
> Please correct me if I am wrong.

My apologies, this bug is indeed real because pt_pmu lacks the
PERF_PMU_CAP_MEDIATED_VPMU capability.

Adding this capability to pt_pmu seems intuitive, but unlike

                       the core PMU (which merely toggles enable bits),
Intel PT is an AUX-based PMU. Stopping and restarting it on every VM
transition is heavier, and I'm not sure whether it could introduce a
noticeable performance penalty.

However, whether the solution is adding PERF_PMU_CAP_MEDIATED_VPMU or
some other mechanism to enforce mutual exclusion between pt_pmu and
mediated vPMU, we can address that in a separate patch.

To immediately protect guest state and live migration in this series,
I'm thinking of adding the following defensive filter in
intel_mediated_pmu_put():

+ /*
+  * Scrub bits that are not virtualized for the guest to prevent
+  * possible host state from leaking into guest state and breaking
+  * live migration.
+  */
+  pmu->global_status &= ~pmu->global_status_rsvd;

> 
>>
>> https://lore.kernel.org/kvm/20260821222002.54907-1-zide.chen@xxxxxxxxx/T/#m90394fda6d71ed0dd539a579abfb0c1df1e044fe
>>
>>> (I think the PMI may also be lost as LVTPC points at the mediated vPMU
>>> vector)
>>>
>>> 2. On AMD, bit 58 and 59 have a similar problem. HW accepts those bits
>>> but they are reserved for the guest, so the guest can set them if
>>> GLOBAL_STATUS_SET is passed through, but userspace cannot restore them.
>>
>> Right. That seems orthogonal to this series and could be addressed with
>> follow-up fixes.
> 
> Maybe AMD folks on the thread will take a look :)