Re: [PATCH v8 1/7] target/i386/kvm: set KVM_PMU_CAP_DISABLE if "-pmu" is configured

[Dongli Zhang <dongli.zhang@oracle.com>]

On Tue, Oct 6, 2026 1:41:05AM -0700, Sandipan Das wrote:
> On 01-10-2026 16: 42, Sandipan Das wrote: > On 01-10-2026 16: 35, Michael
> Tokarev wrote: >> On 10/1/26 13: 43, Sandipan Das wrote: >>> On 01-10-2026 15: 
> 30, Michael Tokarev wrote: >>>> On 10/1/26 11: 54, Sandipan Das
> 
> On 01-10-2026 16:42, Sandipan Das wrote:
>> On 01-10-2026 16:35, Michael Tokarev wrote:
>>> On 10/1/26 13:43, Sandipan Das wrote:
>>>> On 01-10-2026 15:30, Michael Tokarev wrote:
>>>>> On 10/1/26 11:54, Sandipan Das wrote:
>>>>>> On 01-10-2026 14:02, Michael Tokarev wrote:
>>>>> ...
>>>>>
>>>>>>> When booting windows11 VM with -cpu EPYC-Rome-v4 -enable-kvm, the
>>>>>>> guest enters tight CPU loop while displaying a boot screen, before
>>>>>>> it starts showing up the rotating circle (which shows boot progress).
>>>>>
>>>>>
>>>>>> What happens if you use "-cpu EPYC-Rome-v4,+pmu"?
>>>>>
>>>>> With that, it boots fine, just like before this patch.
>>>>> I checked current master too - same, +pmu fixes it.
>>>>>
>>>> A guest OS cannot expect a functioning PMU if the hypervisor has disabled
>>>> it. Linux runs a basic sanity test to determine this. See:
>>>> https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/master/arch/
> x86/events/core.c*L268__;Iw!!ACWV5N9M2RV99hQ!
> PdJ7r8w0UUuD5iOlCxu7931wevMkDprX9yCV5mkfktbFkpOobtIWrkMt0Gmb9Ztnj3iZHwTK4UQHh85raOPEmgo$ <https://urldefense.com/v3/__https://github.com/torvalds/linux/blob/master/arch/x86/events/core.c*L268__;Iw!!ACWV5N9M2RV99hQ!PdJ7r8w0UUuD5iOlCxu7931wevMkDprX9yCV5mkfktbFkpOobtIWrkMt0Gmb9Ztnj3iZHwTK4UQHh85raOPEmgo$>
>>>
>>> So.. what do we do with all this?  :)
>>>
>>> I kinda see the intention of the original change, but it results in
>>> non-bootable systems (linux too, as I think you demonstrate above).
>>>
>> 
>> Because of the sanity test, Linux will boot but not register the "cpu" PMU.
>> Perhaps others should also run a similar sanity test on PMU hardware rather
>> than making assumptions and failing to boot.
> 
> After looking at kvm_msr and kvm_cpuid traces, I see that Windows is indeed
> getting #GPs upon accessing MSRs 0xc0010200 and 0xc0010201 but it is not at
> fault here since it expects these MSRs to be available as guest CPUID
> 0x80000001[ECX].PerfCtrExtCore is set. This feature bit should have been
> cleared by QEMU when "pmu=off".
> 
> It boots up when "pmu=off" is combined with "perfctr-core=off" and
> "perfmon-v2=off". The missing pieces here are the following:
> 
> https://lore.kernel.org/qemu-devel/20251111061532.36702-2-dongli.zhang@oracle.com/
> https://lore.kernel.org/qemu-devel/20251111061532.36702-3-dongli.zhang@oracle.com/
> 
> Dongli, Zhao,
> 
> I see a discussion about compat array at
> https://lore.kernel.org/qemu-devel/aUEXkDDOba+oZ4v+@intel.com/
> 
> Is this ready for the two patches above to be pulled in?
> 

Thanks Sandipan for analyzing the issue!

Hi Zhao,

I noticed that the machine compat arrays are now available. Would you be able to
send updated versions of patches 1 and 2 with the compatibility property you
suggested?

Thank you very much!

Dongli Zhang