Re: [Minios-devel] Unikraft: _init_mem_clear_bootstrap() Fix

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

Hi Bruno,

thanks a lot for investigating this issue!
I had a similar issue with Xen on ARM where the zImage header was 
sometimes placed to a region that was out of range for the loader. I did 
not find the time yet to figure out why exactly this sometimes happens. 
I guess it has to do with the compiler flags -fdata-sections 
-ffunction-sections and --gc-sections for the linker. Any idea?
Could you send me your configuration (.config)? I wonder if I could 
reproduce the mis-placement that you saw; for now I couldn't:
nm build/helloworld_xen-x86_64.dbg | sort
0000000000000000 T _libxenplat_start
0000000000000000 T _text
0000000000000008 a RSP_OFFSET
0000000000000017 t stack_start
00000000000000fc a KERNEL_CS_MASK
0000000000001000 t _libxenplat_shared_info
0000000000002000 t hypercall_page
0000000000003000 t error_entry
0000000000003069 t hypervisor_callback
0000000000003078 t hypervisor_callback2
00000000000030bb t error_exit
...

On 01.02.2018 07:35, Bruno Alvisio wrote:
> Hello all,
>
> Currently, the call to the function 
> unikraft/plat/x86/mm.c:_init_mem_clear_bootstrap() from 
> unikraft/plat/xen/x86/setup.c:_init_mem() causes unikraft to crash. I 
> investigated this issue and noticed that the VA address of 
> _libxenplat_start (kernel entry point) is located at address 0x1000 
> instead of 0x0. (The .text section starts at address 0x0 though) See below:
> *balvisio@debianxen**:~/unikraft/apps/helloworld/build$ nm 
> helloworld_xen-x86_64.dbg | grep start | sort*
> *0000000000001000 T _libxenplat_start***
>
> *0000000000001017 t stack_start*
>
> *000000000000435b t thread_starter*
>
> *000000000000a0a0 t schedcoop_thread_start*
>
> *000000000000c00c d nonopt_start*
>
> *000000000000c01c D __bss_start*
>
> *0000000000057060 B HYPERVISOR_start_info***
>
> I forced the linker script to position _libxenplat_start() at location 
> 0x0 with the following patch and it seems to solve the problem:
> *diff --git a/plat/xen/x86/entry64.S b/plat/xen/x86/entry64.S*
>
> *index bdaa05a..94a5546 100644*
>
> *--- a/plat/xen/x86/entry64.S*
>
> *+++ b/plat/xen/x86/entry64.S*
>
> @@ -51,7 +51,7 @@ ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION, .asciz "xen-3.0")
>
> .text
>
> .globl _libxenplat_start
>
> -
>
> +.section .text.prologue, "ax"
>
> _libxenplat_start:
>
> #else
>
> *diff --git a/plat/xen/x86/link64.ld b/plat/xen/x86/link64.ld*
>
> *index 2842a75..837c500 100644*
>
> *--- a/plat/xen/x86/link64.ld*
>
> *+++ b/plat/xen/x86/link64.ld*
>
> @@ -32,6 +32,7 @@ SECTIONS
>
> . = 0x0;
>
> _text = .;/* Text and read-only data */
>
> .text : {
>
> +*(.text.prologue)
>
> *(.text)
>
> *(.gnu.warning)
>
> } = 0x2000
>
> *diff --git a/plat/xen/x86/setup.c b/plat/xen/x86/setup.c*
>
> *index cf8bad2..18fcd24 100644*
>
> *--- a/plat/xen/x86/setup.c*
>
> *+++ b/plat/xen/x86/setup.c*
>
> @@ -156,7 +156,7 @@ static inline void _init_mem(void)
>
> uk_printd(DLVL_INFO, "max_pfn: %lx\n", max_pfn);
>
> _init_mem_build_pagetable(&start_pfn, &max_pfn);
>
> -//_init_mem_clear_bootstrap(); /* FIXME - stack or text screwed up? */
>
> +_init_mem_clear_bootstrap(); /* FIXME - stack or text screwed up? */
>
> //_init_mem_set_readonly(&_text, &_erodata); /* FIXME - shared info ro? */
>
> /* Fill out mrd array */
>
> I am not sure if the problem can be solved by adding certain flag to the 
> linker so that it automatically places _libxenplat_start() function at 0x0.
> Any comments on this would be greatly appreciated and if this looks like 
> a right solution I can send the PATCH to the list.
What happens actually to the other boot-critical symbols when you apply 
your patch (e.g., _libxenplat_shared_info, hypercall_page). For now the 
boot code expects them to be at 0x1000 and 0x2000.
> Cheers >
> Bruno
Cheers,

Simon

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel