From: Ingo Molnar <mingo@elte.hu>
To: Gerd Hoffmann <kraxel@suse.de>
Cc: virtualization <virtualization@lists.osdl.org>,
Jan Beulich <jbeulich@novell.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, Roland McGrath <roland@redhat.com>
Subject: Re: Xen & VMI?
Date: Tue, 6 Mar 2007 11:26:59 +0100 [thread overview]
Message-ID: <20070306102658.GA7478@elte.hu> (raw)
In-Reply-To: <45ED3F29.6000705@suse.de>
* Gerd Hoffmann <kraxel@suse.de> wrote:
> > cleanliness and performance: KVM doesnt need any artificial
> > indirection.
>
> Xen doesn't need it either.
>
> > IMO the GPL-ed ROM portion of VMI was a bad idea to begin with.
>
> So why do you want xen use vmi then?
due to the other argument i listed:
|| Also, lguest and KVM is Linux-internal, so there's a natural match
|| between the guest and the host APIs.
It's a basic kernel maintainance issue: lguest/KVM and Linux host and
guest will co-evolve foward in a natural way as they are in essence
Linux-internal technologies. They /will/ harmonize. There is no such
guarantee with Xen/VMWare/etc. (which are distinctly separate
technologies) - so any ABIs towards them could become (and are already
becoming) a drag and distraction.
> > well, the VMI patches got into Linux with the claim that it's also
> > useful for Xen. So that claim was ... not actually true?
>
> As mentioned there was a proof-of-concept VMI ROM done by vmware. As
> far I know it translated the VMI ROM interface calls into xen
> hypercalls somehow, Zach probably has more details.
>
> So in the end you would still have two different hypervisor ABI's, the
> VMI ROM just hides that.
oh, but that way i have cleverly pushed the problem out of Linux and
into the VMI-ROM's domain ;) Which is all i care about.
really, one of my jobs as a maintainer is to keep crap out of Linux (we
are capable of adding enough crap ourselves ;-). Having multiple,
overlapping, technologically redundant ABIs between /software/, embedded
into the heart of the kernel (paravirt ops nonwithstanding), for
perpetuity, is one such type of crap. It is in fact the kind of crap i'm
/most/ worried about, because it sticks forever.
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Gerd Hoffmann <kraxel@suse.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
virtualization <virtualization@lists.osdl.org>,
Jan Beulich <jbeulich@novell.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Roland McGrath <roland@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Xen & VMI?
Date: Tue, 6 Mar 2007 11:26:59 +0100 [thread overview]
Message-ID: <20070306102658.GA7478@elte.hu> (raw)
In-Reply-To: <45ED3F29.6000705@suse.de>
* Gerd Hoffmann <kraxel@suse.de> wrote:
> > cleanliness and performance: KVM doesnt need any artificial
> > indirection.
>
> Xen doesn't need it either.
>
> > IMO the GPL-ed ROM portion of VMI was a bad idea to begin with.
>
> So why do you want xen use vmi then?
due to the other argument i listed:
|| Also, lguest and KVM is Linux-internal, so there's a natural match
|| between the guest and the host APIs.
It's a basic kernel maintainance issue: lguest/KVM and Linux host and
guest will co-evolve foward in a natural way as they are in essence
Linux-internal technologies. They /will/ harmonize. There is no such
guarantee with Xen/VMWare/etc. (which are distinctly separate
technologies) - so any ABIs towards them could become (and are already
becoming) a drag and distraction.
> > well, the VMI patches got into Linux with the claim that it's also
> > useful for Xen. So that claim was ... not actually true?
>
> As mentioned there was a proof-of-concept VMI ROM done by vmware. As
> far I know it translated the VMI ROM interface calls into xen
> hypercalls somehow, Zach probably has more details.
>
> So in the end you would still have two different hypervisor ABI's, the
> VMI ROM just hides that.
oh, but that way i have cleverly pushed the problem out of Linux and
into the VMI-ROM's domain ;) Which is all i care about.
really, one of my jobs as a maintainer is to keep crap out of Linux (we
are capable of adding enough crap ourselves ;-). Having multiple,
overlapping, technologically redundant ABIs between /software/, embedded
into the heart of the kernel (paravirt ops nonwithstanding), for
perpetuity, is one such type of crap. It is in fact the kind of crap i'm
/most/ worried about, because it sticks forever.
Ingo
next prev parent reply other threads:[~2007-03-06 10:26 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-05 12:06 [patch] paravirt: VDSO page is essential Ingo Molnar
2007-03-05 12:36 ` Avi Kivity
2007-03-05 12:40 ` Ingo Molnar
2007-03-05 13:00 ` Avi Kivity
2007-03-05 13:32 ` Rusty Russell
2007-03-05 14:28 ` Andi Kleen
2007-03-05 13:48 ` Ingo Molnar
2007-03-05 14:58 ` Andi Kleen
2007-03-05 13:59 ` Ingo Molnar
2007-03-05 14:10 ` Avi Kivity
2007-03-05 14:10 ` Ingo Molnar
2007-03-05 13:28 ` Rusty Russell
2007-03-05 13:38 ` Ingo Molnar
2007-03-05 14:34 ` Andi Kleen
2007-03-05 13:46 ` [patch] paravirt: re-enable COMPAT_VDSO Ingo Molnar
2007-03-05 13:48 ` [patch] paravirt: VDSO page is essential Ingo Molnar
2007-03-05 20:11 ` Zachary Amsden
2007-03-05 20:11 ` Zachary Amsden
2007-03-05 20:16 ` Andi Kleen
2007-03-05 20:33 ` Zachary Amsden
2007-03-05 20:19 ` Ingo Molnar
2007-03-05 20:19 ` Ingo Molnar
2007-03-05 20:42 ` Zachary Amsden
2007-03-05 20:42 ` Zachary Amsden
2007-03-06 0:57 ` Rusty Russell
2007-03-06 1:03 ` Zachary Amsden
2007-03-06 1:11 ` Rusty Russell
2007-03-06 1:11 ` Rusty Russell
2007-03-06 1:14 ` Jeremy Fitzhardinge
2007-03-06 1:51 ` Zachary Amsden
2007-03-06 1:53 ` Jeremy Fitzhardinge
2007-03-06 1:53 ` Jeremy Fitzhardinge
2007-03-06 8:19 ` Xen & VMI? Ingo Molnar
2007-03-06 8:19 ` Ingo Molnar
2007-03-06 8:37 ` Gerd Hoffmann
2007-03-06 8:48 ` Zachary Amsden
2007-03-06 8:52 ` Ingo Molnar
2007-03-06 8:52 ` Ingo Molnar
2007-03-06 9:03 ` Zachary Amsden
2007-03-06 9:03 ` Zachary Amsden
2007-03-06 9:10 ` Ingo Molnar
2007-03-06 9:10 ` Ingo Molnar
2007-03-06 9:15 ` Gerd Hoffmann
2007-03-06 9:15 ` Gerd Hoffmann
2007-03-06 9:34 ` Ingo Molnar
2007-03-06 10:15 ` Gerd Hoffmann
2007-03-06 10:15 ` Gerd Hoffmann
2007-03-06 10:26 ` Ingo Molnar [this message]
2007-03-06 10:26 ` Ingo Molnar
2007-03-06 11:04 ` Gerd Hoffmann
2007-03-06 11:59 ` Ingo Molnar
2007-03-06 12:34 ` Gerd Hoffmann
2007-03-06 15:03 ` Anthony Liguori
2007-03-06 15:03 ` Anthony Liguori
2007-03-06 17:17 ` Nakajima, Jun
2007-03-06 17:17 ` Nakajima, Jun
2007-03-06 17:32 ` Anthony Liguori
2007-03-06 20:37 ` Ingo Molnar
2007-03-06 21:02 ` Jeremy Fitzhardinge
2007-03-06 21:02 ` Jeremy Fitzhardinge
2007-03-06 21:11 ` Ingo Molnar
2007-03-06 21:11 ` Ingo Molnar
2007-03-06 21:13 ` Jeremy Fitzhardinge
2007-03-06 21:13 ` Jeremy Fitzhardinge
2007-03-06 21:20 ` Ingo Molnar
2007-03-06 21:20 ` Ingo Molnar
2007-03-06 21:46 ` Jeremy Fitzhardinge
2007-03-06 21:46 ` Jeremy Fitzhardinge
2007-03-06 21:35 ` Nakajima, Jun
2007-03-06 21:35 ` Nakajima, Jun
2007-03-07 0:44 ` Rusty Russell
2007-03-07 0:54 ` Anthony Liguori
2007-03-07 0:54 ` Anthony Liguori
2007-03-07 3:06 ` Zachary Amsden
2007-03-07 8:15 ` Ingo Molnar
2007-03-07 8:15 ` Ingo Molnar
2007-03-07 9:17 ` Zachary Amsden
2007-03-07 11:15 ` Thomas Gleixner
2007-03-07 19:14 ` Dan Hecht
2007-03-06 16:27 ` Jeremy Fitzhardinge
2007-03-06 17:11 ` Ingo Molnar
2007-03-06 17:33 ` Jeremy Fitzhardinge
2007-03-07 2:16 ` Zachary Amsden
2007-03-07 2:16 ` Zachary Amsden
2007-03-06 9:55 ` Avi Kivity
2007-03-06 10:23 ` Gerd Hoffmann
2007-03-06 10:31 ` Ingo Molnar
2007-03-06 19:46 ` Chris Wright
2007-03-06 19:46 ` Chris Wright
2007-03-06 20:30 ` Ingo Molnar
2007-03-06 20:30 ` Ingo Molnar
2007-03-06 20:53 ` Chris Wright
2007-03-06 21:03 ` Ingo Molnar
2007-03-06 21:03 ` Ingo Molnar
2007-03-06 21:28 ` Chris Wright
2007-03-06 21:28 ` Chris Wright
2007-03-07 2:35 ` Zachary Amsden
2007-03-07 2:35 ` Zachary Amsden
2007-03-06 9:07 ` Jeremy Fitzhardinge
2007-03-06 9:07 ` Jeremy Fitzhardinge
2007-03-06 9:26 ` Ingo Molnar
2007-03-06 9:26 ` Ingo Molnar
2007-03-06 16:42 ` Jeremy Fitzhardinge
2007-03-06 16:42 ` Jeremy Fitzhardinge
2007-03-06 17:18 ` Ingo Molnar
2007-03-06 17:18 ` Ingo Molnar
2007-03-06 18:04 ` Jeremy Fitzhardinge
2007-03-06 18:04 ` Jeremy Fitzhardinge
2007-03-06 7:35 ` [patch] paravirt: VDSO page is essential Ingo Molnar
2007-03-06 7:35 ` Ingo Molnar
2007-03-06 7:42 ` Zachary Amsden
2007-03-06 7:50 ` Ingo Molnar
2007-03-06 7:50 ` Ingo Molnar
2007-03-06 18:48 ` Jeremy Fitzhardinge
2007-03-06 18:48 ` Jeremy Fitzhardinge
2007-03-05 14:27 ` Andi Kleen
2007-03-05 21:58 ` Roland McGrath
2007-03-05 22:01 ` Jeremy Fitzhardinge
2007-03-05 22:58 ` Roland McGrath
2007-03-05 23:03 ` Jeremy Fitzhardinge
2007-03-06 8:34 ` Ingo Molnar
2007-03-06 9:13 ` Roland McGrath
2007-03-06 9:14 ` Jeremy Fitzhardinge
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=20070306102658.GA7478@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=jbeulich@novell.com \
--cc=kraxel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.osdl.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.