Re: [syzbot ci] Re: KVM: x86: Unconditionally recompute CR8 intercept on PPR update

On Mon, Jun 15, 2026 at 11:37:45AM -0700, Sean Christopherson wrote:
>On Mon, Jun 15, 2026, Carlos López wrote:
>> On 6/11/26 7:20 PM, Sean Christopherson wrote:
>> > On Thu, Jun 11, 2026, syzbot ci wrote:
>> >> ------------[ cut here ]------------
>> >> debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count))
>> >> WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879
>> >> WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879
>> >> Modules linked in:
>> >> CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)
>> >> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
>> >> RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline]
>> >> RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879
>> >>  apic_update_ppr arch/x86/kvm/lapic.c:984 [inline]
>> >>  kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023
>> >>  kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986
>> >>  kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847
>> >>  kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201
>> >>  kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159
>> >>  vfs_ioctl fs/ioctl.c:51 [inline]
>> >>  __do_sys_ioctl fs/ioctl.c:597 [inline]
>> >>  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
>> >>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>> >>  do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
>> >>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>> >
>> > This is "fine", the assertion just wants to make sure KVM isn't access vmcs12
>> > without holding vcpu->mutex, otherwise any queries are inherently unstable.
>> > It's just that vCPU creation runs without taking vcpu->mutex, because the vCPU
>> > is otherwise unreachable.
>> >
>> > I'm pretty sure we can squash the WARN by grabbing vmcs12 if and only if the vCPU
>> > is actually in guest mode.
>>
>> Will you add this on top or should I send a v3?
>
>Gah, I was going to say "I'll fixup when applying", but that leads to an unwieldy
>changelog.  I'll send a v3 with this slotted in as a proper prep patch, might as
>well let syzbot have another go at it, to make sure there isn't another assertion
>lurking.

I successfully tested Carlos's v2 plus this hunk with SVSM as mentioned 
in the link in the description.

So, feel free to carry my T-b in v3:

Tested-by: Stefano Garzarella <[email protected]>

Thanks,
Stefano

>
>> > diff --git arch/x86/kvm/vmx/vmx.c arch/x86/kvm/vmx/vmx.c
>> > index c548f22375ad..332fbcd924f2 100644
>> > --- arch/x86/kvm/vmx/vmx.c
>> > +++ arch/x86/kvm/vmx/vmx.c
>> > @@ -6876,11 +6876,10 @@ int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
>> >
>> >  void vmx_update_cr8_intercept(struct kvm_vcpu *vcpu, int tpr, int irr)
>> >  {
>> > -       struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
>> >         int tpr_threshold;
>> >
>> >         if (is_guest_mode(vcpu) &&
>> > -               nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW))
>> > +           nested_cpu_has(get_vmcs12(vcpu), CPU_BASED_TPR_SHADOW))
>> >                 return;
>> >
>> >         guard(vmx_vmcs01)(vcpu);
>> >
>> >
>> > Longer term, I'll work on figuring out how to handle this in get_vmcs12(), because
>> > to_hv_vcpu() has the solve the same fundamental problem:
>> >
>> > https://lore.kernel.org/all/[email protected]
>>
>