Re: [PATCH v6 00/28] KVM: combined patchset for MBEC/GMET support

[David Riley]

Hi Sean,
thanks for the input.

On 5/15/26 8:31 PM, Sean Christopherson wrote:
> [...]
> Hmm, this probably confirms its the hrtimer issue?  When using the VMX preemption
> timer, KVM (on Intel) doesn't use an hrtimer to emulate L1's APIC timer.  I _think_
> forcing KVM to use an hrtimer would cause result in hrtimers being reprogrammed
> in response to KVM's usage, and thus mask the deferred reprogramming bug?  That
> sounds plausible-ish?
> [...]
> Can you try Peter's fixes?  AIUI, the reporter's hack-a-fix was very far from a
> complete fix.  Note, there's a v3 of patch 1 (b4 should take care of that for you,
> if you're using b4).
>
> https://lore.kernel.org/all/20260423155611.216805954@xxxxxxxxxxxxx

I tested it again with the v3 hrtimer patches [0] applied on top of the v6
MBEC/GMET series.

Setup:
* Host CPU: Intel(R) Core(TM) Ultra 7 265K (Arrow Lake)
* Host OS: Proxmox VE (based on Debian Trixie)
* Host Kernel: mainline kernel 7.1.0-rc4 with v6 MBEC/GMET and v3 
hrtimer [0]
* QEMU: 11.0.0 (downstream build)
* Guest OS: Windows Server 2026 (24H2, Build 26100.1742) with VBS/Hyper-V
   enabled.

Using:
* QEMU CPU Options: -cpu host,level=30,+vmx-mbec,-cet-ss,-cet-ibt

The CPU lockups did not occur anymore and I was able to boot the Guest. 
Keep
in mind that in this case I have the cet-ss and cet-ibt not passed along 
to the
guest.

If I launch the same Virtual Guest using
* QEMU CPU Options: -cpu host,level=30,+vmx-mbec,+cet-ss,+cet-ibt

The issue of the VM being stuck on boot persists even with the hrtimer 
patches
applied, but now there are no hard/soft lockups of the CPU anymore.

I get this trace using: trace-cmd record -e kvm

       CPU 0/KVM-11837 [001] d..2.  1363.314703: kvm_apic_accept_irq:  
apicid 0 vec 209 (Fixed|edge)
       CPU 0/KVM-11837 [001] d..2.  1363.314703: kvm_apicv_accept_irq: 
apicid 0 vec 209 (Fixed|edge)
       CPU 0/KVM-11837 [001] d..3.  1363.314703: kvm_hv_timer_state:  
 vcpu_id 0 hv_timer 1
       CPU 0/KVM-11837 [001] d..1.  1363.314703: kvm_entry:      vcpu 0 
rip 0xfffff801a59020f7
       CPU 0/KVM-11837 [001] d..1.  1363.314703: kvm_wait_lapic_expire: 
vcpu 0: delta -590 (late)
       CPU 0/KVM-11837 [001] d..1.  1363.314993: kvm_exit:      reason 
EXTERNAL_INTERRUPT rip 0xfffff801a59020ec info 0 0
       CPU 0/KVM-11837 [001] d..1.  1363.314994: kvm_entry:      vcpu 0 
rip 0xfffff801a59020ec
       CPU 0/KVM-11837 [001] d..1.  1363.315993: kvm_exit:      reason 
EXTERNAL_INTERRUPT rip 0xfffff801a59020ec info 0 0
       CPU 0/KVM-11837 [001] d..1.  1363.315993: kvm_entry:      vcpu 0 
rip 0xfffff801a59020ec
       CPU 0/KVM-11837 [001] d..1.  1363.316993: kvm_exit:      reason 
EXTERNAL_INTERRUPT rip 0xfffff801a59020ec info 0 0
       CPU 0/KVM-11837 [001] d..1.  1363.316994: kvm_entry:      vcpu 0 
rip 0xfffff801a59020ec
       CPU 0/KVM-11837 [001] d..1.  1363.317992: kvm_exit:      reason 
EXTERNAL_INTERRUPT rip 0xfffff801a59020ec info 0 0
       CPU 0/KVM-11837 [001] d..1.  1363.317993: kvm_entry:      vcpu 0 
rip 0xfffff801a59020ec
       CPU 0/KVM-11837 [001] d..1.  1363.318992: kvm_exit:      reason 
EXTERNAL_INTERRUPT rip 0xfffff801a59020ec info 0 0
       CPU 0/KVM-11837 [001] d..1.  1363.319269: kvm_entry:      vcpu 0 
rip 0xfffff801a59020ec
       CPU 0/KVM-11837 [001] d..1.  1363.319992: kvm_exit:      reason 
EXTERNAL_INTERRUPT rip 0xfffff801a59020ec info 0 0
       CPU 0/KVM-11837 [001] d..1.  1363.319994: kvm_entry:      vcpu 0 
rip 0xfffff801a59020ec

I did not spot anything useful in the dmesg/journalctl output.

I also did the same tests with mainline kernel
7.1.0-rc3 with v6 MBEC/GMET (patches 1-22 of 28) and v3 hrtimer [0]
and got the same results.

Best regards,
David

[0] https://lore.kernel.org/all/20260423155611.216805954@xxxxxxxxxxxxx