From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755620Ab2LLAjH (ORCPT ); Tue, 11 Dec 2012 19:39:07 -0500 Received: from terminus.zytor.com ([198.137.202.10]:39434 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753788Ab2LLAjC (ORCPT ); Tue, 11 Dec 2012 19:39:02 -0500 Message-ID: <50C7D1CF.70304@zytor.com> Date: Tue, 11 Dec 2012 16:37:35 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yinghai Lu CC: Borislav Petkov , "Yu, Fenghua" , "mingo@kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "hpa@linux.intel.com" , "linux-tip-commits@vger.kernel.org" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU References: <3E5A0FA7E9CA944F9D5414FEC6C71220470F154E@ORSMSX105.amr.corp.intel.com> <50C6AB63.9070008@zytor.com> <50C6D3DF.3030209@zytor.com> <20121211145716.GB8873@liondog.tnic> <50C763C2.5020603@zytor.com> <20121211170605.GD28827@liondog.tnic> <50C76F9E.4080001@zytor.com> <50C7C859.60405@zytor.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/11/2012 04:27 PM, Yinghai Lu wrote: > On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin wrote: >> Well, we could invoke it on the bootloader page tables, but as you say >> it may not be a good idea... depending on how much memory we may be >> talking about. One solution -- which I have to admit is starting to >> sound really good -- is to set up a #PF handler which cycles through a >> set of page tables and creates a "virtual identity map"... it does have >> the advantage of making the entire physical address space available >> without any additional funnies. > > so that #PF handler will work before > arch/x86/kernel/setup.c::setup_arch/early_trap_init > > early_strap_intit will install another handler there for #PF > > for 64bit, moving early_ioremap_init ahead is very simple, like attach patch > > but for 32 bit looks like it is not that easy. > For 32 bits, we don't need it, because we can just run this part in linear mode. It also doesn't help us on 32 bits since we are limited by virtual address space anyway. -hpa