From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751132AbcDOJ7e (ORCPT ); Fri, 15 Apr 2016 05:59:34 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:33995 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750745AbcDOJ7c (ORCPT ); Fri, 15 Apr 2016 05:59:32 -0400 X-IronPort-AV: E=Sophos;i="5.24,486,1454976000"; d="scan'208";a="353934788" Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry To: "Luis R. Rodriguez" References: <20160406024027.GX1990@wotan.suse.de> <20160407185148.GL1990@wotan.suse.de> <20160413195257.GB1990@wotan.suse.de> <570F68AB.2040400@citrix.com> <20160414194408.GP1990@wotan.suse.de> CC: Matt Fleming , , 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 , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= From: George Dunlap Message-ID: <5710BB74.2060409@citrix.com> Date: Fri, 15 Apr 2016 10:59:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160414194408.GP1990@wotan.suse.de> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/04/16 20:44, Luis R. Rodriguez wrote: > 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. Oh -- I read both those lines as, "What if this is *the only option* then?" (which I then interpreted to mean, what if booting EFI is the only thing Linux will accept). The rest of my reply is based on that misunderstanding. Sorry about that. Regarding the second one -- I wasn't talking about actual non-Linux unikernels; I was talking about using Linux in the way that unikernels are used ("unikernel-style"). That is, you boot a minimal Linux image with a small ramdisk and have a single process running as init. For this use case, even an extra megabyte of guest RAM and an extra second of boot time is a significant cost. "Use OVMF for domUs" is an excellent solution for traditional VMs where you boot a full distro, but would impose a significant cost on using Linux in unikernel-style VMs. Whether a stripped-down EFI support would be sufficiently low memory / latency for such workloads is an open question that would take time and engineering effort to discover. And in any case, it would certainly require the maintenance of Yet Another Bootloader in the Xen source tree. -George