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] xen-kernel and EDD

To: Keir Fraser <keir@xxxxxxx>
Subject: Re: [Xen-devel] xen-kernel and EDD
From: Lin-Bao Zhang <2004.zhang@xxxxxxxxx>
Date: Fri, 19 Aug 2011 16:27:19 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 19 Aug 2011 01:28:20 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=x1O9xH6IVPAOb+qXbrS43xQeWHNSxep8KDNIWeBokWE=; b=CZAXb1a2g4ouoXQi7ETfeUOr9X7llvPGYWAIlB7jWOKUK6Pfams7MLe2cEL9J8hidB eCehhjiHyRV66RczxnxDdBDVE+vlAkqjxsj3P99pt3Z6vs7+gm4FeengfCb1w4Vgg4n7 ETsyiqzRZ61pR+cmFoWROxd0uFXBnR85/1q1Q=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CANuKePmOd7h2qiG=8AmyXqza805sEeg-o6csHpTM5fE+XK-6pA@xxxxxxxxxxxxxx>
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>
References: <CANuKePmurLWCEEJVzbQv2hSzccUiE-NHDkuVddgyRyXapb9Znw@xxxxxxxxxxxxxx> <CA72B048.30827%keir@xxxxxxx> <CANuKePmOd7h2qiG=8AmyXqza805sEeg-o6csHpTM5fE+XK-6pA@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
2011/8/18 Lin-Bao Zhang <2004.zhang@xxxxxxxxx>
>
> 2011/8/18 Keir Fraser <keir@xxxxxxx>:
> > It's almost certainly this. In latest Xen we run the trampoline code at
> > 0x7c000. So you can try rebuilding your hypervisor with the following
> > changes:
> > 1. Change BOOT_TRAMPOLINE to 0x7c000
> > 2. In arch/x86/boot/head.S, change the line 'mov $0x98000,%esp' to 'mov
> > $0x80000,%esp'.
> >
> > That will probably fix your problem.
> >
> >  -- Keir

Hi Keir ,
maybe 0x80000 is not very good, I check xen-4.1.0 code:
/* Copy bootstrap trampoline to low memory, below 1MB. */
       mov     $sym_phys(trampoline_start),%esi
       mov     $bootsym_phys(trampoline_start),%edi
       mov     $trampoline_end - trampoline_start,%ecx
       rep     movsb

       mov     $bootsym_phys(early_stack),%esp  //eary_stack.
       call    cmdline_parse_early

       /* Jump into the relocated trampoline. */
       jmp     $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry)

it seems that direct number is not very compatible .

1, another point : it seems that this code should copy code (from
trampoline_start to trampoline_end) to BOOT_TRAMPOLINE(0x90000)) , I
will consider if trampoline code size bigger than
0x95400-0x90000=21KBytes .
but my binary xen.gz doesn't include symbols , so I can't see address
of trampoline_start and trampoline_end.  how to get them ? must
recompile it ?I think maybe redhat has deleted symbols . yet I don't
trampoline will be over 21KBytes,because it seems small code.


2, about definition of trampoline_start and trampoline_end ?
I just can see:
#define BOOT_TRAMPOLINE 0x90000
#define bootsym_phys(sym)                                 \
   (((unsigned long)&(sym)-(unsigned long)&trampoline_start)+BOOT_TRAMPOLINE)
#define bootsym(sym)                                      \
   (*RELOC_HIDE((typeof(&(sym)))__va(__pa(&(sym))),      \
                BOOT_TRAMPOLINE-__pa(trampoline_start)))
#ifndef __ASSEMBLY__
extern char trampoline_start[], trampoline_end[];
extern char trampoline_realmode_entry[];
extern unsigned int trampoline_xen_phys_start;
extern unsigned char trampoline_cpu_started;
#endif

。。。。。。。。。。
head.S :
       .globl trampoline_start, trampoline_end
trampoline_start:  //  it seems that I must find this symbol to
confirm its value , nm -a this file , displaying no symbols.
#include "trampoline.S"
trampoline_end:


3 , in sles11:

I find sles11 again , I did the same steps .
in sles11 x86_64 version ,there are also :
xen-syms-3.3.1_18546_12-3.1 and xen.gz :
nm -a xen(unzip xen.gz) ,can't trampoline_start/end
while nm -a xen-syms-3.3.1_18546_12-3.1 , I can finally find
"trampoline_start" and "trampoline_end" :
--bob comment: I begin another email subject "about __XEN_VIRT_START
and 0x100000" to ask the difference between these 2 files.

from this output ,useful information:
ffff828c80100000 A _start
...
ffff828c8020d5b6 t trampoline_boot_cpu_entry
ffff828c8020d549 T trampoline_cpu_started
ffff828c8020fe50 T trampoline_end                                 //here
ffff828c8020d511 t trampoline_gdt
ffff828c8020d54a t trampoline_protmode_entry
ffff828c8020d4e0 T trampoline_realmode_entry
ffff828c8020d4e0 T trampoline_start                                  //here
ffff828c8020d545 T trampoline_xen_phys_start
ffff828c80172ab0 t transition_pstate
...
from sles11 , trampoline code size   0xFFFF828C8_020FE50 -
ffff828c8_020d4e0 =  0x2970  (about 10KBytes)
if BOOT_TRAMPOLINE == 0x90000 , then trampoline end will be 0x92970
,while my EBDA is 0x954000 ~ 0xa0000 . so I think don't overlap.
certainly , this number is from sles11 xen-kernel ,but I think their
trampoline.S basily same ,length should be almost same.

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