Re: [PATCH] x86/mtrr: Correct the returned MTRR type of mtrr_type_lookup.

From: Borislav Petkov <bp@alien8.de>
To: Ying-Tsun Huang <ying-tsun.huang@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Alexandre Chartre <alexandre.chartre@oracle.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Toshi Kani <toshi.kani@hp.com>,
	linux-kernel@vger.kernel.org,
	Dmitry Lapik <dmitry.kolyadintsev@nyriad.com>,
	James Lee <James.Lee@amd.com>
Subject: Re: [PATCH] x86/mtrr: Correct the returned MTRR type of mtrr_type_lookup.
Date: Fri, 11 Dec 2020 11:52:39 +0100	[thread overview]
Message-ID: <20201211105239.GA25974@zn.tnic> (raw)
In-Reply-To: <20201207061227.131580-1-ying-tsun.huang@amd.com>

On Mon, Dec 07, 2020 at 02:12:26PM +0800, Ying-Tsun Huang wrote:
> In mtrr_type_lookup, if the input memory address region is not in the
> MTRR, over 4GB, and not over the top of memory, write-back attribute
> is returned. These condition checks are for ensuring the input memory
> address region is mapped to the physical memory actually.
> 
> However, if the end address is just aligned with the top of memory,
> the condition check treats the address is over the top of memory, and
> write-back attribute is not returned.

Oh fun. So to make sure I understand this correctly end ends up equal to
TOM2?

> There is a real case of NVDIMM. The nd_pmem module tries to map
> NVDIMMs as cacheable memories when NVDIMMs are connected. If a NVDIMM
> is the last of the DIMMs, the performance of this NVDIMM becomes very
> low since it aligned with the top of memory and its memory type is
> uncached-minus.
> 
> To check the top of memory should use "<=" instead of "<" since both the
> input end address and the value of top of memory are actually the start
> of next region.

Right, so looking at that function, it calls
mtrr_type_lookup_variable(), among others, and that does:

        /* Make end inclusive instead of exclusive */
        end--;

which sounds to me like it expects ranges with exclusive end.

So maybe it would be better to do something like:

	/*
	 * Blurb about end address being == tom2, perhaps give your example
	 */
	end--;

above the check so that it is absolutely obvious why this is done.

But but, looking at this more, the PPR says about TOM2:

"This value is normally placed above 4G. From 4G to TOM2 - 1 is DRAM;
TOM2 and above is MMIO."

So the check is *actually* correct - TOM2 - 1 is DRAM so you need '<'.

Unless you do end-- before, which would make sense and suggest the end
decrement to be the proper fix.

Hmm?

> Fixes: b73522e0c1be ("x86/mm/mtrr: Enhance MTRR checks in kernel mapping
> helpers")

I think you mean:

35605a1027ac ("x86: enable PAT for amd k8 and fam10h")

which first added that check.

Btw, while doing git archeology, I saw that mtrr_type_lookup() used to do end--
on function entry, see

2e5d9c857d4e ("x86: PAT infrastructure patch")

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette