WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 00/13] Nested Virtualization: Overview
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Mon, 22 Nov 2010 14:55:04 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Sun, 21 Nov 2010 23:00:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201011121939.17994.Christoph.Egger@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <201011121939.17994.Christoph.Egger@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcuCmnefQJ7NZsdAQKKSgU4zEk9YFAHdcpug
Thread-topic: [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

<Prev in Thread] Current Thread [Next in Thread>