[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V2] Revert "xen/arm: do not relocate Xen outside of visible RAM"



On Tue, 25 Oct 2016, Sameer Goel wrote:
> This reverts commit db92b1ac55cd5e193ae22b0b6f01fb47bc9e5d2f.
> 
> The restriction on non contiguous memory was resolved by commit
> 2d02b05c77fc5e7c76bf6f112db84bbaa44fdcb5:
> "xen: arm: improve handling of system with non-contiguous RAM regions"
> 
> So, reverting this change,to enable Xen image placement at the end of the
> useable system RAM.
> 
> Signed-off-by: Sameer Goel <sgoel@xxxxxxxxxxxxxx>

Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>


> The load restriction placed in the above reverted patch resulted in a crash
> when booting DOM0 on a Qualcomm platform with non contiguous system RAM.
> 
> (XEN) DOM0: [ 0.000000] bootmem alloc of 64 bytes failed!
> (XEN) DOM0: [ 0.000000] Kernel panic - not syncing: Out of memory
> (XEN) DOM0: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc7+ #19
> (XEN) DOM0: [ 0.000000] Hardware name: (null) (DT)
> (XEN) DOM0: [ 0.000000] Call trace:
> (XEN) DOM0: [ 0.000000] [<ffff000008088854>] dump_backtrace+0x0/0x1e4
> (XEN) DOM0: [ 0.000000] [<ffff000008088a5c>] show_stack+0x24/0x2c
> (XEN) DOM0: [ 0.000000] [<ffff000008452004>] dump_stack+0x8c/0xb0
> (XEN) DOM0: [ 0.000000] [<ffff00000819ee78>] panic+0x128/0x268
> (XEN) DOM0: [ 0.000000] [<ffff00000902c018>] __alloc_bootmem_low+0x40/0x4c
> (XEN) DOM0: [ 0.000000] [<ffff000009012adc>] setup_arch+0x2d8/0x560
> (XEN) DOM0: [ 0.000000] [<ffff00000901084c>] start_kernel+0x60/0x3b4
> (XEN) DOM0: [ 0.000000] [<ffff0000090101bc>] __primary_switched+0x30/0x74
> (XEN) DOM0: [ 0.000000] ---[ end Kernel panic - not syncing: Out of memory
> 
> The root cause for the crash was >4GB difference between the arm grant table
> (lower address) and the kernel start address. The kernel sees the grant table
> region as the start of system RAM.
> 
> Since, the grant table is a reuse of the text region of Xen image this issue
> would not be seen if Xen is loaded high enough in memory.
> 
>  xen/arch/arm/setup.c | 10 +---------
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 38eb888..1678871 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -392,25 +392,17 @@ static paddr_t __init get_xen_paddr(void)
>  {
>      struct meminfo *mi = &bootinfo.mem;
>      paddr_t min_size;
> -    paddr_t paddr = 0, last_end;
> +    paddr_t paddr = 0;
>      int i;
>  
>      min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
>  
> -    last_end = mi->bank[0].start;
> -
>      /* Find the highest bank with enough space. */
>      for ( i = 0; i < mi->nr_banks; i++ )
>      {
>          const struct membank *bank = &mi->bank[i];
>          paddr_t s, e;
>  
> -        /* We can only deal with contiguous memory at the moment */
> -        if ( last_end != bank->start )
> -            break;
> -
> -        last_end = bank->start + bank->size;
> -
>          if ( bank->size >= min_size )
>          {
>              e = consider_modules(bank->start, bank->start + bank->size,
> -- 
> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
> Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
> Linux Foundation Collaborative Project.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.