1

Why the check mechanism is changed? Because of the MTRR code upgrade? Or was that a bug in checking before?

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/x86/mm/pgtable.c?h=v6.5.7&id=12f0dd8df14285a5604f35ed3af8b8c33e8fd97f

x86/mm: Only check uniform after calling mtrr_type_lookup()
Today pud_set_huge() and pmd_set_huge() test for the MTRR type to be
WB or INVALID after calling mtrr_type_lookup().

Those tests can be dropped as the only reason not to use a large mapping
would be uniform being 0.

Any MTRR type can be accepted as long as it applies to the whole memory
range covered by the mapping, as the alternative would only be to map
the same region with smaller pages instead, using the same PAT type as
for the large mapping.
0

1 Answer 1

2

The code was changed because the semantics of uniform weren’t correct. This was discovered in an earlier iteration of the patchset; Juergen Gross asked

The problem arises in case a large mapping is spanning multiple MTRRs, even if they define the same caching type (uniform is set to 0 in this case).

So the basic question for me is: shouldn't the semantics of uniform be adpated? Today it means "the range is covered by only one MTRR or by none". Looking at the use cases I'm wondering whether it shouldn't be "the whole range has the same caching type".

to which Linus Torvalds replied

Oh, I think then you should fix uniform to be 1.

IOW, we should not think "multiple MTRRs" means "non-uniform". Only "different actual memory types" should mean non-uniformity.

If I remember correctly, there were good reasons to have overlapping MTRR's. In fact, you can generate a single MTRR that described a memory ttype that wasn't even contiguous if you had odd memory setups.

Intel definitely defines how overlapping MTRR's work, and "same types overlaps" is documented as a real thing.

This led to the patch you’re asking about, which is marked as suggested by Linus.

(In such circumstances, to find the email which counts as the suggestion, look for emails from the suggester to the patch author.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .