On Wed, Sep 22, 2010 at 02:04:38AM +0200, Nadav Har'El wrote: > Hi, thanks for the summary. > I also listened-in on the call. I'm glad these issues are being discussed. > > On Tue, Sep 21, 2010, Chris Wright wrote about "KVM call minutes for Sept 21": > > Nested VMX > > - looking for forward progress and better collaboration between the > > Intel and IBM teams > > I'll be very happy if anyone, be it from Intel or somewhere else, would like > to help me work on nested VMX. > > Somebody (I don't recognize your voices yet, sorry...) mentioned on the call > that there might not be much point in cooperation before I finish getting > nested VMX merged into KVM. I agree, but my conclusion is different that what > I think the speaker implied: My conclusion is that it is important that we > merge the nested VMX code into KVM as soon as possible, because if nested VMX > is part of KVM (and not a set of patches which becomes stale the moment after > I release it) this will make it much easier for people to test it, use it, > and cooperate in developing it. > > > - needs more review (not a new issue) > > I think the reviews that nested VMX has received over the past year (thanks > to Avi Kivity, Gleb Natapov, Eddie Dong and sometimes others), have been > fantastic. You guys have shown deep understanding of the code, and found > numerous bugs, oversights, missing features, and also a fair share of ugly > code, and we (first Orit and Abel, and then I) have done are best to fix all > of these issues. I've personally learned a lot from the latest round of > reviews, and the discussions with you. > > So I don't think there has been any lack of reviews. I don't think that > getting more reviews is the most important task ahead of us. > > Surely, if more people review the code, more potential bugs will be spotted. > But this is always the case, with any software. I think the question now > is, what would it take to finally declare the code as "good enough to be > merged", with the understanding that even after being merged it will still be > considered an experimental feature, disabled by default and documented as > experimental. Nested SVM was also merged before it was perfect, and also > KVM itself was released before being perfect :-) > There is only one outstanding serious issue from my point of view: event injection path. I want it to be similar to how nested SVM handles it. I don't see why it can't be done the same way for VMX too. The way nested SVM does it looks cleaner and making code paths similar will allow us to consolidate the logic in common code later. This issue is too fundamental to be fixed after merge IMHO. Other nitpicks about missing checks that real HW does, but emulation doesn't can be fixed any time after merge. > > - use cases > > I don't kid myself that as soon as nested VMX is available in KVM, millions > of users worldwide will flock to use it. Definitely, many KVM users will never > find a need for nested virtualization. But I do believe that there are many > use cases. We outlined some of them in our paper (to be presented in a couple > of weeks in OSDI): > > 1. Hosting one of the new breed of operating systems which have a hypervisor > as part of them. Windows 7 with XP mode is one example. Linux with KVM > is another. > > 2. Platforms with embedded hypervisors in firmware need nested virt to > run any workload - which can itself be a hypervisor with guests. > > 3. Clouds users could put in their virtual machine a hypervisor with > sub-guests, and run multiple virtual machines on the one virtual machine > which they get. > > 4. Enable live migration of entire hypervisors with their guests - for > load balancing, disaster recovery, and so on. > > 5. Honeypots and protection against hypervisor-level rootkits > > 6. Make it easier to test, demonstrate, benchmark and debug hypervisors, > and also entire virtualization setups. An entire virtualization setup > (hypervisor and all its guests) could be run as one virtual machine, > allowing testing many such setups on one physical machine. > > By the way, I find the question of "why do we need nested VMX" a bit odd, > seeing that KVM already supports nested virtualization (for SVM). Is it the > case that nested virtualization was found useful on AMD processors, but for > Intel processors, it isn't? Of course not :-) I think KVM should support > nested virtualization on neither architecture, or on both - and of course > I think it should be on both :-) I think the question was "why do we need nested virtualization" ;) -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
