This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: A proposal - binary

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: A proposal - binary
From: David Lang <dlang@xxxxxxxxxxxxxxxxxx>
Date: Fri, 4 Aug 2006 13:31:47 -0700 (PDT)
Cc: Andrew Morton <akpm@xxxxxxxx>, zach@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, jeremy@xxxxxxxxxxxxx, simon@xxxxxxxxxxxxx, jlo@xxxxxxxxxx, greg@xxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Antonio Vargas <windenntw@xxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, hch@xxxxxxxxxxxxx, ian.pratt@xxxxxxxxxxxxx, torvalds@xxxxxxxx, Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 07 Aug 2006 02:22:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44D3A9F3.2000000@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44D1CC7D.4010600@xxxxxxxxxx> <20060803190605.GB14237@xxxxxxxxx> <44D24DD8.1080006@xxxxxxxxxx> <20060803200136.GB28537@xxxxxxxxx> <44D2B678.6060400@xxxxxxxxxxxxx> <20060803211850.3a01d0cc.akpm@xxxxxxxx> <1154667875.11382.37.camel@xxxxxxxxxxxxxxxxxxxxx> <20060803225357.e9ab5de1.akpm@xxxxxxxx> <1154675100.11382.47.camel@xxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.63.0608040944480.18902@xxxxxxxxxxxxxxxxxxx> <69304d110608041146t44077033j9a10ae6aee19a16d@xxxxxxxxxxxxxx> <Pine.LNX.4.63.0608041150360.18862@xxxxxxxxxxxxxxxxxxx> <44D39F73.8000803@xxxxxxxxxxxxxxx> <Pine.LNX.4.63.0608041239430.18862@xxxxxxxxxxxxxxxxxxx> <44D3A9F3.2000000@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 4 Aug 2006, Jeremy Fitzhardinge wrote:

so if I understand this correctly we are saying that a kernel compiled to run on hypervisor A would need to be recompiled to run on hypervisor B, and recompiled again to run on hypervisor C, etc

where A could be bare hardware, B could be Xen 2, C could be Xen 3, D could be vmware, E could be vanilla Linux, etc.

Yes, but you can compile one kernel for any set of hypervisors, so if you want both Xen and VMI, then compile both in. (You always get bare hardware support.)

how can I compile in support for Xen4 on my 2.6.18 kernel? after all xen 2 and xen3 are incompatable hypervisors so why wouldn't xen4 (and I realize there is no xen4 yet, but there is likly to be one during the time virtual servers created with 2.6.18 are still running)

this sounds like something that the distros would not support, they would pick their one hypervisor to support and leave out the others. the big problem with this is that the preferred hypervisor will change over time and people will be left with incompatable choices (or having to compile their own kernels, including having to recompile older kernels to support newer hypervisors)

Why? That's like saying that distros will only bother to compile in one scsi driver.

The hypervisor driver is tricker than a normal kernel device driver, because in general it needs to be present from very early in boot, which precludes it from being a normal module. There's hope that we'll be able to support hypervisor drivers as boot-time grub/multiboot modules, so you'll be able to compile up a new hypervisor driver for a particular kernel and use it without recompiling the whole thing.

distros don't offer kernels with all options today, why would they in the future (how many distros offer seperate 486/586/K6/K7/Pentium/P2/P3/P4 kernels, none. they offer a least-common denominator kernel or two instead)

I also am missing something here. how can a system be compiled to do several different things for the same privilaged opcode (including running that opcode) without turning that area of code into a performance pig as it checks for each possible hypervisor being present?

David Lang

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>