[PATCH] x86: Avoid using hardcoded number of variable range MTRRs in mtrr_commit()

Since commit 29d2d64ed55f ("x86: Add support for more than 8 MTRRs"), the maximum number of variable range MTRRs was increased from 8 to 10, which caused a #GP exception during VESA video driver probe.
On the BayTrail platform there are only 8 variable range MTRRs. In mtrr_commit() it still uses MTRR_MAX_COUNT which should have been updated to use dynamically probed number.
This fixes the boot failure seen on Intel Minnow Max board.
Fixes: 29d2d64ed55f ("x86: Add support for more than 8 MTRRs") Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/mtrr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/cpu/mtrr.c b/arch/x86/cpu/mtrr.c index 5180eb0..6f095c5 100644 --- a/arch/x86/cpu/mtrr.c +++ b/arch/x86/cpu/mtrr.c @@ -158,7 +158,7 @@ int mtrr_commit(bool do_caches)
/* Clear the ones that are unused */ debug("clear\n"); - for (; i < MTRR_MAX_COUNT; i++) + for (; i < mtrr_get_var_count(); i++) wrmsrl(MTRR_PHYS_MASK_MSR(i), 0); debug("close\n"); mtrr_close(&state, do_caches);

Hi Bin,
On Mon, 9 Nov 2020 at 01:05, Bin Meng bmeng.cn@gmail.com wrote:
Since commit 29d2d64ed55f ("x86: Add support for more than 8 MTRRs"), the maximum number of variable range MTRRs was increased from 8 to 10, which caused a #GP exception during VESA video driver probe.
On the BayTrail platform there are only 8 variable range MTRRs. In mtrr_commit() it still uses MTRR_MAX_COUNT which should have been updated to use dynamically probed number.
This fixes the boot failure seen on Intel Minnow Max board.
Fixes: 29d2d64ed55f ("x86: Add support for more than 8 MTRRs") Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/mtrr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
I don't actually see the boot failure in my lab, but this looks right to me.
Regards, Simon

Hi Simon,
On Tue, Nov 10, 2020 at 12:05 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 9 Nov 2020 at 01:05, Bin Meng bmeng.cn@gmail.com wrote:
Since commit 29d2d64ed55f ("x86: Add support for more than 8 MTRRs"), the maximum number of variable range MTRRs was increased from 8 to 10, which caused a #GP exception during VESA video driver probe.
On the BayTrail platform there are only 8 variable range MTRRs. In mtrr_commit() it still uses MTRR_MAX_COUNT which should have been updated to use dynamically probed number.
This fixes the boot failure seen on Intel Minnow Max board.
Fixes: 29d2d64ed55f ("x86: Add support for more than 8 MTRRs") Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/mtrr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
I don't actually see the boot failure in my lab, but this looks right to me.
That's weird :)
Regards, Bin

On Tue, Nov 10, 2020 at 12:05 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 9 Nov 2020 at 01:05, Bin Meng bmeng.cn@gmail.com wrote:
Since commit 29d2d64ed55f ("x86: Add support for more than 8 MTRRs"), the maximum number of variable range MTRRs was increased from 8 to 10, which caused a #GP exception during VESA video driver probe.
On the BayTrail platform there are only 8 variable range MTRRs. In mtrr_commit() it still uses MTRR_MAX_COUNT which should have been updated to use dynamically probed number.
This fixes the boot failure seen on Intel Minnow Max board.
Fixes: 29d2d64ed55f ("x86: Add support for more than 8 MTRRs") Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/mtrr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
applied to u-boot-x86, thanks!
participants (2)
-
Bin Meng
-
Simon Glass