[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH 00/13] Nested Virtualization: Overview



Christoph Egger wrote:
> Hi!
> 
> This patch series brings Nested Virtualization to Xen.
> This is the sixth patch series. Improvements to the
> previous patch submission:
> 
> - Move GIF definition into SVM
> - Move VMEXIT emulation into SVM
> - Introduce hooks for getting host/guest cr3 for use with hap-on-hap
>    per proposal from Eddie Dong
> - Moved fields from struct nestedhvm into SVM
> - Renamed struct nestedhvm to struct nestedvcpu
> - Reworked VMRUN and VMEXIT emulation. It uses a defered emulation
>    mechanism that makes interrupt handling more efficient and is
>    closer to what VMX is doing
> - VMCB is peristent mapped. Only remap the VMCB when l1 guest
>    changes the address.
> 
> 
> The patch series:
> 
> patch 01: add nestedhvm guest config option to the tools.
>                   This is the only one patch touching the tools
> patch 02: Add data structures for nested virtualization.
> patch 03: add nestedhvm function hooks.
> patch 04: The heart of nested virtualization.
> patch 05: Allow switch to paged real mode during vmrun emulation.
>                   Emulate cr0 and cr4 when guest does not intercept
>                   them (i.e. Hyper-V/Windows7, KVM)
> patch 06: When injecting an exception into nested guest, inject
>                   #VMEXIT into the guest if intercepted.
> patch 07: Allow guest to enable SVM in EFER only on AMD.
> patch 08: Handle interrupts (generic part).
> patch 09: SVM specific implementation for nested virtualization.
> patch 10: Handle interrupts (SVM specific).
> patch 11: The piece of code that effectively turns on nested
> virtualization. patch 12: Move dirty_vram from struct hvm_domain to
>                   struct p2m_domain. This change is the first part
>                   from a larger not-yet-ready change where the vram
>                   and log_dirty tracking is teached to work on per
> p2m. 
> patch 13: Handle nested pagefault to enable hap-on-hap and handle
>                   nested guest page-table-walks to emulate
>                   instructions the guest does not intercept (i.e.
> WBINVD with Windows 7). 

Thanks for the progress! 
I am fine with the patch series in general .

Some minor comments here:

+enum nestedhvm_intercepts {
+       /* exitinfo1 and exitinfo2 undefined */
+       NESTEDHVM_INTERCEPT_INVALID = 0, /* INVALID vmcb/vmcs */
+       NESTEDHVM_INTERCEPT_SHUTDOWN = 1, /* kill guest */
+       NESTEDHVM_INTERCEPT_MCE = 2, /* machine check exception */
+       NESTEDHVM_INTERCEPT_VMMCALL = 3, /* VMMCALL/VMCALL */
+
+       /* exitinfo1 is hvm_intsrc_*, exitinfo2 is the vector */
+       NESTEDHVM_INTERCEPT_INTR = 4, /* interrupt exit code */
+       NESTEDHVM_INTERCEPT_NMI = 5, /* NMI exit code */
+
+       /* exitinfo1 is PF error code, exitinfo2 is PF fault address */
+       NESTEDHVM_INTERCEPT_NPF = 6, /* nested page fault */
+       NESTEDHVM_INTERCEPT_PF = 7, /* page fault */
+
+       /* exceptions: exitinfo1 and exitinfo2 are undefined */
+       NESTEDHVM_INTERCEPT_NM = 8, /* device-not-available */
+
+       /* end mark */
+       NESTEDHVM_INTERCEPT_LAST,
+};

I didn't see where it is used. Did I miss something?


+    union {
+        uint32_t bytes;
+        struct {
+            uint32_t vmentry_pending: 1;
+            uint32_t vmexit_pending: 1;
+            uint32_t vmswitch_in_progress: 1; /* true during vmentry/vmexit 
emulation */
+            uint32_t reserved : 29;
+        } fields;
+    } nv_hostflags;

I feel it is unnecessary to use tricky bit definition (slow and readers may 
think it has some relationship w/ hardware field). Using a simple byte variable 
for each field seems more simple to me.


Both nhvm & nestedhvm is used in API names, what is the policy?

Thx, Eddie


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.