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: [RFC PATCH 07/35] Make LOAD_OFFSET defined by subarch

To: Zachary Amsden <zach@xxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC PATCH 07/35] Make LOAD_OFFSET defined by subarch
From: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Date: Thu, 11 May 2006 17:43:00 +0100
Cc: Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>
Delivery-date: Thu, 11 May 2006 09:43:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44627733.4010305@xxxxxxxxxx>
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: <20060509084945.373541000@xxxxxxxxxxxx> <20060509085150.509458000@xxxxxxxxxxxx> <44627733.4010305@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Wed, May 10, 2006 at 04:28:51PM -0700, Zachary Amsden wrote:
> Chris Wright wrote:
> >Change LOAD_OFFSET so that the kernel has virtual addresses in the elf 
> >header fields.
> >
> >Unlike bare metal kernels, Xen kernels start with virtual address
> >management turned on and thus the addresses to load to should be
> >virtual addresses.
> This patch interferes with using a traditional bootloader.  The loader 
> for Xen should be smarter - it already has VIRT_BASE from the xen_guest 
> section, and can simply add the relocation to these header fields.  This 
> is unnecessary, and one of the many reasons a Xen kernel can't run in a 
> normal environment.

It's certainly not as simple as you make it sound, if you want to
support existing kernels without having to guess how the kernel image
was built.

I've updated our loader to support this now, so that this patch is
no longer necessary.  I have at the same time added a new field to
xen_guest which allows specifying the entry point, allowing us to have
a different entry point when running the kernel image on Xen.


Xen-devel mailing list

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