search for: pgdir_size

...this to potentially allow access to rest of 2G and PAE --- a/arch/arc/include/asm/highmem.h +++ b/arch/arc/include/asm/highmem.h @@ -9,17 +9,29 @@ #ifdef CONFIG_HIGHMEM #include <uapi/asm/page.h> -#include <asm/kmap_types.h> +#include <asm/kmap_size.h> + +#define FIXMAP_SIZE PGDIR_SIZE +#define PKMAP_SIZE PGDIR_SIZE /* start after vmalloc area */ #define FIXMAP_BASE (PAGE_OFFSET - FIXMAP_SIZE - PKMAP_SIZE) -#define FIXMAP_SIZE PGDIR_SIZE /* only 1 PGD worth */ -#define KM_TYPE_NR ((FIXMAP_SIZE >> PAGE_SHIFT)/NR_CPUS) -#define FIXMAP_ADDR(nr) (FIXMAP_BASE + ((nr) &l...

...-03-02 13:36:25.554259348 -0800 @@ -15,7 +15,7 @@ typedef unsigned long pgdval_t; typedef unsigned long pgprotval_t; -typedef struct { pteval_t pte; } pte_t; +typedef union { pteval_t pte; unsigned int pte_low; } pte_t; #endif /* !__ASSEMBLY__ */ @@ -54,6 +54,7 @@ #define PGDIR_MASK (~(PGDIR_SIZE - 1)) /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */ +#define MAX_PHYSMEM_BITS 43 #define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL) #define VMALLOC_START _AC(0xffffc90000000000, UL) #define VMALLOC_END _AC(0xffffe8ffffffffff, UL) L...

...-03-02 13:36:25.554259348 -0800 @@ -15,7 +15,7 @@ typedef unsigned long pgdval_t; typedef unsigned long pgprotval_t; -typedef struct { pteval_t pte; } pte_t; +typedef union { pteval_t pte; unsigned int pte_low; } pte_t; #endif /* !__ASSEMBLY__ */ @@ -54,6 +54,7 @@ #define PGDIR_MASK (~(PGDIR_SIZE - 1)) /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */ +#define MAX_PHYSMEM_BITS 43 #define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL) #define VMALLOC_START _AC(0xffffc90000000000, UL) #define VMALLOC_END _AC(0xffffe8ffffffffff, UL) L...

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

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

...--git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h index 52e5f5f2240d..ec3fe348bbd4 100644 --- a/arch/x86/include/asm/pgtable_64_types.h +++ b/arch/x86/include/asm/pgtable_64_types.h @@ -103,7 +103,7 @@ extern unsigned int ptrs_per_p4d; #define PGDIR_MASK (~(PGDIR_SIZE - 1)) /* - * See Documentation/x86/x86_64/mm.rst for a description of the memory map. + * See Documentation/arch/x86/x86_64/mm.rst for a description of the memory map. * * Be very careful vs. KASLR when changing anything here. The KASLR address * range must not overlap with anything except...

Fix several warnings and broken links. This series was generated against linux-next, but was rebased to be applied at docs-next. It should apply cleanly on either tree. There's a git tree with all of them applied on the top of docs/docs-next at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=fix_doc_links_v2 Mauro Carvalho Chehab (21): ABI: sysfs-devices-system-cpu: point to

...--git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h index 88bca456da99..52e5f5f2240d 100644 --- a/arch/x86/include/asm/pgtable_64_types.h +++ b/arch/x86/include/asm/pgtable_64_types.h @@ -103,7 +103,7 @@ extern unsigned int ptrs_per_p4d; #define PGDIR_MASK (~(PGDIR_SIZE - 1)) /* - * See Documentation/x86/x86_64/mm.txt for a description of the memory map. + * See Documentation/x86/x86_64/mm.rst for a description of the memory map. * * Be very careful vs. KASLR when changing anything here. The KASLR address * range must not overlap with anything except the...

...--git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h index 88bca456da99..52e5f5f2240d 100644 --- a/arch/x86/include/asm/pgtable_64_types.h +++ b/arch/x86/include/asm/pgtable_64_types.h @@ -103,7 +103,7 @@ extern unsigned int ptrs_per_p4d; #define PGDIR_MASK (~(PGDIR_SIZE - 1)) /* - * See Documentation/x86/x86_64/mm.txt for a description of the memory map. + * See Documentation/x86/x86_64/mm.rst for a description of the memory map. * * Be very careful vs. KASLR when changing anything here. The KASLR address * range must not overlap with anything except the...