From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754702AbcDICEt (ORCPT <rfc822;w@1wt.eu>);
	Fri, 8 Apr 2016 22:04:49 -0400
Received: from mx2.suse.de ([195.135.220.15]:56350 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752195AbcDICEr (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 8 Apr 2016 22:04:47 -0400
Date: Sat, 9 Apr 2016 04:04:44 +0200
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Toshi Kani <toshi.kani@hpe.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>, Juergen Gross <jgross@suse.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Matt Fleming <matt@codeblueprint.co.uk>,
        Olof Johansson <olof@lixom.net>, Paul Stewart <pstew@chromium.org>,
        Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
        Paul Gortmaker <paul.gortmaker@windriver.com>,
        Paul McKenney <paulmck@linux.vnet.ibm.com>, X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        xen-devel@lists.xensource.com
Subject: Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code
Message-ID: <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>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1458251807.6393.474.camel@hpe.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

  Luis