Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752688Ab3F0JBC (ORCPT ); Thu, 27 Jun 2013 05:01:02 -0400 Received: from mail-we0-f171.google.com ([74.125.82.171]:61546 "EHLO mail-we0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752037Ab3F0JA6 (ORCPT ); Thu, 27 Jun 2013 05:00:58 -0400 Date: Thu, 27 Jun 2013 11:00:50 +0200 From: Leif Lindholm To: Matthew Garrett Cc: James Bottomley , Matt Fleming , Grant Likely , Stephen Warren , "linux-arm-kernel@lists.infradead.org" , linux-efi@vger.kernel.org, "linux-doc@vger.kernel.org" , Linux Kernel Mailing List , "patches@linaro.org" , "H. Peter Anvin" , Thomas Gleixner , matt.fleming@intel.com Subject: Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services Message-ID: <20130627090050.GC18151@rocoto.smurfnet.nu> References: <1372183863-11333-1-git-send-email-leif.lindholm@linaro.org> <1372183863-11333-2-git-send-email-leif.lindholm@linaro.org> <51CA2B03.4080106@wwwdotorg.org> <20130626135311.GA9078@rocoto.smurfnet.nu> <20130626135933.GQ22026@console-pimps.org> <1372257499.2168.5.camel@dabdike> <20130627013219.GA346@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130627013219.GA346@srcf.ucam.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1408 Lines: 29 On Thu, Jun 27, 2013 at 02:32:19AM +0100, Matthew Garrett wrote: > On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote: > > The fixed virtual address scheme currently being looked at for x86_64 to > > make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit > > because the address space isn't big enough. For ARM, given that we've > > much more opportunity to work with the vendors, can we just avoid > > transitioning to a virtual address map and always just install a > > physical mapping before doing efi calls? > > We can probably get away with that now, but it does risk us ending up > with some firmware that expects to run in physical mode (boards designed > for Linux) and some firmware that expects to run in virtual mode (boards > designed for Windows). The degree of lockdown in the Windows ecosystem > at present means it's not a real problem at the moment, but if that ever > changes we're going to risk incompatibility. Is there anything preventing calling SetVirtualAddressMap() with a 1:1 map? Or do you simply mean that some platforms might cruise along with undetected bugs in their relocation hooks? / Leif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/