Messages in this thread | | | Subject | Re: [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table | From | Toshi Kani <> | Date | Tue, 15 Mar 2016 16:02:00 -0600 |
| |
On Tue, 2016-03-15 at 12:00 +0100, Borislav Petkov wrote: > On Mon, Mar 14, 2016 at 03:37:23PM -0600, Toshi Kani wrote: > > Your patch is a simplified version of mine. So, yes, it fixes the > > Paul's issue, but it does not address other issues that my patchset > > also addressed. In specific, I think your patch has the following > > issues. > > You couldnt've structured your reply better: remember how I split a > convoluted patch of yours already? A patch which was trying to do a > bunch of things in one go. > > The situation here is the same. You need to do *one* *logical* > *non-trivial* thing in a patch. If there's something else that needs to > be done, add it in a *separate* patch which explains why that new change > is needed.
Got it!
> > - pat_disable() is now callable from other modules. So, it needs to > > check with boot_cpu_done. We cannot disable PAT once it is initialized. > > That should be a separate patch which explains *why* the change is being > done. > > > - mtrr_bp_init() needs to check with mtrr_enabled() when it > > calls mtrr_pat_setup_bp(). Otherwise, PAT is left initialized on BSP > > only when MTRR is disabled by its MSR. In your patch, mtrr_bp_init() > > calls pat_setup() again, but it does not help since boot_cpu_done is > > set. > > The code which you carved out from get_mtrr_state() didn't check > mtrr_enabled() before. That needs to be another patch *again* with > explanations. > > > - When PAT is disabled in CPU feature, pat_bsp_init() calls > > pat_disable() and returns. However, it does not initialize a PAT table > > by calling pat_init_cache_modes(). > > Yet another patch. > > > - When CONFIG_MTRR is unset, it does not call pat_setup(). > > Aaaand... can you guess what I'm going to say here? > > I hope it is coming across as I intend it: please use my hunk to do a > single fix and then prepare all those changes above in separate patches > with explanations:
Unfortunately, this single fix will break Xen. So, I think we will need to make a few enhancements first before making the fix.
> "Problem is A. We need to do B. I'm doing it/I'm doing C because." > > Ok?
Yes, I will try to separate the patches to change one logical thing at a time.
Thanks, -Toshi
| |