Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752986AbcDORRS (ORCPT ); Fri, 15 Apr 2016 13:17:18 -0400 Received: from mx2.suse.de ([195.135.220.15]:35344 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752537AbcDORRR (ORCPT ); Fri, 15 Apr 2016 13:17:17 -0400 Date: Fri, 15 Apr 2016 19:17:15 +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: <20160415171715.GB1990@wotan.suse.de> 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> <5710BB74.2060409@citrix.com> <20160415153028.GX1990@wotan.suse.de> <571110BB.2000408@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <571110BB.2000408@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: 2660 Lines: 58 On Fri, Apr 15, 2016 at 05:03:07PM +0100, George Dunlap wrote: > On 15/04/16 16:30, Luis R. Rodriguez wrote: > > On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote: > >> On 14/04/16 20:44, Luis R. Rodriguez wrote: > >>> 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. > >> > >> 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. > > > > Understood. > > > >> 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. > > > > OVMF is used by ARM, so using it should be a matter of adaptation, and > > some changes other than perhaps DT use. Question still stands though, > > would it be possible to have HVMLite be using EFI as an option so that > > some users could opt-in if they so wish ? > > Well we definitely intend go have a mode of PVH* which boots OVMF to > EFI-enabled guests, if that's what you mean. For one thing, that should > in theory allow us to boot Windows guests without needing to spin up > qemu to emulate any devices (since OVMF will be able to access the PV > devices until the Windows PV drivers come up). OK so for Windows x86 HVMLite will need to go the EFI boot route for sure, only it will use OVMF ? > Booting to EFI-enabled > distros is certainly something we want as well. > > But we need an option for dom0, and ideally we'd like an option for > lightweight Linux guests. It's using EFI for those purposes that we're > pushing back on. > > -George > > * I'm saying PVH because I hope when everything is sorted out we can > just call HVMLite PVH again. OK sure, so so long as: * Other OSes don't have to use EFI * We keep a Linux non-EFI lightweight boot mechanism Then the OVMF / EFI route (perhaps alternatives might be minimal EFI emulation) is still a prospect on the table long term. Luis