| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <81575.40939.qm@web50114.mail.yahoo.com>
Date: Tue, 2 Jan 2007 16:20:35 -0800 (PST)
From: Doug Thompson <norsk5@...oo.com>
To: linux-kernel@...r.kernel.org
Subject: [PATCH 2/2] EDAC: K8 Memory scrubbing patch
from: Frithiof Jensen <frithiof.jensen@...cson.com>
This patch is meant for Kernel version 2.6.19
This is a first, naive, attempt of providing an interface for memory
scrubbing in EDAC.
The following things are still outstanding:
- Only the K8 driver has been refactored with a HW scrub function
The patch provide a method of configuring the K8 hardware memory
scrubber via the 'mcX' sysfs directory. There should be some
fallback to a generic scrubber implemented in software if the
hardware does not support scrubbing.
Or .. the scrubbing sysfs entry should not be visible at all.
- Only works with SDRAM,
The K8 can scrub cache and l2cache also - but I think this is
not so useful as the cache is busy all the time (one hopes).
One would also expect that cache scrubbing requires hardware
support.
- Error Handling,
I would like that errors are returned to the user in
"terms of file system".
- Presentation,
I chose Bandwidth in Bytes/Second as a representation of
the scrubbing rate for the following reasons:
I like that the sysfs entries are sort-of textual, related
to something that makes sense instead of magical values
that must be looked up.
"My People" wants "% main memory scrubbed per hour" others
prefer "% memory bandwidth used" as representation, "bandwith
used" makes it easy to calculate both versions in one-liner
scripts.
If one later wants to scrub cache, the scaling becomes wierd
for K8 changing from "blocks of 64 byte memory" to "blocks of
64 cache lines" to "blocks of 64 bit". Using "bandwidth used"
makes sense in all three cases, (I.M.O. anyway ;-).
- Discovery,
There is no way to discover the possible settings and what
they do without reading the code and the documentation.
*I* do not know how to make that work in a practical way.
- Bugs(??),
other tools can set invalid values in the memory scrub
control register, those will read back as '-1', requiring
the user to reset the scrub rate. This is how *I* think it
should be.
- Afflicting other areas of code,
I made changes to edac_mc.c and edac_mc.h which will show up
globally - this is not nice, it would be better that the
memory scrubbing fuctionality and interface could be entirely
contained within the memory controller it applies to.
Signed-off-by: Frithiof Jensen <frithiof.jensen@...cson.com>
Signed-off-by: doug thompson <norsk5@...ssion.com>
k8_edac.c | 135
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 135 insertions(+)
Index: linux-2.6.19/drivers/edac/k8_edac.c
===================================================================
--- linux-2.6.19.orig/drivers/edac/k8_edac.c
+++ linux-2.6.19/drivers/edac/k8_edac.c
@@ -254,6 +254,17 @@
* 7:0 Err addr high 39:32
*/
+#define K8_SCRCTRL 0x58 /* Memory scrub control register.
+ *
+ * 30:21 reserved
+ * 20:16 dcache scrub
+ * 15:13 reserved
+ * 12:8 L2Scrub
+ * 7:5 reserved
+ * 4:0 dramscrub
+ *
+ */
+
#define K8_NBCAP 0xE8 /* MCA NB capabilities (32b)
*
* 31:9 reserved
@@ -412,6 +423,45 @@ static const struct k8_dev_info k8_devs[
.misc_ctl = PCI_DEVICE_ID_AMD_OPT_3_MISCCTL},
};
+/* Valid scrub rates for the K8 hardware memory scrubber. We map
+ maps the scrubbing bandwith to a valid bit pattern. The 'set'
+ operation finds the 'matching- or higher value'.
+
+ FIXME: Produce a better mapping/linearisation.
+*/
+
+# define SDRATE_EOD 0xFFFFFFFF
+
+static struct scrubrate {
+ u32 scrubval; /* bit pattern for scrub rate */
+ u32 bandwidth; /* bandwidth consumed by scrubbing in bytes/sec */
+} scrubrates[] = {
+ {0x00, 0UL}, /* Scrubbing Off */
+ {0x16, 761UL}, /* Slowest Rate */
+ {0x15, 1523UL},
+ {0x14, 3051UL},
+ {0x13, 6101UL},
+ {0x12, 12213UL},
+ {0x11, 24427UL},
+ {0x10, 48854UL},
+ {0x0F, 97650UL},
+ {0x0E, 195300UL},
+ {0x0D, 390720UL},
+ {0x0C, 781440UL},
+ {0x0B, 1560975UL},
+ {0x0A, 3121951UL},
+ {0x09, 6274509UL},
+ {0x08, 12284069UL},
+ {0x07, 25000000UL},
+ {0x06, 50000000UL},
+ {0x05, 100000000UL},
+ {0x04, 200000000UL},
+ {0x03, 400000000UL},
+ {0x02, 800000000UL},
+ {0x01, 1600000000UL},
+ {0x00, SDRATE_EOD} /* End Of Data */
+};
+
static struct pci_dev * pci_get_related_function(unsigned int vendor,
unsigned int device, struct pci_dev *related)
{
@@ -428,6 +478,88 @@ static struct pci_dev * pci_get_related_
return dev;
}
+/* Memory scrubber control interface. For the K8 memory scrubbing is
+ handled by hardware and can involve the cache and the dcache as
+ well as the main memory. This causes the "units" for the scrubbing
+ speed to vary from 64 byte blocks (sdram) over cache lines (cache)
+ to bits (dcache).
+
+ This is nasty, so we will use bandwith in bytes/sec for the
setting.
+
+ Currently, we only do scrubbing of sdram - the caches are assumed
+ to be excercised always by running code and if the scrubber is done
+ in software on other archs, we might not have access to the
+ caches directly.
+*/
+
+static int set_sdram_scrub_rate(struct mem_ctl_info *mci, u32 *bw)
+{
+ struct k8_pvt *pvt;
+ u32 scrubval;
+ int status = -1;
+ int i;
+
+ pvt = (struct k8_pvt *) mci->pvt_info;
+
+ /* translate the configured rate to a value specific to
+ the K8 memory controller and apply.
+ search for the bandwith that is eq or gt than the
+ setting and program that.
+ */
+ for (i=0; scrubrates[i].bandwidth != SDRATE_EOD; i++) {
+
+ if (scrubrates[i].bandwidth >= *bw) {
+ scrubval = scrubrates[i].scrubval;
+ pci_write_bits32(pvt->misc_ctl, K8_SCRCTRL,
+ scrubval, 0x001F);
+ status = 0;
+ break;
+ }
+ }
+ return status;
+}
+
+static int get_sdram_scrub_rate(struct mem_ctl_info *mci, u32 *bw)
+{
+ struct k8_pvt *pvt;
+ u32 scrubval = 0;
+ int status = -1;
+ int i;
+
+ pvt = (struct k8_pvt *) mci->pvt_info;
+
+ /* find the bandwith matching the memory scrubber configuration
+ and return that value in *bw.
+ */
+ pci_read_config_dword(pvt->misc_ctl, K8_SCRCTRL, &scrubval);
+ scrubval = scrubval & 0x001F;
+
+ edac_printk(KERN_DEBUG, EDAC_MC,
+ "pci-read, sdram scrub control value: %d \n",scrubval);
+
+ for (i=0; scrubrates[i].bandwidth != SDRATE_EOD; i++) {
+
+ if (scrubrates[i].scrubval == scrubval) {
+ *bw = scrubrates[i].bandwidth;
+ status = 0;
+ break;
+ }
+ }
+
+ /* the bit pattern is invalid - we might fix it
+ by applying the slowest scrub rate as this is
+ closest to the valid value, but we do not!
+ */
+
+ if (scrubrates[i].bandwidth == SDRATE_EOD) {
+ edac_printk(KERN_WARNING, EDAC_MC,
+ "Invalid sdram scrub control value: %d \n",
+ scrubval);
+ status = -1;
+ }
+ return status;
+}
+
/* FIXME - stolen from msr.c - the calls in msr.c could be exported */
struct msr_command {
int cpu;
@@ -1801,6 +1933,9 @@ static int k8_probe1(struct pci_dev *pde
mci->ctl_name = k8_devs[dev_idx].ctl_name;
mci->edac_check = k8_check;
mci->ctl_page_to_phys = NULL;
+ /* memory scrubber interface */
+ mci->set_sdram_scrub_rate = set_sdram_scrub_rate;
+ mci->get_sdram_scrub_rate = get_sdram_scrub_rate;
if (k8_init_csrows(mci)) {
debugf1("Setting mci->edac_cap to EDAC_FLAG_NONE "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists