From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toshi Kani Subject: Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Date: Fri, 18 Mar 2016 15:35:58 -0600 Message-ID: <1458336958.6393.544.camel@hpe.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> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: "Luis R. Rodriguez" Cc: Boris Ostrovsky , "xen-devel@lists.xensource.com" , Thomas Gleixner , Matt Fleming , Paul Gortmaker , Borislav Petkov , X86 ML , Paul Stewart , Ingo Molnar , Olof Johansson , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Juergen Gross List-Id: xen-devel@lists.xenproject.org On Thu, 2016-03-17 at 17:06 -0700, Luis R. Rodriguez wrote: > On Mar 17, 2016 2:04 PM, "Toshi Kani" wrote: > >=20 > > 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: > > > > > >=C2=A0 > > =C2=A0: > > > > MTRR code does not have to be dead for the virtual machines wit= h no > > > > MTRR support.=C2=A0=C2=A0The code just needs to handle the disa= bled case > > > > properly.=C2=A0=C2=A0I consider this is part of 1) that the ker= nel keeps the > > > > MTRR state as disabled. > > >=20 > > > 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. > >=20 > > Virtual BIOS does not need MTRRs since it does not manage the platf= orm. >=20 > 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. =C2=A0: > > > On x86 Linux code we now have ioremap_uc() that can't use MTRR be= hind > > > 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 P= AT > > > on the BIOS? > >=20 > > Because it requires to run in virtual mode with page tables. >=20 > 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 t= o > 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 speci= fied by the MTRR default type MSR. =C2=A0: > > > > > >=C2=A0 > > > MTRR has a bunch of junk that is outside of the scope of the gene= ric > > > procedure which I'd hope we can skip. > >=20 > > We can skip the part that modifies MTRR setup. I think that is the = part > > you think is a junk. >=20 > 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. =C2=A0I think this cleanup was neede= d to allocate more free slots to MTRRs. =C2=A0We do not need to care about t= he number of free slots as long as the kernel does not insert any new entry to MT= RRs. Thanks, -Toshi