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

[Xen-devel] Re: xen/ia64 and elilo relocation

To: Arun Sharma <arun.sharma@xxxxxxxxx>
Subject: [Xen-devel] Re: xen/ia64 and elilo relocation
From: Stephane Eranian <eranian@xxxxxxxxxx>
Date: Sun, 20 Feb 2005 08:42:47 -0800
Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA.
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>, brett@xxxxxx
Delivery-date: Mon, 21 Feb 2005 07:35:38 +0000
E-mail: eranian@xxxxxxxxxx
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <4213F913.9020607@xxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organisation: HP Labs Palo Alto
References: <4213F913.9020607@xxxxxxxxx>
Reply-to: eranian@xxxxxxxxxx
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
Arun,

sorry for the delay I was travelling.

On Wed, Feb 16, 2005 at 05:53:23PM -0800, Arun Sharma wrote:
> 
> I noticed that elilo occassionally loads xen/ia64 at: 0x14000000 instead of 
> the usual
> 0x4000000 (especially if you interrupt the loading process by pressing a 
> key).
> 

elilo loads each block of text/data at the address indicated by the
paddr of the corresponding program header.

Are you saying that the address is different only when you abort a load?
Note that when an EFI program terminates, the memory is not freed. If we do
not cleanly free the memory on load abort, then it is possible that the
designated memory address is unavailable. I quickly checked the source code
and elilo does not try to relocate unless the option "relocatable " is specified
either globally in elilo.conf or on the Xen image. I also checked the abort
case and elilo does free the memory allocated for the kernel, as such you should
be able to retry. 

You can try forcing elilo-3.4/ia64/config.c:ia64_can_relocate() to return 0
just to make sure this is not the source of the problem.


> This results in TR map setup from: fffc000014000000 (virtual) -> 0x4000000 
> (physical).
> Further, __alloc_bootmem() gives out fffc000004000000 as free memory and 
> memsets it to 0. Now xen is going to insert a second TC from 
> fffc000004000000 (virtual) -> 0x4000000 (physical) i.e. we have two virtual 
> addresses mapping to the same physical address.
> 
> The memset essentially corrupts xen's text.
> 
> We have to figure out a way of telling elilo to always load xen at the same 
> physical address. I thought the relocatable flag was off by default?
> 
>       -Arun

-- 

-Stephane


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel