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/
Home Products Support Community News


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

To: Christoph Egger <Christoph.Egger@xxxxxxx>
Subject: [Xen-devel] RE: [PATCH 00/13] Nested Virtualization: Overview
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Thu, 9 Sep 2010 09:45:55 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Tim, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Deegan <Tim.Deegan@xxxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Wed, 08 Sep 2010 18:51:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201009081735.35496.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: <201009011653.27082.Christoph.Egger@xxxxxxx> <201009071749.23010.Christoph.Egger@xxxxxxx> <1A42CE6F5F474C41B63392A5F80372B22A825E34@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <201009081735.35496.Christoph.Egger@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActPa66yNS6DQ+2JQeGGhSeGJPxLfQAUCPiQ
Thread-topic: [PATCH 00/13] Nested Virtualization: Overview
Well, so you decide to cycle here, though it obviously not only hurt Intel but 
also AMD's progress.

Let me ask several questions first:
1: Does this heavy weight wrapper a must for nested virtualization?
2: What is the gain and lose?
3: How single layer virtualization does? Are they abstracting with heavy weight 
wrapper or light weight and why? Particularly do they abstract the 1st level VM 
exit/entry event or do they invent 3rd name space for VMCS/VMCB field?

The only reason I can see so far is that you called out the "abstract" in 
nested virtualization side, that is for some reason we have to appreciate but 
not enough for us to swallow the side effect of its impact to future nested VMX 

Taking your "car" abstract as example, 

> All cars are different but they all have three pedals and a steering wheel.
Well, automatic cars have 2 pedals only (but I know most German cars are 
mechanical car for green fuel reason which does have 3 pedals.
Steering wheel is current implementation, but there are researches inventing 
automatic controlled cars that is fully controlled by computer, and I am not 
sure if trolley car is a car? If it is, it can work without steering wheel 
though it may have today. 

Above comments doesn;t mean I against your abstract of "car with 3 pedals and a 
steering wheeling" even it may be not accurate enough. But it does reflect the 
trade off between innovation and industry standardization. W/o 
standaradization, there are many variants coming in to compete in different 
area, but once a standardization comes, the innovation is deprioritized, rather 
other competition comes such as price. Hardly we can see if we need innovation 
more (no standardization) or cost saving more. But at very beginning of a new 
product/feature, I think innovation is more important to allow different 
variants to compete. 

Taking software or nested virtualization as example, defining those wrappers or 
abstract to force each vendor to follow does deprioritize innovation, but they 
may be easier for followers to understand easily if they doesn't understand 
SVM/VMX itself very well. However, as I said, nested virtualization is still at 
its very beginning and we need innovation more to find what is the best 
solution especially from performance point of view. Otherwise re-abstract does 
require double effort for VMX developers to consider SVM support as well (and 
even more than double effort because normally Intel VMX developers doesn't know 
SVM architecture very well and we don't have test machine for SVM).

Anyway, the ball is in your side.

Thx, Eddie

Xen-devel mailing list