From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: VMX ideas Date: Sun, 02 Nov 2008 12:26:00 +0200 Message-ID: <490D8038.8040109@redhat.com> References: <687FC948-DBF4-4A7C-AD14-F6DB53A092D6@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list To: Alexander Graf Return-path: Received: from mx2.redhat.com ([66.187.237.31]:47697 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753240AbYKBK0F (ORCPT ); Sun, 2 Nov 2008 05:26:05 -0500 In-Reply-To: <687FC948-DBF4-4A7C-AD14-F6DB53A092D6@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: > Hi list, > > I really do like KVM and would love to make using it a complete > no-brainer user experience. For the average user, loading a kernel > module (and unloading it) isn't really one of the most common tasks. > > So I was considering to automatically load kvm-intel and kvm-amd on > bootup, when the CPU has a CPUID flag. Unfortunately it doesn't work > that easily. VMX enters Root mode, setting a page to use for the VMCS. > KVM sets up this page when the kvm-intel module gets loaded. This > means, as soon as kvm-intel is modprobe'd, vmware, virtual box, > parallels and the like are screwed. > From a distribution perspective, this isn't exactly an ideal situation. > > So I was thinking hard on what to do to circumvent this problem and > came up with several approaches: > > 1. Export some functions that could be used by 3rd party hypervisors > to "occupy" the VMCS region > > This would mean, that the others' kernel modules have dependencies on > KVM. I don't think that's really desirable. Furthermore it wouldn't > work with kvm compiled as external module. > > > 2. Create a root mode base framework > > This is the Mac OS X approach. They have a small piece of code in the > kernel, that sets up the root mode, handles suspend/resume and > maintains a ref counter on its usage. Since the root mode is set on > bootup, all hypervisors would need to make use of that framework. > > While I like that approach for its simplicity, it does not allow for > parallel execution of VMs with different hypervisors. Is this a real > problem? > > > 3. Create a root mode bloat framework > > Taking approach 2. we could also export functions to handle VPID > management and VMXPTRLD, which would make it possible for multiple > hypervisors to run concurrently. This is the most elegant approach > IMHO, but also needs the most maintenance, as new revisions of VMX > could possibly break the whole concept. > > > I started working on 2. and wanted to put in some parts of 3., > realizing that it's more work and code change than I'd like. Any > comments on these ideas? I'd really love to have KVM always loaded > somehow. I like 2 as well. We already started moving in this direction in order to get kexec working well with kvm. Please copy virtualization@lists.linux-foundation.org and zach@vmware.com to get feedback. (on the distro I use (F9), kvm is auto-loaded. or did I change some config script and forget?) -- error compiling committee.c: too many arguments to function