Re: WARNING in kvm_arch_vcpu_ioctl_run

Re: WARNING in kvm_arch_vcpu_ioctl_run

[Sean Christopherson]

+LKML (lore isn't picking this up for some reason) and a real subject

On Thu, Mar 16, 2023, zhangjianguo (A) wrote:
> Hi all,
> 
> Install the 6.3.0-rc1 kernel on the x86 server, and execute the https://syzkaller.appspot.com/text?tag=ReproC&x=14b34300880000 test case, the call trace appears.
> 
> [  +0.000028] ------------[ cut here ]------------
> [  +0.000002] WARNING: CPU: 36 PID: 73250 at arch/x86/kvm/x86.c:11060 kvm_arch_vcpu_ioctl_run+0x482/0x4b0 [kvm]
> [  +0.000086] Modules linked in: openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass rapl intel_cstate ixgbe ses intel_uncore mei_me enclosure pcspkr i2c_i801 mdio sunrpc mei intel_pch_thermal i2c_smbus joydev lpc_ich dca sg acpi_power_meter drm vhost_net tun vhost fuse vhost_iotlb tap ext4 mbcache jbd2 sd_mod crct10dif_pclmul ipmi_si ahci crc32_pclmul crc32c_intel libahci ipmi_devintf ghash_clmulni_intel mpt3sas libata sha512_ssse3 ipmi_msghandler wdat_wdt raid_class scsi_transport_sas dm_mod br_netfilter bridge stp llc nvme nvme_core t10_pi crc64_rocksoft_generic crc64_rocksoft crc64 nbd
> [  +0.000077] CPU: 36 PID: 73250 Comm: run_vcpu_ioctrl Not tainted 6.3.0-rc1+ #2
> [  +0.000004] Hardware name: Huawei RH2288 V3/BC11HGSB0, BIOS 3.87 02/02/2018
> [  +0.000002] RIP: 0010:kvm_arch_vcpu_ioctl_run+0x482/0x4b0 [kvm]
> [  +0.000002] Call Trace:
> [  +0.000003]  <TASK>
> [  +0.000003]  kvm_vcpu_ioctl+0x279/0x680 [kvm]
> [  +0.000047]  ? vfs_write+0x2c8/0x3d0
> [  +0.000006]  __x64_sys_ioctl+0x8f/0xc0
> [  +0.000006]  do_syscall_64+0x3f/0x90
> [  +0.000007]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> [  +0.000002]  </TASK>
> [  +0.000002] ---[ end trace 0000000000000000 ]---
> 
> |        } else {
> |                WARN_ON_ONCE(vcpu->arch.pio.count);
> |                WARN_ON_ONCE(vcpu->mmio_needed);      // where the splat triggered
> |        }

The splat occurs due to a longstanding (literally since KVM's inception) shortcoming
in KVM's uAPI.  On an emulated MMIO write, KVM finishes the instruction before
exiting to userspace.  This is necessary given how KVM's uAPI works, as outside
of REP string instructions, KVM doesn't provide a way to restart an instruction
that partially completed before the MMIO was encountered.

For the vast majority of _emulated_ instructions, this doesn't cause problems as
there is a single memory accesses, i.e. any exceptions on the instruction will
occur _before_ the MMIO write.

What's happening here is that a PUSHA triggers an MMIO write and then runs past
the segment limit, resulting in a #SS after the MMIO is queued.  KVM injects the
#SS (well, tries to) and thus loses track of the MMIO, but never clears mmio_needed.

There's a second bug here that results in failed VM-Enter when KVM tries to inject
the #SS: KVM doesn't ignore drop error code when the vCPU is in Real Mode.  This
too is a longstanding bug that has likely escaped notice because no real work code
runs in Real Mode _and_ gracefully handles exceptions.

My plan, pending testing, is to suppress the MMIO write + exception scenario since
the bug has been around for 15+ years without anyone noticing, let alone caring.
Fixing it properly would be a heck of a lot of complexity and code churn for no
real benefit.

And for the Real Mode exception bug, unless I'm missing something, the error code
can simply be suppressed when queueing the exception.

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 237c483b1230..b3bf3a0d74ab 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -646,6 +646,9 @@ static void kvm_multiple_exception(struct kvm_vcpu *vcpu,
 
        kvm_make_request(KVM_REQ_EVENT, vcpu);
 
+       /* Real Mode exceptions do not report error codes. */
+       has_error &= is_protmode(vcpu);
+
        /*
         * If the exception is destined for L2 and isn't being reinjected,
         * morph it to a VM-Exit if L1 wants to intercept the exception.  A
@@ -8883,6 +8886,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
        }
 
        if (ctxt->have_exception) {
+               WARN_ON_ONCE(vcpu->mmio_needed && !vcpu->mmio_is_write);
+               vcpu->mmio_needed = false;
                r = 1;
                inject_emulated_exception(vcpu);
        } else if (vcpu->arch.pio.count) {

WARNING in kvm_arch_vcpu_ioctl_run

[Yikebaer Aizezi]

Hello, I'm sorry for the mistake in my previous email. I forgot to add
a subject. This is my second attempt to send the message.

When using Healer to fuzz the latest Linux kernel, the following crash
was triggered.

HEAD commit: fdf0eaf11452d72945af31804e2a1048ee1b574c (tag: v6.5-rc2)

git tree: upstream

console output:
https://drive.google.com/file/d/1FiemC_AWRT-6EGscpQJZNzYhXZty6BVr/view?usp=drive_link
kernel config: https://drive.google.com/file/d/1fgPLKOw7QbKzhK6ya5KUyKyFhumQgunw/view?usp=drive_link
C reproducer: https://drive.google.com/file/d/1SiLpYTZ7Du39ubgf1k1BIPlu9ZvMjiWZ/view?usp=drive_link
Syzlang reproducer:
https://drive.google.com/file/d/1eWSmwvNGOlZNU-0-xsKhUgZ4WG2VLZL5/view?usp=drive_link
Similar report:
https://groups.google.com/g/syzkaller-bugs/c/C2ud-S1Thh0/m/z4iI7l_dAgAJ

If you fix this issue, please add the following tag to the commit:
Reported-by: Yikebaer Aizezi <yikebaer61@gmail.com>

kvm: vcpu 129: requested lapic timer restore with starting count
register 0x390=4241646265 (4241646265 ns) > initial count (296265111
ns). Using initial count to start timer.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1977 at arch/x86/kvm/x86.c:11098
kvm_arch_vcpu_ioctl_run+0x152f/0x1830 arch/x86/kvm/x86.c:11098
Modules linked in:
CPU: 0 PID: 1977 Comm: syz-executor Not tainted 6.5.0-rc2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x152f/0x1830 arch/x86/kvm/x86.c:11098
Code: fd ff ff e8 83 ca 67 00 44 89 ee 48 c7 c7 80 8e 42 89 c6 05 e3
40 1e 0c 01 e8 2d 22 33 00 0f 0b e9 ed fc ff ff e8 61 ca 67 00 <0f> 0b
e9 ff fb ff ff e8 55 ca 67 00 80 3d c0 40 1e 0c 00 0f 85 19
RSP: 0018:ffffc900072dfcd8 EFLAGS: 00010212
RAX: 00000000000006a9 RBX: ffff88801852c000 RCX: ffffc90002bd9000
RDX: 0000000000040000 RSI: ffffffff81114ddf RDI: ffff88810e5d0880
RBP: ffff888018995180 R08: 0000000000000000 R09: fffffbfff1f4f5b0
R10: ffffffff8fa7ad87 R11: 0000000000000001 R12: ffff8880189951ac
R13: 0000000000000000 R14: ffff8880189959a8 R15: ffff888018995268
FS:  00007feb64c14640(0000) GS:ffff888063e00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000002a8 CR3: 0000000114888000 CR4: 0000000000752ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 <TASK>
 kvm_vcpu_ioctl+0x4de/0xcc0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x173/0x1e0 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x47959d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 b4 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007feb64c14068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000000000059c0a0 RCX: 000000000047959d
RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000008
RBP: 000000000059c0a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000059c0ac
R13: 000000000000000b R14: 0000000000437250 R15: 00007feb64bf4000
 </TASK>

Modules linked in:
CPU: 0 PID: 1977 Comm: syz-executor Not tainted 6.5.0-rc2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x152f/0x1830 arch/x86/kvm/x86.c:11098
Code: fd ff ff e8 83 ca 67 00 44 89 ee 48 c7 c7 80 8e 42 89 c6 05 e3
40 1e 0c 01 e8 2d 22 33 00 0f 0b e9 ed fc ff ff e8 61 ca 67 00 <0f> 0b
e9 ff fb ff ff e8 55 ca 67 00 80 3d c0 40 1e 0c 00 0f 85 19
RSP: 0018:ffffc900072dfcd8 EFLAGS: 00010212
RAX: 00000000000006a9 RBX: ffff88801852c000 RCX: ffffc90002bd9000
RDX: 0000000000040000 RSI: ffffffff81114ddf RDI: ffff88810e5d0880
RBP: ffff888018995180 R08: 0000000000000000 R09: fffffbfff1f4f5b0
R10: ffffffff8fa7ad87 R11: 0000000000000001 R12: ffff8880189951ac
R13: 0000000000000000 R14: ffff8880189959a8 R15: ffff888018995268
FS:  00007feb64c14640(0000) GS:ffff888063e00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000002a8 CR3: 0000000114888000 CR4: 0000000000752ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 <TASK>
 kvm_vcpu_ioctl+0x4de/0xcc0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x173/0x1e0 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x47959d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 b4 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007feb64c14068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000000000059c0a0 RCX: 000000000047959d
RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000008
RBP: 000000000059c0a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000059c0ac
R13: 000000000000000b R14: 0000000000437250 R15: 00007feb64bf4000
 </TASK>
Kernel panic - not syncing: kernel: panic_on_warn set ...
CPU: 0 PID: 1977 Comm: syz-executor Not tainted 6.5.0-rc2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x92/0xf0 lib/dump_stack.c:106
 panic+0x570/0x620 kernel/panic.c:340
 check_panic_on_warn+0x8e/0x90 kernel/panic.c:236
 __warn+0xee/0x340 kernel/panic.c:673
 __report_bug lib/bug.c:199 [inline]
 report_bug+0x25d/0x460 lib/bug.c:219
 handle_bug+0x3c/0x70 arch/x86/kernel/traps.c:324
 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:345
 asm_exc_invalid_op+0x16/0x20 arch/x86/include/asm/idtentry.h:568
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x152f/0x1830 arch/x86/kvm/x86.c:11098
Code: fd ff ff e8 83 ca 67 00 44 89 ee 48 c7 c7 80 8e 42 89 c6 05 e3
40 1e 0c 01 e8 2d 22 33 00 0f 0b e9 ed fc ff ff e8 61 ca 67 00 <0f> 0b
e9 ff fb ff ff e8 55 ca 67 00 80 3d c0 40 1e 0c 00 0f 85 19
RSP: 0018:ffffc900072dfcd8 EFLAGS: 00010212
RAX: 00000000000006a9 RBX: ffff88801852c000 RCX: ffffc90002bd9000
RDX: 0000000000040000 RSI: ffffffff81114ddf RDI: ffff88810e5d0880
RBP: ffff888018995180 R08: 0000000000000000 R09: fffffbfff1f4f5b0
R10: ffffffff8fa7ad87 R11: 0000000000000001 R12: ffff8880189951ac
R13: 0000000000000000 R14: ffff8880189959a8 R15: ffff888018995268
 kvm_vcpu_ioctl+0x4de/0xcc0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x173/0x1e0 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x47959d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 b4 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007feb64c14068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000000000059c0a0 RCX: 000000000047959d
RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000008
RBP: 000000000059c0a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000059c0ac
R13: 000000000000000b R14: 0000000000437250 R15: 00007feb64bf4000
 </TASK>
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 1 seconds..

Re: WARNING in kvm_arch_vcpu_ioctl_run

[Sean Christopherson]

On Thu, Jul 27, 2023, Yikebaer Aizezi wrote:
> Hello, I'm sorry for the mistake in my previous email. I forgot to add
> a subject. This is my second attempt to send the message.
> 
> When using Healer to fuzz the latest Linux kernel, the following crash
> was triggered.
> 
> HEAD commit: fdf0eaf11452d72945af31804e2a1048ee1b574c (tag: v6.5-rc2)
> 
> git tree: upstream
> 
> console output:
> https://drive.google.com/file/d/1FiemC_AWRT-6EGscpQJZNzYhXZty6BVr/view?usp=drive_link
> kernel config: https://drive.google.com/file/d/1fgPLKOw7QbKzhK6ya5KUyKyFhumQgunw/view?usp=drive_link
> C reproducer: https://drive.google.com/file/d/1SiLpYTZ7Du39ubgf1k1BIPlu9ZvMjiWZ/view?usp=drive_link
> Syzlang reproducer:
> https://drive.google.com/file/d/1eWSmwvNGOlZNU-0-xsKhUgZ4WG2VLZL5/view?usp=drive_link
> Similar report:
> https://groups.google.com/g/syzkaller-bugs/c/C2ud-S1Thh0/m/z4iI7l_dAgAJ
> 
> If you fix this issue, please add the following tag to the commit:
> Reported-by: Yikebaer Aizezi <yikebaer61@gmail.com>
> 
> kvm: vcpu 129: requested lapic timer restore with starting count
> register 0x390=4241646265 (4241646265 ns) > initial count (296265111
> ns). Using initial count to start timer.
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1977 at arch/x86/kvm/x86.c:11098
> kvm_arch_vcpu_ioctl_run+0x152f/0x1830 arch/x86/kvm/x86.c:11098

Well that's annoying.  The WARN is a sanity check that KVM doesn't somehow put
the guest into an uninitialized state while emulating the guest's APIC timer, but
I completely overlooked the fact that userspace can simply stuff the should-be-
impossible guest state. *sigh*

Sadly, I think the most reasonable thing to do is to simply drop the sanity check :-(

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0145d844283b..e9e262b244b8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11091,12 +11091,17 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
                        r = -EINTR;
                        goto out;
                }
+
                /*
-                * It should be impossible for the hypervisor timer to be in
-                * use before KVM has ever run the vCPU.
+                * Don't bother switching APIC timer emulation from the
+                * hypervisor timer to the software timer, the only way for the
+                * APIC timer to be active is if userspace stuffed vCPU state,
+                * i.e. put the vCPU and into a nonsensical state.  The only
+                * transition out of UNINITIALIZED (without more state stuffing
+                * from userspace) is an INIT, which will reset the local APIC
+                * and thus smother the timer anyways, i.e. APIC timer IRQs
+                * will be dropped no matter what.
                 */
-               WARN_ON_ONCE(kvm_lapic_hv_timer_in_use(vcpu));
-
                kvm_vcpu_srcu_read_unlock(vcpu);
                kvm_vcpu_block(vcpu);
                kvm_vcpu_srcu_read_lock(vcpu);

Re: WARNING in kvm_arch_vcpu_ioctl_run

[Yikebaer Aizezi]

Just patched it, after dropping the sanity check, I rerun the
reproduce program, and the crash was not triggered.
seems like the problem is fixed for now, Thanks

Sean Christopherson <seanjc@google.com> 于2023年8月4日周五 04:46写道：
>
> On Thu, Jul 27, 2023, Yikebaer Aizezi wrote:
> > Hello, I'm sorry for the mistake in my previous email. I forgot to add
> > a subject. This is my second attempt to send the message.
> >
> > When using Healer to fuzz the latest Linux kernel, the following crash
> > was triggered.
> >
> > HEAD commit: fdf0eaf11452d72945af31804e2a1048ee1b574c (tag: v6.5-rc2)
> >
> > git tree: upstream
> >
> > console output:
> > https://drive.google.com/file/d/1FiemC_AWRT-6EGscpQJZNzYhXZty6BVr/view?usp=drive_link
> > kernel config: https://drive.google.com/file/d/1fgPLKOw7QbKzhK6ya5KUyKyFhumQgunw/view?usp=drive_link
> > C reproducer: https://drive.google.com/file/d/1SiLpYTZ7Du39ubgf1k1BIPlu9ZvMjiWZ/view?usp=drive_link
> > Syzlang reproducer:
> > https://drive.google.com/file/d/1eWSmwvNGOlZNU-0-xsKhUgZ4WG2VLZL5/view?usp=drive_link
> > Similar report:
> > https://groups.google.com/g/syzkaller-bugs/c/C2ud-S1Thh0/m/z4iI7l_dAgAJ
> >
> > If you fix this issue, please add the following tag to the commit:
> > Reported-by: Yikebaer Aizezi <yikebaer61@gmail.com>
> >
> > kvm: vcpu 129: requested lapic timer restore with starting count
> > register 0x390=4241646265 (4241646265 ns) > initial count (296265111
> > ns). Using initial count to start timer.
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 1977 at arch/x86/kvm/x86.c:11098
> > kvm_arch_vcpu_ioctl_run+0x152f/0x1830 arch/x86/kvm/x86.c:11098
>
> Well that's annoying.  The WARN is a sanity check that KVM doesn't somehow put
> the guest into an uninitialized state while emulating the guest's APIC timer, but
> I completely overlooked the fact that userspace can simply stuff the should-be-
> impossible guest state. *sigh*
>
> Sadly, I think the most reasonable thing to do is to simply drop the sanity check :-(
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0145d844283b..e9e262b244b8 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -11091,12 +11091,17 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>                         r = -EINTR;
>                         goto out;
>                 }
> +
>                 /*
> -                * It should be impossible for the hypervisor timer to be in
> -                * use before KVM has ever run the vCPU.
> +                * Don't bother switching APIC timer emulation from the
> +                * hypervisor timer to the software timer, the only way for the
> +                * APIC timer to be active is if userspace stuffed vCPU state,
> +                * i.e. put the vCPU and into a nonsensical state.  The only
> +                * transition out of UNINITIALIZED (without more state stuffing
> +                * from userspace) is an INIT, which will reset the local APIC
> +                * and thus smother the timer anyways, i.e. APIC timer IRQs
> +                * will be dropped no matter what.
>                  */
> -               WARN_ON_ONCE(kvm_lapic_hv_timer_in_use(vcpu));
> -
>                 kvm_vcpu_srcu_read_unlock(vcpu);
>                 kvm_vcpu_block(vcpu);
>                 kvm_vcpu_srcu_read_lock(vcpu);
>