Carl-Daniel Hailfinger <c-d.hailfinger.devel.2...@gmx.net> writes: > I looked at all changes since r2006 in src/cpu/x86/mtrr/ and > src/cpu/amd/mtrr/ > r3014 introduced CONFIG_VAR_MTRR_HOLE which needs to be enabled to use > subtractive MTRR code for x86. Before that revision, that code was > always enabled. > > However, I get the following boot log, so I assume subtractive setup > works at least in some cases:
Good to see. For the rest of the cases I guess someone needs to take a look and see why it doesn't work. A few comment on general MTRR policy. A MTRR covering the rom chip while we are executing out of the ROM is necessary for performance. After that even when copying data I could not measure a measurable performance impact, so it is unnecessary. Given that both Linux and Windows uses PAT on modern systems we want to use whatever MTRRs we can to mark as much of the RAM as possible (preferably all) as cacheable. Reserving MTRRs for the OS was a nice idea when it was specced but with overlapping MTRRs it doesn't really help, and with PAT support in the OS's it really isn't necessary. If the RAM is not cacheable we really should not report it to the OS because it will be painfully and horribly slow, and significantly degrade performance. Eric -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
