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

Re: [Xen-devel] [PATCH] linux/x86-64: miscellaneous initialization code cleanup



See whinges below. I applied the patch anyway, plus the required fixes.

 Thanks,
 Keir

> --- head-2007-06-11.orig/arch/x86_64/kernel/head-xen.S        2007-06-11 
> 09:08:18.000000000 +0200
> +++ head-2007-06-11/arch/x86_64/kernel/head-xen.S     2007-06-11 
> 09:09:41.000000000 +0200
> @@ -53,15 +53,13 @@ ENTRY(name)
>  NEXT_PAGE(init_level4_pgt)
>       /* This gets initialized in x86_64_start_kernel */
>       .fill   512,8,0
> -
>          /*
>           * We update two pgd entries to make kernel and user pgd consistent
>           * at pgd_populate(). It can be used for kernel modules. So we place 
>           * this page here for those cases to avoid memory corruption.
> -         * We also use this page to establish the initiali mapping for
> +         * We also use this page to establish the initial mapping for the
>           * vsyscall area.
>           */
> -NEXT_PAGE(init_level4_user_pgt)
>       .fill   512,8,0
>  NEXT_PAGE(level3_kernel_pgt)


Breaks the build, since removeing NEXT_PAGE(init_level4_user_pgt)
means the $page variable isn't incremented, and so the next NEXT_PAGE
produces a backwards org statement. How could this ever have worked?

> Index: head-2007-06-11/drivers/xen/core/smpboot.c
> ===================================================================
> --- head-2007-06-11.orig/drivers/xen/core/smpboot.c   2007-06-11 
> 09:08:18.000000000 +0200
> +++ head-2007-06-11/drivers/xen/core/smpboot.c        2007-06-11 
> 09:09:41.000000000 +0200
> @@ -72,8 +72,6 @@ EXPORT_SYMBOL(cpu_core_map);
>  #if defined(__i386__)
>  u8 x86_cpu_to_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = 0xff };
>  EXPORT_SYMBOL(x86_cpu_to_apicid);
> -#elif !defined(CONFIG_X86_IO_APIC)
> -unsigned int maxcpus = NR_CPUS;
>  #endif

Breaks the 64-bit SMP domU build, at least in our linux-2.6.18-xen-hg
repo. maxcpus actually is referenced in arxh/x86_64/setup.c. Perhaps it 
shouldn't
be, since it looks to be properly handled in init/main.c?

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


 


Rackspace

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