OSDev.org

In the Intel manuals is stated that system memory locations are not cached when a Write Combining (WC) caching scheme is used. Could anyone please tell which are the system memory locations?

Hi,

limp wrote:In the Intel manuals is stated that system memory locations are not cached when a Write Combining (WC) caching scheme is used. Could anyone please tell which are the system memory locations?

The system memory locations are whichever areas of the physical address space you've set to "write-combining". This could be none of them (default), or all of them (not recommended), or maybe just the area/s that correspond to video display memory, or whatever else you (or your device drivers) feel like.


Cheers,

Brendan

Thanks a lot Brendan,

Brendan wrote: The system memory locations are whichever areas of the physical address space you've set to "write-combining". This could be none of them (default), or all of them (not recommended), or maybe just the area/s that correspond to video display memory, or whatever else you (or your device drivers) feel like.

Do you happen to know if the same applies for Strong Uncacheable (UC) memory?

Intel manuals say:

Strong Uncacheable (UC) —System memory locations are not cached. All reads and writes appear on the system bus and are executed in program order without reordering.

So, would the above mean that only physical address space that is set to "write-combining" cache mode will not be cached? I haven't found a definition of a "system memory location" in the manuals. May I ask where did you get yours?

Kind regards.

A system is the entirety of a construct that operates according to certain rules.

In a computer system the processor is only a part of the whole, that includes RAM and hardware. Thus, a memory location in the system is anything that can be addressed as memory.

Hi,

limp wrote:

Brendan wrote:The system memory locations are whichever areas of the physical address space you've set to "write-combining". This could be none of them (default), or all of them (not recommended), or maybe just the area/s that correspond to video display memory, or whatever else you (or your device drivers) feel like.

Do you happen to know if the same applies for Strong Uncacheable (UC) memory?

When the CPU is first started everything is "Strong Uncacheable (UC)" (mostly because the default state for the MTRRs is "everything disabled"). Then the firmware runs and does a bunch of things; including pre-configuring the MTRRs.

By the time an OS is started there's only 3 things you need to know:

• Usable RAM should be "write-back (WB)"
• Any areas that the firmware thinks is special for whatever reason is setup however the firmware felt like (but the OS shouldn't be touching these areas and has no reason to care what the firmware did). Note: For PC BIOS, this includes the legacy VGA area from 0x000A0000 to 0x000BFFFF, which is typically also used for SMM RAM and therefore the corresponding MTRRs should not be messed with by an OS.
• Any other areas (that are not usable RAM and not "special") should be "Strong Uncacheable (UC)". Note: This includes areas used by memory mapped PCI devices (e.g. the video card's actual display memory, which should not be confused with the legacy VGA area).

limp wrote:Intel manuals say:

Strong Uncacheable (UC) —System memory locations are not cached. All reads and writes appear on the system bus and are executed in program order without reordering.

So, would the above mean that only physical address space that is set to "write-combining" cache mode will not be cached?

I'd hope that "Strong Uncacheable" areas wouldn't be cached either...

limp wrote:I haven't found a definition of a "system memory location" in the manuals. May I ask where did you get yours?

Just replace the words "system memory location" with "whatever is at the physical address/es". For example:

"Strong Uncacheable (UC) - Whatever is at the physical addresses is not cached. All reads and writes appear on the system bus and are executed in program order without reordering."


Cheers,

Brendan