WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Elf loader fixes

To: "Gerd Hoffmann" <kraxel@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Elf loader fixes
From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
Date: Wed, 1 Mar 2006 09:48:54 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Joe Bonasera <joe.bonasera@xxxxxxx>
Delivery-date: Wed, 01 Mar 2006 09:49:23 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZbEPGuwHa1/042ecymfod1BBv+WJYxJ7b4BCkcU273aan79MudD9q8O+pgeg4QdUka6+GSXIqWkRj77AMQa7up5yhJugDgVhx4f8x2JOnBZwo2scumyi4NkMjof5sEFayAcskl3C+Mzbyf1enMRRoNakpjLiouWrnWWWlVr249A=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43FD9938.1010502@xxxxxxx>
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: <E1F6x4v-0001lS-2n@host-192-168-0-1-bcn-london> <43FCAACA.4030804@xxxxxxx> <43FD9938.1010502@xxxxxxx>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 2/23/06, Gerd Hoffmann <kraxel@xxxxxxx> wrote:
> > some with p_vaddr == p_paddr on purpose and some which don't. We rely on a
> > "boot loader" (ie grub or domain builder) that only cares about p_paddr.
>
> Same goes for the x86_64 linux kernel with the vsyscall page ...
>
> I've settled for a slightly different approach now.  To keep behaviour
> as close as possible to classic i386 boot loaders I'll check paddr only
> and use the virt_base value from the __xen_guest section to shift the
> addresses.  For bug compatibility with old linux kernels I compare paddr
> + virt_base.  New patch below, this time tested both 32 and 64 bit
> (linux only though), I think it should be ok for OpenSolaris too ;)

I have two issues with your latest patch:
- the heuristics you use to distinguish between "old" and "new" kernel
images, especially the case where a valid "new" kernel image could be
mistaken for an "old" image.
- the change to the entry point, now entry point and the elf header
paddr fields are in different address modes.

We have the current combination of VIRT_BASE and elf header paddr
fields containing virtual addresses because:
- we want to be able to specify where the virtual address space mapped
by the initial pagetables starts, this is why we have VIRT_BASE
- since we always run in virtual address mode, we thought that the
loader should also do so, thus it will load the image to a virtual
address - this seems to be in line with how other loaders would read
the elf header paddr fields, i.e. use them as load addresses.

If we really need to get rid of how we change LOAD_OFFSET in Linux,
how about this:
we add another entry to the __xen_guest header, PHYS_OFFSET=0 and then
substract PHYS_OFFSET from all elf header paddr fiels to turn them
into physical addresses, respectively, resp. add VIRT_BASE-PHYS_OFFSET
to turn them into virtual addresses.  We default PHYS_OFFSET to
VIRT_BASE if it's not present in the __xen_guest header.

     christian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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