OSDev.org

Ya I am starting to think this is a premature optimization and that it will just add complexity (two code paths) I do not need at this point. I might just revert the work I have done so far.

kzinti wrote:Ya I am starting to think this is a premature optimization and that it will just add complexity (two code paths) I do not need at this point. I might just revert the work I have done so far.

It is actually an elegant idea to let the kernel have linear view of the whole physical space and something 32bit users like me can only imagine. I have to map pages in and out frequently esp. during my naive fork procedure (which is not COW but a deep copy from the beginning).

What bzt and maybe others said above (different page attribute for certain ranges that map to devices) is probably a safer bet though.

That way the CPU is aware that these regions have different attributes all the time.

xeyes wrote:But IMO, this setup (multiple logical apertures with different cache attribute mapped to the same physical memory) is quite risky in terms of correctness. For example the CPU might prefetch when your code accessed something around the cache-able aperture and cause side effect on the MMIO registers within it.

Having multiple apertures with different types isn't itself a risk, since x86 guarantees cache coherency in most cases. You also won't have to worry about side effects on MMIO thanks to the MTRRs preventing caching.

xeyes wrote:It's probably a worse situation to deal with than a SMP system with no hardware cache coherency.

I disagree: on x86, you only have to figure out the correct settings for the cache controls once and then you can forget about it. On architectures without cache coherency, any time you want to pass data between a CPU and some other device on the local bus (whether it's another CPU or some other device) you need to either fight the caches to ensure everyone has a coherent view of memory or disable the cache and suffer a significant performance hit.

I just wrote some code to dump all the fixed and variable MTRR ranges.

What I found is that on 3 different machines, the framebuffer is mapped as UC (Uncacheable). On QEMU I get WB (Writeback), which is technically correct but funny to me for some reason.

So using the PAT with an entry for WC (Write Combining) for the framebuffer seems the easiest way to go about this.

Octocontrabass wrote:You still need to pay at least enough attention to the MTRRs to split large pages that cross memory type boundaries, otherwise you'll get undefined behavior.

I am assuming firmware will not declare MMIO space as "usable memory". My linear mapping only extends to physical RAM, and whatever IO space is needed is mapped separately. Still in the linear range, but in separate mappings. Precisely because of this undefined behavior stuff.