On 12/19/2012 03:03 PM, Borislav Petkov wrote: > On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote: >> I can check but right, they might be used up. But even if we had slots >> available, the memory range that needs to be covered is in large >> enough address and aligned in such a way that you cannot cover it with >> variable range MTRRs. > > Actually, if I'm not mistaken, you only need to cover the HT hole with > one MTRR - the rest remains WB. And in order the mask bits to work, we > could make it a little bigger - we waste some memory but that's nothing > in comparison to the MCE. > > You might need to talk to hw guys about the feasibility of this deal > though. > Just make the hole a bit bigger, so it starts at 0xfc00000000, then you only need one MTRR. This is the correct BIOS-level fix, and it really needs to happen. Do these systems actually exist in the field or are they engineering prototypes? In the latter case, we might be done at that point. Really, though, AMD should have added a TOM3 for memory above the 1T mark since they should have been able to see a 1T hole coming from the design of HyperTransport. This would be the correct hardware-level fix, but I don't expect that to happen. Now, calming down a little bit, we are definitely dealing with BIOS engineers and so f*ckups are going to happen, again and again. The question is what to do about it. The only truly "safe" option is to limit early mappings to 4K pages. This is highly undesirable for a bunch of reasons. Reducing mapping granularity to 2M rather than 1G (what Yinghai is proposing) does reduce the exposure somewhat; it would be interesting to gather trap statistics and try to get a feel for if this actually changes the boot time measurably or not. The other bit is that building the real kernel page tables iteratively (ignoring the early page tables here) is safer, since the real page table builder is fully aware of the memory map. This means any "spillover" from the early page tables gets minimized to regions where there are data objects that have to be accessed early. Since Yinghai already had iterative page table building working, I don't see any reason to not use that capability. Thoughts? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html