Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751358AbcDNToN (ORCPT ); Thu, 14 Apr 2016 15:44:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:41604 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbcDNToM (ORCPT ); Thu, 14 Apr 2016 15:44:12 -0400 Date: Thu, 14 Apr 2016 21:44:08 +0200 From: "Luis R. Rodriguez" To: George Dunlap Cc: "Luis R. Rodriguez" , Matt Fleming , jeffm@suse.com, Michael Chang , Linux Kernel Mailing List , Jim Fehlig , Jan Beulich , "H. Peter Anvin" , Daniel Kiper , the arch/x86 maintainers , Takashi Iwai , =?utf-8?Q?Vojt=C4=9Bch_Pavl=C3=ADk?= , Gary Lin , xen-devel , Jeffrey Cheung , Juergen Gross , Stefano Stabellini , joeyli , Borislav Petkov , Boris Ostrovsky , Charles Arndol , Andrew Cooper , Julien Grall , Andy Lutomirski , David Vrabel , Linus Torvalds , Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160414194408.GP1990@wotan.suse.de> References: <20160406024027.GX1990@wotan.suse.de> <20160407185148.GL1990@wotan.suse.de> <20160413195257.GB1990@wotan.suse.de> <570F68AB.2040400@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570F68AB.2040400@citrix.com> 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: 2717 Lines: 64 On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote: > On 13/04/16 20:52, Luis R. Rodriguez wrote: > > On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote: > >> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez wrote: > >>> So more to it, if the EFI entry already provides a way into Linux > >>> in a more streamlined fashion bringing it closer to the bare metal > >>> boot entry, why *would* we add another boot entry to x86, even if > >>> its small and self contained ? > >> > >> We would avoid using EFI if: > > > > And this is what I was looking for, thanks! > > > >> * Being called both on real hardware and under Xen would make the EFI > >> entry point more complicated > > > > That's on the EFI Linux maintainer to assess. And he seems willing to > > consider this. > > > >> * Adding the necessary EFI support into Xen would be a significant > >> chunk of extra work > > > > This seems to be a good sticking point, but Andi noted another aspect > > of this or redundancy as well. > > > >> * Requiring PVH mode to implement EFI would make it more difficult for > >> other kernes (NetBSD, FreeBSD) to act as dom0s. > > > > What if this is an option only then ? > > > >> > >> * Requiring PVH mode to use EFI would make it more difficult to > >> support unikernel-style workloads for domUs. > > > > What if this is an option only then ? > > So first of all, you asked why anyone would oppose EFI, and this is part > of the answer to that. > > Secondly, you mean "What if this is the only thing the Linux maintainers > will accept?" And you already know the answer to that. No, I meant to ask, would it be possible to make booting HVMLite using EFI be optional ? That way if you already support EFI that can be used on your entires with some small modifications. > How much of a burden it would be on the rest of the open-source > ecosystem (Xen, *BSDs, &c) is a combination of some as-yet unknown facts > (i.e., what a minimal Xen/Linux EFI interface would look like) and a > matter of judgement (i.e., given the same interface, reasonable people > may come to different conclusions about whether the interface is an > undue burden to impose on others or not). > > But I would hope that the Linux maintainers would at least consider the > broader community when weighing their decisions, and not take advantage > of their position of dominance to simply ignore the effect of their > choices on everybody else. This has nothing to do with dominance or anything nefarious, I'm asking simply for a full engineering evaluation of all possibilities, with the long term in mind. Not for now, but for hardware assumptions which are sensible 5 years from now. Luis