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

[Sean Christopherson]

On Fri, May 15, 2026, David Riley wrote:
> Hi Paolo, Hi Chao, Hi Sean,
> 
> I have been testing the v6 patchset (up to 22/28) this time on Arrow
> Lake hardware. My results suggest a kernel version dependent regression
> regarding host stability.
> 
> Environment:
> * Host CPU: Intel(R) Core(TM) Ultra 7 265K (Arrow Lake)
> * Motherboard: Gigabyte Z890 EAGLE (BIOS F18)
> * Host OS: Proxmox VE based on Debian Trixie
> * Host Kernel: mainline with patches 1-22/28 applied.
> * Guest OS: Windows Server 2026 (24H2, Build 26100.1742) with VBS/Hyper-V
>   enabled.
> * QEMU Command: -cpu host,level=30,+vmx-mbec,+cet-ss,+cet-ibt
> 
> Results for Kernel 7.1.0-rc3 + v6 patches 1-22:
> I can reproduce the guest failing to boot. This setup causes host lockups on
> my Arrow Lake machine. In some cases, the guest manages to reach Windows
> Recovery, but most of the time it does not.
> 
> @Chao, in the first line you can see the hard lockup. Also have a look at the
> hrtimer trap I tested below.
> 
> dmesg output:
> [Fri May 15 13:07:37 2026] watchdog: CPU1: Watchdog detected hard LOCKUP on cpu 1

...

> If I run:
> sudo modprobe -r kvm_intel
> sudo modprobe kvm_intel preemption_timer=0
> 
> I am able to boot into windows sometimes.

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?

> Results for Kernel 7.1.0-rc3 + v6 patches 1-22 + hrtimer trap:
> 
> I used the mentioned trap from [0]

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