* WARNING in kvm_arch_vcpu_ioctl_run @ 2023-07-27 8:03 Yikebaer Aizezi 2023-08-03 20:46 ` Sean Christopherson 0 siblings, 1 reply; 4+ messages in thread From: Yikebaer Aizezi @ 2023-07-27 8:03 UTC (permalink / raw) To: seanjc, pbonzini, tglx, mingo, bp, dave.hansen, x86, hpa, jarkko, kvm, linux-kernel, linux-sgx 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.. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: WARNING in kvm_arch_vcpu_ioctl_run 2023-07-27 8:03 WARNING in kvm_arch_vcpu_ioctl_run Yikebaer Aizezi @ 2023-08-03 20:46 ` Sean Christopherson 2023-08-04 2:35 ` Yikebaer Aizezi 0 siblings, 1 reply; 4+ messages in thread From: Sean Christopherson @ 2023-08-03 20:46 UTC (permalink / raw) To: Yikebaer Aizezi Cc: pbonzini, tglx, mingo, bp, dave.hansen, x86, hpa, jarkko, kvm, linux-kernel, linux-sgx 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); ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: WARNING in kvm_arch_vcpu_ioctl_run 2023-08-03 20:46 ` Sean Christopherson @ 2023-08-04 2:35 ` Yikebaer Aizezi 0 siblings, 0 replies; 4+ messages in thread From: Yikebaer Aizezi @ 2023-08-04 2:35 UTC (permalink / raw) To: Sean Christopherson Cc: pbonzini, tglx, mingo, bp, dave.hansen, x86, hpa, jarkko, kvm, linux-kernel, linux-sgx 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); > ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <0a42f824d24946ab86bcc6efa31b2863@huawei.com>]
* Re: WARNING in kvm_arch_vcpu_ioctl_run [not found] <0a42f824d24946ab86bcc6efa31b2863@huawei.com> @ 2023-03-16 19:17 ` Sean Christopherson 0 siblings, 0 replies; 4+ messages in thread From: Sean Christopherson @ 2023-03-16 19:17 UTC (permalink / raw) To: zhangjianguo (A) Cc: pbonzini@redhat.com, kvm@vger.kernel.org, Renxuming, Wangyuan (Ethan), Ligang (J), yuzenghui, linux-kernel +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) { ^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-08-04 2:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-27 8:03 WARNING in kvm_arch_vcpu_ioctl_run Yikebaer Aizezi
2023-08-03 20:46 ` Sean Christopherson
2023-08-04 2:35 ` Yikebaer Aizezi
[not found] <0a42f824d24946ab86bcc6efa31b2863@huawei.com>
2023-03-16 19:17 ` Sean Christopherson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox