From: Avi Kivity <avi@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: KVM list <kvm@vger.kernel.org>
Subject: Re: VMX ideas
Date: Sun, 02 Nov 2008 12:26:00 +0200 [thread overview]
Message-ID: <490D8038.8040109@redhat.com> (raw)
In-Reply-To: <687FC948-DBF4-4A7C-AD14-F6DB53A092D6@suse.de>
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
next prev parent reply other threads:[~2008-11-02 10:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-29 14:52 VMX ideas Alexander Graf
2008-10-29 15:01 ` Joerg Roedel
2008-10-29 15:11 ` Alexander Graf
2008-10-29 15:36 ` Gerd Hoffmann
2008-10-29 15:45 ` Anthony Liguori
2008-10-29 17:15 ` Alexander Graf
2008-10-29 17:18 ` Alexander Graf
2008-11-02 10:28 ` Avi Kivity
2008-11-03 7:32 ` Alexander Graf
2008-11-02 10:26 ` Avi Kivity [this message]
2008-11-02 16:11 ` Daniel P. Berrange
2008-11-02 16:15 ` Avi Kivity
2008-11-02 16:18 ` Avi Kivity
2008-11-02 23:36 ` Glauber Costa
2008-11-03 7:24 ` Alexander Graf
2008-11-03 10:26 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=490D8038.8040109@redhat.com \
--to=avi@redhat.com \
--cc=agraf@suse.de \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.