Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965176AbcDMLMs (ORCPT ); Wed, 13 Apr 2016 07:12:48 -0400 Received: from smtp.eu.citrix.com ([185.25.65.24]:44601 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933443AbcDMLMq (ORCPT ); Wed, 13 Apr 2016 07:12:46 -0400 X-IronPort-AV: E=Sophos;i="5.24,479,1454976000"; d="scan'208";a="18960685" MIME-Version: 1.0 In-Reply-To: <20160413101515.GJ2829@codeblueprint.co.uk> References: <20160406024027.GX1990@wotan.suse.de> <5704D978.1050101@citrix.com> <20160408204032.GR1990@wotan.suse.de> <570B3228.90400@suse.com> <20160413090202.bg2vfdl3iol7eedv@mac> <20160413101515.GJ2829@codeblueprint.co.uk> Date: Wed, 13 Apr 2016 12:12:28 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry From: George Dunlap To: Matt Fleming CC: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Michael Chang , "linux-kernel@vger.kernel.org" , Jim Fehlig , Jan Beulich , "H. Peter Anvin" , Daniel Kiper , X86 ML , =?UTF-8?B?Vm9qdMSbY2ggUGF2bMOtaw==?= , Gary Lin , "xen-devel@lists.xenproject.org" , Jeffrey Cheung , "Charles Arndol" , Stefano Stabellini , joeyli , Borislav Petkov , Boris Ostrovsky , Juergen Gross , Andrew Cooper , Julien Grall , Andy Lutomirski , "Luis R. Rodriguez" , David Vrabel , "Linus Torvalds" Content-Type: text/plain; charset="UTF-8" X-ClientProxiedBy: FTLPEX02CAS02.citrite.net (10.13.99.123) To AMSPEX02CL01.citrite.net (10.69.22.125) X-DLP: AMS1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2164 Lines: 41 On Wed, Apr 13, 2016 at 11:15 AM, Matt Fleming wrote: > For 1. we'd basically be using the PE/COFF file format with the EFI > ABI as an OS agnostic boot protocol, but not as a full firmware > runtime environment. But we still have the issue here that the now the EFI entry point in Linux has to figure out, "Am I running in a full firmware runtime environment, or am I running under Xen?", and then change behavior appropriately. Then we get back to Juergen's comment: "[The EFI proposal] should be evaluated how much of the early EFI boot path would be common to the HVMlite one. What would be gained by using the same entry but having two different boot paths after it?" > 2. is also interesting, though I think less so than 1. I agree that > making OVMF work as a PVH guest is probably the right way to go, even > for Dom0, not least because you'd have a much cleaner/less buggy > implementation than what we see in the real world ;) So rather than just add an extra entry point and a Xen-to-zero-page stub, you're going to ask Xen on dom0 to import a full OVMF binary? Or have the bootloader entries include xen, linux, the initrd, *and* ovmf? That seems a bit extreme. :-) Keep in mind also that PVH needs to support not only the traditional VM use-case (e.g., booting a full distro), but the small service VM usecase (a la unikernels). Booting a traditional distro as a domU via OVMF -> EFI Linux makes sense; it reduces the distro's test burden, and the OVMF doesn't add a lot to the memory or boot time compared to the size and boot time of a full distro. But booting tiny service VMs, sometimes with not even any disk of their own (other than a ramdisk), the extra cost of including OVMF in the guest address space can be a non-negligible addition to the memory requirements and boot-up time. One of the reasons Xen on ARM prioritized getting EFI working for domUs was that a representative from a certain distro vendor made it absolutely clear that *their* distro would *only* support booting via EFI on ARM. But you can still, as I understand it, use uBoot with DT to boot a lightweight domU if you want. -George