search for: arch_sparsemem_enable

...64 && SPARSEMEM_VMEMMAP >> >> Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable > > Why? Again, this is the first I've heard of this as well. FWIW, all > the Xen configs we use have SPARSEMEM_VMEMMAP enabled. Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at SUSE. Figured this was a generic issue. The SUSE kernels are based on 3.12 though, but anyway with it enabled I do get compile failures because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen set to 43 for some reason (can't find that justification), so it doesn...

...64 && SPARSEMEM_VMEMMAP >> >> Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable > > Why? Again, this is the first I've heard of this as well. FWIW, all > the Xen configs we use have SPARSEMEM_VMEMMAP enabled. Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at SUSE. Figured this was a generic issue. The SUSE kernels are based on 3.12 though, but anyway with it enabled I do get compile failures because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen set to 43 for some reason (can't find that justification), so it doesn...

...AP >>> >>> Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable >> >> Why? Again, this is the first I've heard of this as well. FWIW, all >> the Xen configs we use have SPARSEMEM_VMEMMAP enabled. > > Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at > SUSE. Figured this was a generic issue. The SUSE kernels are based on > 3.12 though, but anyway with it enabled I do get compile failures > because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen > set to 43 for some reason (can't find that justificat...

...onfig =================================================================== --- linux-2.6.13.orig/arch/i386/Kconfig 2005-08-24 09:30:49.000000000 -0700 +++ linux-2.6.13/arch/i386/Kconfig 2005-08-24 09:58:56.000000000 -0700 @@ -803,6 +803,14 @@ config ARCH_SELECT_MEMORY_MODEL def_bool y depends on ARCH_SPARSEMEM_ENABLE +config MEMORY_HOLE + int "Create hole at top of memory (0-512 MB)" + range 0 512 + default "0" + help + Useful for creating a hole in the top of memory when running + inside of a virtual machine monitor. + source "mm/Kconfig" config HAVE_ARCH_EARLY_PFN_TO_...

...onfig =================================================================== --- linux-2.6.13.orig/arch/i386/Kconfig 2005-08-24 09:30:49.000000000 -0700 +++ linux-2.6.13/arch/i386/Kconfig 2005-08-24 09:58:56.000000000 -0700 @@ -803,6 +803,14 @@ config ARCH_SELECT_MEMORY_MODEL def_bool y depends on ARCH_SPARSEMEM_ENABLE +config MEMORY_HOLE + int "Create hole at top of memory (0-512 MB)" + range 0 512 + default "0" + help + Useful for creating a hole in the top of memory when running + inside of a virtual machine monitor. + source "mm/Kconfig" config HAVE_ARCH_EARLY_PFN_TO_...

...>> Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable >>> >>> Why? Again, this is the first I've heard of this as well. FWIW, all >>> the Xen configs we use have SPARSEMEM_VMEMMAP enabled. >> >> Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at >> SUSE. Figured this was a generic issue. The SUSE kernels are based on >> 3.12 though, but anyway with it enabled I do get compile failures >> because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen >> set to 43 for some reason (can't find...

Andrey, I believe that on Xen we should disable kasan, would like confirmation from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the

Andrey, I believe that on Xen we should disable kasan, would like confirmation from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the

...es. I will do that if this patch will be accepted. > >diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > >index 38434da..beb1aa7 100644 > >--- a/arch/x86/Kconfig > >+++ b/arch/x86/Kconfig > >@@ -1273,7 +1273,7 @@ config ARCH_SELECT_MEMORY_MODEL > > depends on ARCH_SPARSEMEM_ENABLE > > > > config ARCH_MEMORY_PROBE > >- def_bool y > >+ def_bool X86_64&& !XEN > > depends on MEMORY_HOTPLUG > > The trouble with making anything statically depend on Xen at config time > is that you lose it even if you''re not running under...

...m/memory_hotplug.c | 146 +-------------- 8 files changed, 240 insertions(+), 374 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 38434da..beb1aa7 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1273,7 +1273,7 @@ config ARCH_SELECT_MEMORY_MODEL depends on ARCH_SPARSEMEM_ENABLE config ARCH_MEMORY_PROBE - def_bool y + def_bool X86_64 && !XEN depends on MEMORY_HOTPLUG config ILLEGAL_POINTER_VALUE diff --git a/drivers/base/memory.c b/drivers/base/memory.c index 709457b..933442f 100644 --- a/drivers/base/memory.c +++ b/drivers/base/memory.c @@ -27,14 +27,6 @@...