On Thursday 02 August 2007 10:49:57 Keir Fraser wrote:
> On 2/8/07 09:03, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote:
> > If there is a string table for section headers, it also gets loaded.
> > Therefore take it into account in size calculation for kernel symtab.
>
> I don't see how this works.
Basically, I do it the same way as Xen 3.0.4 did: First calculate the space
you need, then fill the space with ELF header, ELF section headers and
the symbol and string sections itself.
> In fact the whole sstart,send calculation looks broken.
Well, I did it analogous to elf_parse_binary() how it calculates the space
for phdr.
> What do the virtual addresses of the symtab/strtab sections have to
> do with their location in the final address space, after loading? And since
> you pack the sections into the domain address space in
> elf_xen_dom_load_binary(), should you not simply sum the sizes of the
> sections, then sstart=virt_kend and send=sstart+size_sum, rather than
> taking max(end addresses in elf image) minus min(start addresses in elf
> image).
You're right. Attached is a patch, which does it that way.
(Signed-off-by: Christoph Egger <Christoph.Egger@xxxxxxx>)
Oh and c/s 15677 in the staging tree removes the wrong elf_set_verbose() call.
Without it, you will never see the elf_msg() in elf_init().
The correct duplicate to remove is the one right after the use of elf_init().
My patch removes it.
> Does the section-header string table have to be loaded, or is that just an
> artefact of the loader code scanning for all SYMTAB/STRTAB? Shouldn't the
> loader fix up e_shnum and symtab's sh_link in the Elf metadata that it
> generates?
I think, Xen should just pass to Dom0 what it has and let Dom0 decide what
it wants to use.
> Couldn't the loader just use the saved elf->sym_tab and
> elf->sym_strtab to directly find the interesting two sections, rather than
> needing to do yet another full scan?
It needs to go through it, because it must adjust the sh_offset accordingly
in the section headers.
> > Keir: Can you also apply changeset 15672 and this patch
> > to Xen 3.1-stable, since these fixes an regression for Xen 3.1, please?
>
> I don't think so!
I *do* think so :-) Look (I marked the most interesting lines with an arrow):
With Xen 3.0.4 I get this:
[...]
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
Xen).
(XEN) Freed 92kB init memory.
Loaded initial symtab at 0xc09d7ad8, strtab at 0xc0a38cb4, # entries 23398 <=
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 4.99.26 (XEN3_DOM0) #70: Wed Jul 25 15:54:08 UTC 2007
root@tulln:/usr/src/sys/arch/i386/compile/XEN3_DOM0
[...]
With Xen 3.1 I get this:
[...]
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
Xen).
(XEN) Freed 92kB init memory.
[ Kernel symbol table missing! ] <=
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 4.99.26 (XEN3_DOM0) #74: Wed Aug 1 10:57:21 UTC 2007
root@tulln:/usr/src/sys/arch/i386/compile/XEN3_DOM0
[...]
and in -unstable (with my patches) I get this:
[...]
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
Xen).
(XEN) Freed 108kB init memory.
Loaded initial symtab at 0xc09decd8, strtab at 0xc0a4001c, # entries 23398 <=
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 4.99.26 (XEN3_DOM0) #74: Wed Aug 1 10:57:21 UTC 2007
root@tulln:/usr/src/sys/arch/i386/compile/XEN3_DOM0
[...]
Christoph
--
AMD Saxony, Dresden, Germany
Operating System Research Center
Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
Dr. Hans-R. Deppe, Thomas McCoy
xen_symtab.diff
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home