https://bugzilla.kernel.org/show_bug.cgi?id=198843 --- Comment #7 from Dr. David Alan Gilbert (dgilbert@xxxxxxxxxx) --- David: Are you sure this is the act of clearing VMXE that's the problem? My manual decode of the CR4 value (in my case 1626e0) was: 16 26 e0 0001 0110 | 0010 0110 | 1110 0000 5=PAE 6=MCE 7=Page global 9=FXSAVE/FXRSTOR OS support 10=OS support for unmasked SIMD FPE 13=VMX enable bit 17=PCID enable 18=XSAVE and Processor extended states-enable 20=SMEP so VMXe is 1 (that's the '2' in the 26 if I've got it right) and that's consistent between both the RAX and the reported CR4 value. I'm wondering if the problem is PCId (with no proof), I see in arch/x86/kvm/x86.c: if ((cr4 & X86_CR4_PCIDE) && !(old_cr4 & X86_CR4_PCIDE)) { if (!guest_cpuid_has(vcpu, X86_FEATURE_PCID)) return 1; /* PCID can not be enabled when cr3[11:0]!=000H or EFER.LMA=0 */ if ((kvm_read_cr3(vcpu) & X86_CR3_PCID_MASK) || !is_long_mode(vcpu)) return 1; } and the reported CR3 value is: 000000072320a006 so it does have those bits set (although I don't understand why old_cr4 didn't have it to trigger that check) -- You are receiving this mail because: You are watching the assignee of the bug.
