| |
|
 |
|
 |
|
|
|
| |
|
|
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
|
|
|
| |
|
Home