All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2020-12-11 10:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-07  6:12 [PATCH] x86/mtrr: Correct the returned MTRR type of mtrr_type_lookup Ying-Tsun Huang
2020-12-11 10:52 ` Borislav Petkov [this message]
2020-12-15  6:16   ` Huang, Ying-Tsun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201211105239.GA25974@zn.tnic \
    --to=bp@alien8.de \
    --cc=James.Lee@amd.com \
    --cc=alexandre.chartre@oracle.com \
    --cc=dmitry.kolyadintsev@nyriad.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hp.com \
    --cc=x86@kernel.org \
    --cc=ying-tsun.huang@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.