Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMemerror

[H. Peter Anvin]

Venki Pallipadi wrote:
> What I meant was:
> MTRRs are not really base and size. They are defined as base and mask.
> Any addr is affected by mtrr if addr & mask == base & mask.
> So, MTRR entry like
> base = 0xf00000, mask = 0xff00000 with 36 bit physical address covers
> 0xf00000-0xffffff, 0x10f00000-0x10ffffff, 0x20f00000-0x20ffffff, ....
>
> In this case if user is trying to mmap 0x1a000000-0x2a000000, we cannot really
> cover this case with single parsing of variable address ranges. We will have
> to go through the sub-ranges withing single variable range, which can be page
> by page in worst case.
>  

In practice, though, such MTRRs are never seen.  Even in the presence of 
such pathological MTRRs, I'm sure one can figure out a *much* smarter 
overlap algorithm.  I'd have to sit down and think about it, but I'm 
pretty sure one could; the basic observation, though, is that any set 
mask bit that are in a position <= floor(log2(range_len))-1 don't matter 
at all, since the range WILL end up covering both the 0 and the 1 case 
in this bit position.  At this point, you can test only a limited number 
of points (I *believe* you can reduce it down to only the beginning and 
the end, but I haven't proven that, so don't count on it yet.)

The key, of course, is to look for the case of multiple MTRRs matching 
the range.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/