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, RFC] x86: move trampoline location

To: Jan Beulich <JBeulich@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH, RFC] x86: move trampoline location
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 10 Feb 2010 09:36:42 +0000
Cc:
Delivery-date: Wed, 10 Feb 2010 01:37:28 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B71754B020000780002E78A@xxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acqpjl1BPirn3RlqSt6MGDMBU6c+ugApjAaI
Thread-topic: [Xen-devel] [PATCH, RFC] x86: move trampoline location
User-agent: Microsoft-Entourage/12.23.0.091001
On 09/02/2010 13:46, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> A partner of ours is reporting boot failures (Xen not even emitting a
> single message) over iSCSI on new (UEFI based) systems. After
> pointing at their BIOS initially I finally remembered to take a look
> at the memory map a native kernel booted this way see - and voila, the
> BIOS reports memory starting at 0x8d000 as reserved. Xen, however,
> places about 12k of (trampoline) data at 0x8c000.
> 
> Not having got testing feedback on the below patch yet, I still wanted
> to raise the question whether for 4.0 we should go with a simplistic
> fix like this, or whether we shouldn't really determine the trampoline
> location dynamically (i.e. honoring the E820 data) since it obviously
> cannot be excluded that other BIOSes might reserve even more of the
> space below 640k.

Looks fine to me, for 4.0.0 and 3.4.3. I'm not sure whether dynamic
placement based on E820 info is worthwhile. If all systems have an available
region from about address 0x0 up to some delta below EBDA etc, then why not
statically place the trampoline/reloc code to account for the largest such
delta ever observed? The main danger in going to lower addresses I think is
some bootloaders stick multiboot structures down there, which would get
obliterated by our 32-bit relocator.

 -- Keir



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

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