On Tue, 2018-04-17, Zdenek Kaspar wrote: > Hello, I did quick test with latest stable kernel (4.16.2) and got tons > of vmwrite errors immediately when starting VM: > > Apr 17 08:22:05 192.168.1.4 merkur kernel: vmwrite error: reg 401e value > 2021 (err 12) > Apr 17 08:22:05 192.168.1.4 merkur kernel: CPU: 0 PID: 1876 Comm: > qemu-test4 Not tainted 4.16.2-1-core2 #1 > Apr 17 08:22:05 192.168.1.4 merkur kernel: Hardware name: /DG35EC, BIOS > ECG3510M.86A.0118.2010.0113.1426 01/13/2010 > Apr 17 08:22:05 192.168.1.4 merkur kernel: Call Trace: > Apr 17 08:22:05 192.168.1.4 merkur kernel: dump_stack+0x5c/0x82 > Apr 17 08:22:05 192.168.1.4 merkur kernel: vmx_set_cr4+0x1ca/0x200 > [kvm_intel] > Apr 17 08:22:05 192.168.1.4 merkur kernel: vmx_vcpu_reset+0x320/0x660 > [kvm_intel] > Apr 17 08:22:05 192.168.1.4 merkur kernel: kvm_vcpu_reset+0x1f6/0x300 [kvm] > Apr 17 08:22:05 192.168.1.4 merkur kernel: ? vcpu_load+0x1f/0x30 [kvm] > Apr 17 08:22:05 192.168.1.4 merkur kernel: kvm_arch_vcpu_setup+0x1b/0x30 > [kvm] > Apr 17 08:22:05 192.168.1.4 merkur kernel: kvm_vm_ioctl+0x1ea/0x750 [kvm] > Apr 17 08:22:05 192.168.1.4 merkur kernel: do_vfs_ioctl+0x8b/0x5e0 > Apr 17 08:22:05 192.168.1.4 merkur kernel: SyS_ioctl+0x36/0x70 > Apr 17 08:22:05 192.168.1.4 merkur kernel: do_syscall_64+0x6a/0x2f0 > Apr 17 08:22:05 192.168.1.4 merkur kernel: ? __switch_to+0x11b/0x340 > Apr 17 08:22:05 192.168.1.4 merkur kernel: > entry_SYSCALL_64_after_hwframe+0x3d/0xa2 > Apr 17 08:22:05 192.168.1.4 merkur kernel: RIP: 0033:0x7f56ccd0fb77 > Apr 17 08:22:05 192.168.1.4 merkur kernel: RSP: 002b:00007f56c8df4988 > EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > Apr 17 08:22:05 192.168.1.4 merkur kernel: RAX: ffffffffffffffda RBX: > 000000000000ae41 RCX: 00007f56ccd0fb77 > Apr 17 08:22:05 192.168.1.4 merkur kernel: RDX: 0000000000000001 RSI: > 000000000000ae41 RDI: 000000000000000e > Apr 17 08:22:05 192.168.1.4 merkur kernel: RBP: 0000000000000001 R08: > 0000556e8e5ed600 R09: 0000556e907fa5f0 > Apr 17 08:22:05 192.168.1.4 merkur kernel: R10: 0000556e8ebc7620 R11: > 0000000000000246 R12: 0000556e9076f540 > Apr 17 08:22:05 192.168.1.4 merkur kernel: R13: 00007f56c8df59c0 R14: > 0000000000000000 R15: 0000000000000003 > > model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid > aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm > lahf_lm pti tpr_shadow dtherm > > 4.15.17 works fine, it seems already reported here: > https://bugzilla.redhat.com/show_bug.cgi?id=1566258 Code related to UMIP emulation is effectively doing an unconditional RMW on SECONDARY_VM_EXEC_CONTROL, which isn't guaranteed to exist on older processors. KVM already ensures it only advertises UMIP (via emulation) when SECONDARY_EXEC_DESC can be set, i.e. KVM is already implicitly checking for SECONDARY_VM_EXEC_CONTROL, so fixing the bug is just a matter of omitting the unneeded VMREAD/VMWRITE sequence. > Z. >
