xen-devel
[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
development.
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] [PATCH 00/13] Nested Virtualization: Overview, Christoph Egger
- [Xen-devel] RE: [PATCH 00/13] Nested Virtualization: Overview, Dong, Eddie
- [Xen-devel] Re: [PATCH 00/13] Nested Virtualization: Overview, Christoph Egger
- [Xen-devel] RE: [PATCH 00/13] Nested Virtualization: Overview, Dong, Eddie
- [Xen-devel] Re: [PATCH 00/13] Nested Virtualization: Overview, Christoph Egger
- [Xen-devel] RE: [PATCH 00/13] Nested Virtualization: Overview, Dong, Eddie
- [Xen-devel] Re: [PATCH 00/13] Nested Virtualization: Overview, Christoph Egger
- [Xen-devel] RE: [PATCH 00/13] Nested Virtualization: Overview, Dong, Eddie
- [Xen-devel] Re: [PATCH 00/13] Nested Virtualization: Overview, Christoph Egger
- [Xen-devel] RE: [PATCH 00/13] Nested Virtualization: Overview,
Dong, Eddie <=
- [Xen-devel] Re: [PATCH 00/13] Nested Virtualization: Overview, Christoph Egger
[Xen-devel] Re: [PATCH 00/13] Nested Virtualization: Overview, Tim Deegan
|
|
|