[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |