From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758038AbbICWqA (ORCPT ); Thu, 3 Sep 2015 18:46:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:53927 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753026AbbICWp6 (ORCPT ); Thu, 3 Sep 2015 18:45:58 -0400 Date: Fri, 4 Sep 2015 00:45:56 +0200 From: "Luis R. Rodriguez" To: Toshi Kani Cc: Prarit Bhargava , Stuart Hayes , tglx@linutronix.de, mingo@redhat.com, "H. Peter Anvin" , linux-kernel@vger.kernel.org, x86@kernel.org, mcgrof@do-not-panic.com, Toshi Kani , Jan Beulich , Juergen Gross Subject: Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup Message-ID: <20150903224556.GY8051@wotan.suse.de> References: <20150903024542.GS8051@wotan.suse.de> <55E83A3E.3030000@redhat.com> <20150903175902.GU8051@wotan.suse.de> <55E88D06.3040608@redhat.com> <20150903184029.GV8051@wotan.suse.de> <1441308162.3277.20.camel@hpe.com> <20150903195134.GW8051@wotan.suse.de> <1441315902.3277.39.camel@hpe.com> <20150903220711.GX8051@wotan.suse.de> <1441319131.3277.54.camel@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441319131.3277.54.camel@hpe.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 03, 2015 at 04:25:31PM -0600, Toshi Kani wrote: > On Fri, 2015-09-04 at 00:07 +0200, Luis R. Rodriguez wrote: > : > > These are still at odds, for instance, I was under the impression we can > > just have the OS return MTRR_TYPE_INVALID if the OS / drivers never used > > or set up MTRR, but the platform did, above (not the patch) you seem to be > > saying that even if the OS didn't modify MTRRs the OS still needs to return > > the appropriately set up MTRR type by firmware. This is different. Can you > > clarify? > > mtrr_type_lookup() returns valid MTRR cache type for a given address range > when MTRRs are enabled. It does not matter if MTRRs are set by the firmware > or the OS. When MTRRs are enabled, the kernel needs to check through > mtrr_type_lookup() that large page mapping requests are aligned with MTRRs. One further change I was considering was seeing if we can separate PAT set up from MTRR's setup, but that was under the assumption we could live with a kernel that would have mtrr_type_lookup() return MTRR_TYPE_INVALID if kernel MTRR code is completely disabled but PAT enabled. We can't enable PAT today without MTRR beceause PAT is initialized from the MTRR init sequence and that depends on MTRR, if we separated these though and and if a distro disabled kernel MTRR an but enabled PAT and if MTRR did set up MTRR what would the possible issues be? > On Xen, When Xen is used a platform firmware may still set up MTRR, even if the hypervisor doesn't set up MTRR right ? So same issue and question here. > or on a platform with firmware that does not enable MTRRs, > mtrr_type_lookup() returns MTRR_TYPE_INVALID (as long as the kernel does not > enable them). Sure this makes sense. Thanks in advance, Luis