Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752888AbcD2J1B (ORCPT ); Fri, 29 Apr 2016 05:27:01 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:35657 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752165AbcD2J07 (ORCPT ); Fri, 29 Apr 2016 05:26:59 -0400 Date: Fri, 29 Apr 2016 10:26:51 +0100 From: Matt Fleming To: Borislav Petkov Cc: Ingo Molnar , Stephen Rothwell , "Luis R. Rodriguez" , Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , Stefano Stabellini , Xen Devel , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Shannon Zhao , Ard Biesheuvel Subject: Re: efi_enabled(EFI_PARAVIRT) use Message-ID: <20160429092651.GD2839@codeblueprint.co.uk> References: <20160429142020.4499e185@canb.auug.org.au> <20160429063936.GA28320@gmail.com> <20160429082501.GA20762@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160429082501.GA20762@pd.tnic> User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1217 Lines: 29 On Fri, 29 Apr, at 10:25:02AM, Borislav Petkov wrote: > On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote: > > With considerable pain we just got rid of paravirt_enabled() in the > > x86 tree, and Xen is now reintroducing it in the EFI code. > > I think Matt is working towards removing EFI_PARAVIRT but he'll comment > himself when he wakes up... :) Yeah, I haven't actually got around to dropping EFI_PARAVIRT yet but since it's basically used to skip certain initialisation operations on boot I figured we could just provide empty stub functions as part of struct efi (probably). The concerns Ingo voiced about EFI_PARAVIRT being a catch-all flag are very true. Incidentally kexec and arm64 would need a similar stub functions if we move more EFI runtime setup code to drivers/firmware/efi, which is my long-term plan, since neither can call SetVirtualAddressMap(). On x86, I think EFI_PARAVIRT is code for, 1. Has no EFI memory map 2. Runtime regions do not need to be mapped 3. Cannot call SetVirtualAddressMap() 4. /sys/firmware/efi/fw_vendor is invisible 1. and 2. should be covered by never setting EFI_MEMMAP and EFI_RUNTIME_SERVICES in efi.flags. We have no bits for 3. and 4. yet.