* Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:The logic we ideally would like to have is something like this: find _any_ RAM that is not mapped via any MTRRs (be that special MTRR extensions like Tom2) and clear that from the e820 maps. not just 'end of RAM'. And in that sense the amd_special_default_mtrr() check is wrong, because it just checks that Tom2 is set and then does no other checking. And the original MTRR check is wrong too because it just finds the highest cacheable MTRR-covered address and compares that to the kernel-known end of RAM. what we should probably do instead is to have a filter function: new_end = trim_range_to_mtrr_cached(start, end); and then we could iterate through every e820 map entry that is marked as usable RAM, and send it through this filter. If the filter returns the same value that got passed in, we keep the e820 entry unchanged. If the filter returns a new "end" value, we use that in the e820 map. that way, the current Tom2 hack is just a natural extension to the filter function: it would (on AMD CPUs) recognize (within trim_range_to_mtrr_cached filter) that all memory addresses above 4GB are marked as cacheable via Tom2. Or something like this. Hm? Ingo --
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| David Brown | Re: Linux 2.6.21-rc2 |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Justin C. Sherrill | Re: dragonflybsd.org website link? |
git: | |
| Ben Hutchings | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
