Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1362855 > unrolled thread

Re: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is disabled

Started byBorislav Petkov <bp@suse.de>
First post2016-03-22 18:10 +0100
Last post2016-03-22 22:20 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is  disabled Borislav Petkov <bp@suse.de> - 2016-03-22 18:10 +0100
    Re: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is  disabled Toshi Kani <toshi.kani@hpe.com> - 2016-03-22 22:20 +0100

#1362855 — Re: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is disabled

FromBorislav Petkov <bp@suse.de>
Date2016-03-22 18:10 +0100
SubjectRe: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is disabled
Message-ID<rfxYC-7FK-7@gated-at.bofh.it>
Subject: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is disabled

s/ MSR//

On Wed, Mar 16, 2016 at 06:46:57PM -0600, Toshi Kani wrote:
> get_mtrr_state() calls pat_init() on BSP even if MTRR is disabled
> by its MSR.

s/by its MSR//

> This causes pat_init() to be called on BSP only since APs do not call

This doesn't cause that - get_mtrr_state() is called only on the BSP by
mtrr_bp_init().

> pat_init() when MTRR is disabled. This inconsistency between BSP and
> APs leads undefined behavior.

      leads to


> Move BSP's PAT init code from get_mtrr_state() to mtrr_bp_pat_init().
> Change mtrr_bp_init() to call mtrr_bp_pat_init() if MTRR is enabled.

No need for those.

> This keeps BSP's calling condition to pat_init() consistent with AP's,
> mtrr_ap_init() and mtrr_aps_init().

This one is fine.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [next] | [standalone]


#1363003

FromToshi Kani <toshi.kani@hpe.com>
Date2016-03-22 22:20 +0100
Message-ID<rfBSy-1PB-9@gated-at.bofh.it>
In reply to#1362855
On Tue, 2016-03-22 at 18:01 +0100, Borislav Petkov wrote:
> Subject: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is
> disabled
> 
> s/ MSR//

Will do.

> On Wed, Mar 16, 2016 at 06:46:57PM -0600, Toshi Kani wrote:
> > get_mtrr_state() calls pat_init() on BSP even if MTRR is disabled
> > by its MSR.
> 
> s/by its MSR//

Will do.

> > This causes pat_init() to be called on BSP only since APs do not call
> 
> This doesn't cause that - get_mtrr_state() is called only on the BSP by
> mtrr_bp_init().

Right, I will change it to "results" or something.

> > pat_init() when MTRR is disabled. This inconsistency between BSP and
> > APs leads undefined behavior.
> 
>       leads to

Will do.

> > Move BSP's PAT init code from get_mtrr_state() to mtrr_bp_pat_init().
> > Change mtrr_bp_init() to call mtrr_bp_pat_init() if MTRR is enabled.
> 
> No need for those.

OK.

> > This keeps BSP's calling condition to pat_init() consistent with AP's,
> > mtrr_ap_init() and mtrr_aps_init().
> 
> This one is fine.

:-)

Thanks,
-Toshi

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web