aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-x86_64/cache.h
diff options
context:
space:
mode:
authorBernhard Kaindl <bk@suse.de>2007-05-02 13:27:17 -0400
committerAndi Kleen <andi@basil.nowhere.org>2007-05-02 13:27:17 -0400
commit2b1f6278d77c1f2f669346fc2bb48012b5e9495a (patch)
tree52a30a649b4786869a51bceefb2c7ca696e0fe32 /include/asm-x86_64/cache.h
parent2b3b4835c94226681c496de9446d456dcf42ed08 (diff)
[PATCH] x86: Save the MTRRs of the BSP before booting an AP
Applied fix by Andew Morton: http://lkml.org/lkml/2007/4/8/88 - Fix `make headers_check'. AMD and Intel x86 CPU manuals state that it is the responsibility of system software to initialize and maintain MTRR consistency across all processors in Multi-Processing Environments. Quote from page 188 of the AMD64 System Programming manual (Volume 2): 7.6.5 MTRRs in Multi-Processing Environments "In multi-processing environments, the MTRRs located in all processors must characterize memory in the same way. Generally, this means that identical values are written to the MTRRs used by the processors." (short omission here) "Failure to do so may result in coherency violations or loss of atomicity. Processor implementations do not check the MTRR settings in other processors to ensure consistency. It is the responsibility of system software to initialize and maintain MTRR consistency across all processors." Current Linux MTRR code already implements the above in the case that the BIOS does not properly initialize MTRRs on the secondary processors, but the case where the fixed-range MTRRs of the boot processor are changed after Linux started to boot, before the initialsation of a secondary processor, is not handled yet. In this case, secondary processors are currently initialized by Linux with MTRRs which the boot processor had very early, when mtrr_bp_init() did run, but not with the MTRRs which the boot processor uses at the time when that secondary processors is actually booted, causing differing MTRR contents on the secondary processors. Such situation happens on Acer Ferrari 1000 and 5000 notebooks where the BIOS enables and sets AMD-specific IORR bits in the fixed-range MTRRs of the boot processor when it transitions the system into ACPI mode. The SMI handler of the BIOS does this in SMM, entered while Linux ACPI code runs acpi_enable(). Other occasions where the SMI handler of the BIOS may change bits in the MTRRs could occur as well. To initialize newly booted secodary processors with the fixed-range MTRRs which the boot processor uses at that time, this patch saves the fixed-range MTRRs of the boot processor before new secondary processors are started. When the secondary processors run their Linux initialisation code, their fixed-range MTRRs will be updated with the saved fixed-range MTRRs. If CONFIG_MTRR is not set, we define mtrr_save_state as an empty statement because there is nothing to do. Possible TODOs: *) CPU-hotplugging outside of SMP suspend/resume is not yet tested with this patch. *) If, even in this case, an AP never runs i386/do_boot_cpu or x86_64/cpu_up, then the calls to mtrr_save_state() could be replaced by calls to mtrr_save_fixed_ranges(NULL) and mtrr_save_state() would not be needed. That would need either verification of the CPU-hotplug code or at least a test on a >2 CPU machine. *) The MTRRs of other running processors are not yet checked at this time but it might be interesting to syncronize the MTTRs of all processors before booting. That would be an incremental patch, but of rather low priority since there is no machine known so far which would require this. AK: moved prototypes on x86-64 around to fix warnings Signed-off-by: Bernhard Kaindl <bk@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: Dave Jones <davej@codemonkey.org.uk>
Diffstat (limited to 'include/asm-x86_64/cache.h')
0 files changed, 0 insertions, 0 deletions
ef='#n26'>26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117
#ifndef _LINUX_ATMBR2684_H
#define _LINUX_ATMBR2684_H

#include <linux/types.h>
#include <linux/atm.h>
#include <linux/if.h>		/* For IFNAMSIZ */

/*
 * Type of media we're bridging (ethernet, token ring, etc)  Currently only
 * ethernet is supported
 */
#define BR2684_MEDIA_ETHERNET	(0)	/* 802.3 */
#define BR2684_MEDIA_802_4	(1)	/* 802.4 */
#define BR2684_MEDIA_TR		(2)	/* 802.5 - token ring */
#define BR2684_MEDIA_FDDI	(3)
#define BR2684_MEDIA_802_6	(4)	/* 802.6 */

					/* used only at device creation:  */
#define BR2684_FLAG_ROUTED	(1<<16)	/* payload is routed, not bridged */

/*
 * Is there FCS inbound on this VC?  This currently isn't supported.
 */
#define BR2684_FCSIN_NO		(0)
#define BR2684_FCSIN_IGNORE	(1)
#define BR2684_FCSIN_VERIFY	(2)

/*
 * Is there FCS outbound on this VC?  This currently isn't supported.
 */
#define BR2684_FCSOUT_NO	(0)
#define BR2684_FCSOUT_SENDZERO	(1)
#define BR2684_FCSOUT_GENERATE	(2)

/*
 * Does this VC include LLC encapsulation?
 */
#define BR2684_ENCAPS_VC	(0)	/* VC-mux */
#define BR2684_ENCAPS_LLC	(1)
#define BR2684_ENCAPS_AUTODETECT (2)	/* Unsuported */

/*
 * Is this VC bridged or routed?
 */

#define BR2684_PAYLOAD_ROUTED   (0)
#define BR2684_PAYLOAD_BRIDGED  (1)

/*
 * This is for the ATM_NEWBACKENDIF call - these are like socket families:
 * the first element of the structure is the backend number and the rest
 * is per-backend specific
 */
struct atm_newif_br2684 {
	atm_backend_t backend_num;	/* ATM_BACKEND_BR2684 */
	int media;		/* BR2684_MEDIA_*, flags in upper bits */
	char ifname[IFNAMSIZ];
	int mtu;
};

/*
 * This structure is used to specify a br2684 interface - either by a
 * positive integer (returned by ATM_NEWBACKENDIF) or the interfaces name
 */
#define BR2684_FIND_BYNOTHING	(0)
#define BR2684_FIND_BYNUM	(1)
#define BR2684_FIND_BYIFNAME	(2)
struct br2684_if_spec {
	int method;		/* BR2684_FIND_* */
	union {
		char ifname[IFNAMSIZ];
		int devnum;
	} spec;
};

/*
 * This is for the ATM_SETBACKEND call - these are like socket families:
 * the first element of the structure is the backend number and the rest
 * is per-backend specific
 */
struct atm_backend_br2684 {
	atm_backend_t backend_num;	/* ATM_BACKEND_BR2684 */
	struct br2684_if_spec ifspec;
	int fcs_in;		/* BR2684_FCSIN_* */
	int fcs_out;		/* BR2684_FCSOUT_* */
	int fcs_auto;		/* 1: fcs_{in,out} disabled if no FCS rx'ed */
	int encaps;		/* BR2684_ENCAPS_* */
	int has_vpiid;		/* 1: use vpn_id - Unsupported */
	__u8 vpn_id[7];
	int send_padding;	/* unsupported */
	int min_size;		/* we will pad smaller packets than this */
};

/*
 * The BR2684_SETFILT ioctl is an experimental mechanism for folks
 * terminating a large number of IP-only vcc's.  When netfilter allows
 * efficient per-if in/out filters, this support will be removed
 */
struct br2684_filter {
	__be32 prefix;		/* network byte order */
	__be32 netmask;		/* 0 = disable filter */
};

struct br2684_filter_set {
	struct br2684_if_spec ifspec;
	struct br2684_filter filter;
};

enum br2684_payload {
	p_routed = BR2684_PAYLOAD_ROUTED,
	p_bridged = BR2684_PAYLOAD_BRIDGED,
};

#define BR2684_SETFILT	_IOW( 'a', ATMIOC_BACKEND + 0, \
				struct br2684_filter_set)

#endif /* _LINUX_ATMBR2684_H */