Changeset 80816 in vbox for trunk/src

Timestamp:

Sep 16, 2019 9:23:56 AM (5 years ago)

Author:

vboxsync

Message:

VMM/IEM: "guest hypervisor" -> "nested hypervisor".

Location:

trunk/src/VBox/VMM/VMMAll

Files:

• IEMAllCImplSvmInstr.cpp.h (modified) (1 diff)
• IEMAllCImplVmxInstr.cpp.h (modified) (8 diffs)

trunk/src/VBox/VMM/VMMAll/IEMAllCImplSvmInstr.cpp.h

@@ -1061 +1061 @@
     {
         /*
-         * This shouldn't happen, but if it does, cause a #VMEXIT and let the "host" (guest hypervisor) deal with it.
+         * This shouldn't happen, but if it does, cause a #VMEXIT and let the "host" (nested hypervisor) deal with it.
          */
         Log(("iemSvmHandleMsrIntercept: Invalid/out-of-range MSR %#RX32 fWrite=%RTbool -> #VMEXIT\n", idMsr, fWrite));

trunk/src/VBox/VMM/VMMAll/IEMAllCImplVmxInstr.cpp.h

@@ -1592 +1592 @@
 
     /*
-     * Optimization if the guest hypervisor is using the same guest-physical page for both
+     * Optimization if the nested hypervisor is using the same guest-physical page for both
      * the VM-entry MSR-load area as well as the VM-exit MSR store area.
      */
@@ -1630 +1630 @@
             /*
              * If we're in ring-0, we cannot handle returns to ring-3 at this point and continue VM-exit.
-             * If any guest hypervisor loads MSRs that require ring-3 handling, we cause a VMX-abort
+             * If any nested hypervisor loads MSRs that require ring-3 handling, we cause a VMX-abort
              * recording the MSR index in the auxiliary info. field and indicated further by our
              * own, specific diagnostic code. Later, we can try implement handling of the MSR in ring-0
@@ -1990 +1990 @@
                 /*
                  * If we're in ring-0, we cannot handle returns to ring-3 at this point and continue VM-exit.
-                 * If any guest hypervisor loads MSRs that require ring-3 handling, we cause a VMX-abort
+                 * If any nested hypervisor loads MSRs that require ring-3 handling, we cause a VMX-abort
                  * recording the MSR index in the auxiliary info. field and indicated further by our
                  * own, specific diagnostic code. Later, we can try implement handling of the MSR in ring-0
@@ -6407 +6407 @@
         /** @todo r=ramshankar: This is done primarily to simplify recursion scenarios while
          *        redirecting accesses between the APIC-access page and the virtual-APIC
-         *        page. If any guest hypervisor requires this, we can implement it later. */
+         *        page. If any nested hypervisor requires this, we can implement it later. */
         if (pVmcs->u32ProcCtls & VMX_PROC_CTLS_USE_TPR_SHADOW)
         {
@@ -6756 +6756 @@
                 /*
                  * If we're in ring-0, we cannot handle returns to ring-3 at this point and continue VM-entry.
-                 * If any guest hypervisor loads MSRs that require ring-3 handling, we cause a VM-entry failure
+                 * If any nested hypervisor loads MSRs that require ring-3 handling, we cause a VM-entry failure
                  * recording the MSR index in the Exit qualification (as per the Intel spec.) and indicated
                  * further by our own, specific diagnostic code. Later, we can try implement handling of the
@@ -7171 +7171 @@
     /*
      * Any VMCS field which we do not establish on every VM-exit but may potentially
-     * be used on the VM-exit path of a guest hypervisor -and- is not explicitly
+     * be used on the VM-exit path of a nested hypervisor -and- is not explicitly
      * specified to be undefined needs to be initialized here.
      *
@@ -7322 +7322 @@
      * We are allowed to cache VMCS related data structures (such as I/O bitmaps, MSR bitmaps)
      * while entering VMX non-root mode. We do some of this while checking VM-execution
-     * controls. The guest hypervisor should not make assumptions and cannot expect
+     * controls. The nested hypervisor should not make assumptions and cannot expect
      * predictable behavior if changes to these structures are made in guest memory while
      * executing in VMX non-root mode. As far as VirtualBox is concerned, the guest cannot
@@ -7426 +7426 @@
 
                                 /*
-                                 * Inject any event that the guest hypervisor wants to inject.
+                                 * Inject any event that the nested hypervisor wants to inject.
                                  * Note! We cannot immediately perform the event injection here as we may have
                                  *       pending PGM operations to perform due to switching page tables and/or