Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753055AbcDKOit (ORCPT ); Mon, 11 Apr 2016 10:38:49 -0400 Received: from g1t5424.austin.hp.com ([15.216.225.54]:39885 "EHLO g1t5424.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbcDKOir (ORCPT ); Mon, 11 Apr 2016 10:38:47 -0400 Message-ID: <1460385013.20338.91.camel@hpe.com> Subject: Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code From: Toshi Kani To: "Luis R. Rodriguez" Cc: Juergen Gross , Boris Ostrovsky , Matt Fleming , Olof Johansson , Paul Stewart , Borislav Petkov , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Paul Gortmaker , Paul McKenney , X86 ML , "linux-kernel@vger.kernel.org" , xen-devel@lists.xensource.com Date: Mon, 11 Apr 2016 08:30:13 -0600 In-Reply-To: <20160409020444.GX1990@wotan.suse.de> References: <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> <20160409020444.GX1990@wotan.suse.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1370 Lines: 32 On Sat, 2016-04-09 at 04:04 +0200, Luis R. Rodriguez wrote: > On Thu, Mar 17, 2016 at 03:56:47PM -0600, Toshi Kani wrote: > > > > On Wed, 2016-03-16 at 00:29 +0100, Luis R. Rodriguez wrote: > > > > > > 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. > > I see now. Specifically, BIOSes run in real mode, and PAT uses > paging. Paging requires bit 31 on CR0 set (PG), and PG has no > effect if the PE flag (Protection Enable) bit 0 on CR0 is clear. > If PE is clear we have real mode, which is what the BIOS uses. > > Stupid question then: > > are there no use case for a BIOS to enter PE, even if just > limited to set paging attributes for instance. For the simple > sake of burying MTRR this seems worthy, but I wonder if there > are other paging needs a BIOS might find use for. The OS calls EFI in virtual mode.  BIOS SMI handler, however, is called in physical mode.  Since it has the highest priority, it needs to finish as soon as possible.  So, it typically does not make additional steps to switch to virtual mode. Thanks, -Toshi