Merge branch 'x86/core' into x86/generalize-visws

What:		/sys/firmware/memmap/

Date:		June 2008

Contact:	Bernhard Walle <bwalle@suse.de>

Description:

		On all platforms, the firmware provides a memory map which the

		kernel reads. The resources from that memory map are registered

		in the kernel resource tree and exposed to userspace via

		/proc/iomem (together with other resources).

		However, on most architectures that firmware-provided memory

		map is modified afterwards by the kernel itself, either because

		the kernel merges that memory map with other information or

		just because the user overwrites that memory map via command

		line.

		kexec needs the raw firmware-provided memory map to setup the

		parameter segment of the kernel that should be booted with

		kexec. Also, the raw memory map is useful for debugging. For

		that reason, /sys/firmware/memmap is an interface that provides

		the raw memory map to userspace.

		The structure is as follows: Under /sys/firmware/memmap there

		are subdirectories with the number of the entry as their name:

			/sys/firmware/memmap/0

			/sys/firmware/memmap/1

			/sys/firmware/memmap/2

			/sys/firmware/memmap/3

			...

		The maximum depends on the number of memory map entries provided

		by the firmware. The order is just the order that the firmware

		provides.

		Each directory contains three files:

		start	: The start address (as hexadecimal number with the

			  '0x' prefix).

		end	: The end address, inclusive (regardless whether the

			  firmware provides inclusive or exclusive ranges).

		type	: Type of the entry as string. See below for a list of

			  valid types.

		So, for example:

			/sys/firmware/memmap/0/start

			/sys/firmware/memmap/0/end

			/sys/firmware/memmap/0/type

			/sys/firmware/memmap/1/start

			...

		Currently following types exist:

		  - System RAM

		  - ACPI Tables

		  - ACPI Non-volatile Storage

		  - reserved

		Following shell snippet can be used to display that memory

		map in a human-readable format:

		-------------------- 8< ----------------------------------------

		  #!/bin/bash

		  cd /sys/firmware/memmap

		  for dir in * ; do

		      start=$(cat $dir/start)

		      end=$(cat $dir/end)

		      type=$(cat $dir/type)

		      printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"

		  done

		-------------------- >8 ----------------------------------------

2) Or use the system kernel binary itself as dump-capture kernel and there is

   no need to build a separate dump-capture kernel. This is possible

   only with the architecutres which support a relocatable kernel. As

   of today i386 and ia64 architectures support relocatable kernel.

   of today, i386, x86_64 and ia64 architectures support relocatable kernel.

Building a relocatable kernel is advantageous from the point of view that

one does not have to build a second kernel for capturing the dump. But

	aic79xx=	[HW,SCSI]

			See Documentation/scsi/aic79xx.txt.

	amd_iommu=	[HW,X86-84]

			Pass parameters to the AMD IOMMU driver in the system.

			Possible values are:

			isolate - enable device isolation (each device, as far

			          as possible, will get its own protection

			          domain)

	amd_iommu_size= [HW,X86-64]

			Define the size of the aperture for the AMD IOMMU

			driver. Possible values are:

			'32M', '64M' (default), '128M', '256M', '512M', '1G'

	amijoy.map=	[HW,JOY] Amiga joystick support

			Map of devices attached to JOY0DAT and JOY1DAT

			Format: <a>,<b>

			See drivers/char/README.epca and

			Documentation/digiepca.txt.

	disable_mtrr_cleanup [X86]

	enable_mtrr_cleanup [X86]

			The kernel tries to adjust MTRR layout from continuous

			to discrete, to make X server driver able to add WB

			entry later. This parameter enables/disables that.

	mtrr_chunk_size=nn[KMG] [X86]

			used for mtrr cleanup. It is largest continous chunk

			that could hold holes aka. UC entries.

	mtrr_gran_size=nn[KMG] [X86]

			Used for mtrr cleanup. It is granularity of mtrr block.

			Default is 1.

			Large value could prevent small alignment from

			using up MTRRs.

	mtrr_spare_reg_nr=n [X86]

			Format: <integer>

			Range: 0,7 : spare reg number

			Default : 1

			Used for mtrr cleanup. It is spare mtrr entries number.

			Set to 2 or more if your graphical card needs more.

	disable_mtrr_trim [X86, Intel and AMD only]

			By default the kernel will trim any uncacheable

			memory out of your available memory pool based on

	usbhid.mousepoll=

			[USBHID] The interval which mice are to be polled at.

	add_efi_memmap	[EFI; x86-32,X86-64] Include EFI memory map in

			kernel's map of available physical RAM.

	vdso=		[X86-32,SH,x86-64]

			vdso=2: enable compat VDSO (default with COMPAT_VDSO)

			vdso=1: enable VDSO (default)

kernel debugging options, such as Kernel Stack Meter or Kernel Tracer,

may implicitly disable the NMI watchdog.]

For x86-64, the needed APIC is always compiled in, and the NMI watchdog is

always enabled with I/O-APIC mode (nmi_watchdog=1).

For x86-64, the needed APIC is always compiled in.

Using local APIC (nmi_watchdog=2) needs the first performance register, so

you can't use it for other purposes (such as high precision performance

But its NMI frequency is much higher, resulting in a more significant hit

to the overall system performance.

NOTE: starting with 2.4.2-ac18 the NMI-oopser is disabled by default,

you have to enable it with a boot time parameter.  Prior to 2.4.2-ac18

the NMI-oopser is enabled unconditionally on x86 SMP boxes.

On x86 nmi_watchdog is disabled by default so you have to enable it with

a boot time parameter.

On x86-64 the NMI oopser is on by default. On 64bit Intel CPUs

it uses IO-APIC by default and on AMD it uses local APIC.

NOTE: In kernels prior to 2.4.2-ac18 the NMI-oopser is enabled unconditionally

on x86 SMP boxes.

[ feel free to send bug reports, suggestions and patches to

  Ingo Molnar <mingo@redhat.com> or the Linux SMP mailing