Re: REGRESSION on linux-next (next-20250919)

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

On 10/9/2025 8:58 PM, Sean Christopherson wrote:
> On Thu, Oct 09, 2025, Dapeng Mi wrote:
>> On 10/7/2025 2:22 PM, Borah, Chaitanya Kumar wrote:
>>> Hi,
>>>
>>> On 10/6/2025 1:33 PM, Borah, Chaitanya Kumar wrote:
>>>> Thank you for your responses.
>>>>
>>>> Following change fixes the issue for us.
>>>>
>>>>
>>>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>>>> index 40ac4cb44ed2..487ad19a236e 100644
>>>> --- a/arch/x86/kvm/pmu.c
>>>> +++ b/arch/x86/kvm/pmu.c
>>>> @@ -108,16 +108,18 @@ void kvm_init_pmu_capability(const struct 
>>>> kvm_pmu_ops *pmu_ops)
>>>>          bool is_intel = boot_cpu_data.x86_vendor == X86_VENDOR_INTEL;
>>>>          int min_nr_gp_ctrs = pmu_ops->MIN_NR_GP_COUNTERS;
>>>>
>>>> -       perf_get_x86_pmu_capability(&kvm_host_pmu);
>>>> -
>>>>          /*
>>>>           * Hybrid PMUs don't play nice with virtualization without careful
>>>>           * configuration by userspace, and KVM's APIs for reporting 
>>>> supported
>>>>           * vPMU features do not account for hybrid PMUs.  Disable vPMU 
>>>> support
>>>>           * for hybrid PMUs until KVM gains a way to let userspace opt-in.
>>>>           */
>>>> -       if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU))
>>>> +       if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) {
>>>>                  enable_pmu = false;
>>>> +               memset(&kvm_host_pmu, 0, sizeof(kvm_host_pmu));
>>>> +       } else {
>>>> +               perf_get_x86_pmu_capability(&kvm_host_pmu);
>>>> +       }
>>> Can we expect a formal patch soon?
>> I'd like to post a patch to fix this tomorrow if Sean has no bandwidth on
>> this. Thanks.
> Sorry, my bad, I was waiting for you to post a patch, but that wasn't at all
> clear.  So yeah, go ahead and post one :-)

Sure. Would post it now.