[Bug 216091] New: KVM nested virtualization does not support VMX fields that should always be supported

[Bug 216091] New: KVM nested virtualization does not support VMX fields that should always be supported

[bugzilla-daemon]

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@kernel-bugs.osdl.org
          Reporter: ercli@ucdavis.edu
        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.

[Bug 216091] KVM nested virtualization does not support VMX fields that should always be supported

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216091

Sean Christopherson (seanjc@google.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seanjc@google.com

--- Comment #1 from Sean Christopherson (seanjc@google.com) ---
The CR3-target values are clear cut, "A.6 MISCELLANEOUS DATA" in the SDM
explicitly calls out '0' as a legal value for the number of CR3-target values:

  Bits 24:16 indicate the number of CR3-target values supported by the
processor.
  This number is a value between 0 and 256, inclusive (bit 24 is set if and
only
  if bits 23:16 are clear).

For the other fields ("Executive-VMCS pointer", "Guest SMBASE", and "I/O R*X",
I would argue that the lack of a footnote is an SDM bug, as those fields should
exist if and only if the CPU enumerates support for an SMM-transfer monitor in
MSR_IA32_VMX_BASIC, and KVM never sets that bit (49).  The I/O fields "are used
only for VM exits due to SMIs ...", and SMIs are not true VM-Exits when not
using STM.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.