https://bugzilla.kernel.org/show_bug.cgi?id=216091 Bug ID: 216091 Summary: KVM nested virtualization does not support VMX fields that should always be supported Product: Virtualization Version: unspecified Kernel Version: 5.17.11-200.fc35.x86_64 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: kvm Assignee: virtualization_kvm@xxxxxxxxxxxxxxxxxxxx Reporter: ercli@xxxxxxxxxxx Regression: No Created attachment 301112 --> https://bugzilla.kernel.org/attachment.cgi?id=301112&action=edit Guest hypervisor to reproduce this bug (xz compressed) (4.img) CPU model: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz Host kernel version: 5.17.11-200.fc35.x86_64 Host kernel arch: x86_64 Guest: a hypervisor I wrote myself, 32-bits. Compressed and attached as 4.img.xz with this bug. Source code is in https://github.com/lxylxy123456/uberxmhf/tree/f779b4f5de519d2cc5397a2cee72d7fa7963348b QEMU command line: qemu-system-i386 -m 256M -cpu Haswell,vmx=yes -enable-kvm -serial stdio -drive media=disk,file=4.img,index=0 The problem does not go away if I use -machine kernel_irqchip=off. This problem cannot be tested using -accel tcg, because nested virtualization is not supported in TCG. How to reproduce: 1. Download 4.img.xz from this bug, decompress it to get 4.img. 2. Enter the QEMU command line above 3. Serial port is redirected to stdio. On serial port, see: VMREAD of 0x2000 gives 0x00000000 VMREAD of 0x200c fails (0xc) VMREAD of 0x4000 gives 0x00000000 VMREAD of 0x4828 fails (0xc) VMREAD of 0x6000 gives 0x00000000 VMREAD of 0x6008 fails (0xc) VMREAD of 0x600a fails (0xc) VMREAD of 0x600c fails (0xc) VMREAD of 0x600e fails (0xc) VMREAD of 0x6402 fails (0xc) VMREAD of 0x6404 fails (0xc) VMREAD of 0x6406 fails (0xc) VMREAD of 0x6408 fails (0xc) 4. The relevant source code that prints these messages is at https://github.com/lxylxy123456/uberxmhf/blob/f779b4f5de519d2cc5397a2cee72d7fa7963348b/xmhf/src/xmhf-core/xmhf-runtime/xmhf-startup/lhv-vmx.c#L20 5. This means that KVM does not support the following 10 fields: Encoding 0x200c: Executive-VMCS pointer Encoding 0x4828: Guest SMBASE Encoding 0x6008: CR3-target value 0 Encoding 0x600a: CR3-target value 1 Encoding 0x600c: CR3-target value 2 Encoding 0x600e: CR3-target value 3 Encoding 0x6402: I/O RCX Encoding 0x6404: I/O RSI Encoding 0x6406: I/O RDI Encoding 0x6408: I/O RIP Expected behavior: the VMCS fields listed above should be supported. The serial port should print: VMREAD of 0x2000 gives 0x00000000 VMREAD of 0x200c gives 0x00000000 VMREAD of 0x4000 gives 0x00000000 VMREAD of 0x4828 gives 0x00000000 VMREAD of 0x6000 gives 0x00000000 VMREAD of 0x6008 gives 0x00000000 VMREAD of 0x600a gives 0x00000000 VMREAD of 0x600c gives 0x00000000 VMREAD of 0x600e gives 0x00000000 VMREAD of 0x6402 gives 0x00000000 VMREAD of 0x6404 gives 0x00000000 VMREAD of 0x6406 gives 0x00000000 VMREAD of 0x6408 gives 0x00000000 Explanation: Intel's SDM lists all VMCS field name, encoding, and existence information in appendix C. For example, if a field is not supported in some CPUs, then SDM writes: > Field Name Index Encoding > VMX-preemption timer value[1] 000010111B 0000482EH > NOTES: > 1. This field exists only on processors that support the 1-setting of the > "activate VMX-preemption timer" VM-execution control. However, for the 10 fields above, SDM implies that these fields should always exist. For example: > Field Name Index Encoding > CR3-target value 0 000000100B 00006008H > CR3-target value 1 000000101B 0000600AH > CR3-target value 2 000000110B 0000600CH > CR3-target value 3[1] 000000111B 0000600EH > NOTES: > 1. If a future implementation supports more than 4 CR3-target values, they > will be encoded consecutively following the 4 encodings given here. Thus, according to SDM I believe the 10 fields should always exist. Using CR3-target value as an example, I think KVM can say that number of CR3-target values supported by the processor is 0 by setting the IA32_VMX_MISC MSR. However, the 4 VMCS fields CR3-target value 0 - 3 should still exist. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
