[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160429092651.GD2839@codeblueprint.co.uk>
Date: Fri, 29 Apr 2016 10:26:51 +0100
From: Matt Fleming <matt@...eblueprint.co.uk>
To: Borislav Petkov <bp@...en8.de>
Cc: Ingo Molnar <mingo@...nel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Stefano Stabellini <stefano.stabellini@...citrix.com>,
Xen Devel <Xen-devel@...ts.xensource.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
Shannon Zhao <shannon.zhao@...aro.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: efi_enabled(EFI_PARAVIRT) use
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.
Powered by blists - more mailing lists