Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1363003
| From | Toshi Kani <toshi.kani@hpe.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is disabled |
| Date | 2016-03-22 22:20 +0100 |
| Message-ID | <rfBSy-1PB-9@gated-at.bofh.it> (permalink) |
| References | <rdtw6-7MK-1@gated-at.bofh.it> <rdtw6-7MK-5@gated-at.bofh.it> <rfxYC-7FK-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
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
csiph-web