Message-ID: <1458336958.6393.544.camel@hpe.com>
Subject: Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code
From: Toshi Kani <toshi.kani@hpe.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Matt Fleming <matt@codeblueprint.co.uk>,
        Paul Gortmaker <paul.gortmaker@windriver.com>,
        Borislav Petkov <bp@alien8.de>, X86 ML <x86@kernel.org>,
        Paul Stewart <pstew@chromium.org>, Ingo Molnar <mingo@kernel.org>,
        Olof Johansson <olof@lixom.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Juergen Gross <jgross@suse.com>
Date: Fri, 18 Mar 2016 15:35:58 -0600
In-Reply-To: <CAB=NE6VqANJgQb_U1qO=ScfxaN1=e+T-vyeKPNWDAjmLFUhV8w@mail.gmail.com>
References: <1457671546-13486-1-git-send-email-toshi.kani@hpe.com>
	 <1457671546-13486-3-git-send-email-toshi.kani@hpe.com>
	 <20160311092400.GB4347@pd.tnic> <1457722632.6393.130.camel@hpe.com>
	 <20160311221747.GC25147@wotan.suse.de> <1457740571.6393.236.camel@hpe.com>
	 <CAB=NE6UE7pKz8bmpRrFmAW=ySY0JnGoRY=MYn2zfOH4g_H81hw@mail.gmail.com>
	 <1457745396.6393.257.camel@hpe.com> <20160315001501.GF25147@wotan.suse.de>
	 <1458085724.6393.425.camel@hpe.com> <20160315232916.GJ1990@wotan.suse.de>
	 <1458251807.6393.474.camel@hpe.com>
	 <CAB=NE6VqANJgQb_U1qO=ScfxaN1=e+T-vyeKPNWDAjmLFUhV8w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2719
Lines: 64

On Thu, 2016-03-17 at 17:06 -0700, Luis R. Rodriguez wrote:
> On Mar 17, 2016 2:04 PM, "Toshi Kani" <toshi.kani@hpe.com> wrote:
> > 
> > On Wed, 2016-03-16 at 00:29 +0100, Luis R. Rodriguez wrote:
> > > On Tue, Mar 15, 2016 at 05:48:44PM -0600, Toshi Kani wrote:
> > > > On Tue, 2016-03-15 at 01:15 +0100, Luis R. Rodriguez wrote:
> > > > > On Fri, Mar 11, 2016 at 06:16:36PM -0700, Toshi Kani wrote:
> > > > > > 
> >  :
> > > > MTRR code does not have to be dead for the virtual machines with no
> > > > MTRR support.  The code just needs to handle the disabled case
> > > > properly.  I consider this is part of 1) that the kernel keeps the
> > > > MTRR state as disabled.
> > > 
> > > For Xen it was possible to use PAT without any of the MTRR code
> > > running, I don't see why its needed then and why other virtual
> > > machines that only need PAT need it.
> > 
> > Virtual BIOS does not need MTRRs since it does not manage the platform.
> 
> Unless if in dom0 and if some of this purposely wants to be punted
> there to leverage existing kernel code. On the Xen thread I'm asking
> about the implications of that and how/if Xen should be doing. We can
> follow up on this there as its Xen specific.

I do not see any issue for Xen, but sure, we can discuss about Xen in a
separate thread.


 :
> > > On x86 Linux code we now have ioremap_uc() that can't use MTRR behind
> > > the scenes, why would something like this on the BIOS not be
> > > possible? That ultimately uses set_pte_at(). What limitations are
> > > there on the BIOS that prevent us from just using strong UC for PAT
> > > on the BIOS?
> > 
> > Because it requires to run in virtual mode with page tables.
> 
> Ah... interesting... is UC really needed, what is the default? If the
> default is used would there be an issue ? Can such work be deferred to
> a later time ? It seems like a high burden to require on large piece
> of legacy architecture to just blow a fan.

The default cache attribute (i.e. ranges not covered by MTRRs) is specified
by the MTRR default type MSR.

 :
> > > > > > 
> > > MTRR has a bunch of junk that is outside of the scope of the generic
> > > procedure which I'd hope we can skip.
> > 
> > We can skip the part that modifies MTRR setup. I think that is the part
> > you think is a junk.
> 
> Sure, but the more we can avoid any of that code the better. For
> example consider the cleanup patch to increase the chunk size, do we
> even need the cleanup anymore ?

No, I do not think we need it now.  I think this cleanup was needed to
allocate more free slots to MTRRs.  We do not need to care about the number
of free slots as long as the kernel does not insert any new entry to MTRRs.

Thanks,
-Toshi