Re: MTRRs and PATs
Re: MTRRs and PATs
- Subject: Re: MTRRs and PATs
- From: Derek Kumar <email@hidden>
- Date: Mon, 26 Nov 2007 13:12:48 -0500
Victor,
It's not clear from others that OS X uses the MTRRs/PATs for cache
control. Can you confirm that?
Technically, cacheability attributes for all virtual->physical address
translations are governed by the PAT mechanism. The "classical" PCD
and PWT bits in a pagetable entry, in combination with the PAT bit in
the pagetable entry form a "mux" which selects a field in the
IA32_CR_PAT MSR. For compatibility, the power-on value of that MSR is
such that if the PCD (page cache disable) bit is lit in the PTE, the
page is marked non-cacheable and so on. As I described previously, the
only PAT MSR field that the kernel reprograms currently (Tiger/
Leopard) is the PA6 field, which is set to write combine. Thus, if you
use say IOSetProcessorCacheMode() to request write combining for a
particular virtual page (perhaps mapped to a framebuffer), the PCD and
PAT bits are set in the PTE, thus selecting the PA6 field within the
IA32_CR_PAT MSR, which in turn is programmed for write combining. If
you specify kIOMapInhibitCache, the PCD bit is set in the PTE. (There
are some currently unresolved issues such as X's lack of support for
the strong uncacheable attribute, but that's not immediately relevant)
Currently, a few MTRR ranges may be programmed by firmware (EFI) prior
to control transfer to the kernel, and there's a set of legacy exports
(mtrr_range_add/remove) which can be used to alter the cacheability
attributes for a physical range. I'm unaware of any current use of
these exports--the IOKit APIs do not alter MTRRs at present.
It would help if you clarified the nature of the problem. I understand
if you cannot disclose why you need this information, but if your
ultimate objective is to accurately discover the cacheability
attributes of a virtual or physical range from first principles
(perhaps to debug an issue), you will have to discover the union of
the MTRR and pagetable based cache attributes for that range.
You can identify the MTRRs covering the range in question using the
tools I described in my previous message. To discover the pagetable
based cacheability attributes, you'd have to identify the set of all
pagetables which contain a mapping to the physical address in question
(unless you're confident that it can only be a kernel mapping, in
which case you can restrict yourself to the kernel pagetable). You'd
then examine the relevant pagetable entries to discover the cache
attribute type for each mapping. Note that specifying disparate
cacheability attributes for multiple mappings to the same physical
address is illegal, and can lead to hard to debug problems. If the
MTRR and PAT ranges overlap, there are rules for resolving conflicts.
Contact me if you need to do go down this route, there are internal
tools that can help.
Derek
Victor Vedovato wrote:
Derek - thanks for the excellent response. We can use reggie_se to
set/reset the registers for debugging. It's not clear from others
that OS X uses the MTRRs/PATs for cache control. Can you confirm
that? Thanks again.
Victor
On Nov 20, 2007, at 3:17 PM, Derek Kumar wrote:
reggie_se -r -a 0x277 -B 64
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden