From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751310AbcDKFMO (ORCPT ); Mon, 11 Apr 2016 01:12:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:54135 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750912AbcDKFMN (ORCPT ); Mon, 11 Apr 2016 01:12:13 -0400 Subject: Re: HVMLite / PVHv2 - using x86 EFI boot entry To: "Luis R. Rodriguez" , David Vrabel , Julien Grall , Stefano Stabellini References: <20160406024027.GX1990@wotan.suse.de> <5704D978.1050101@citrix.com> <20160408204032.GR1990@wotan.suse.de> Cc: Andrew Cooper , Boris Ostrovsky , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Matt Fleming , Charles Arndol , Jim Fehlig , Jan Beulich , Daniel Kiper , "H. Peter Anvin" , x86@kernel.org, Gary Lin , Andy Lutomirski , Borislav Petkov , joeyli , Jeffrey Cheung , Michael Chang , =?UTF-8?Q?Vojt=c4=9bch_Pavl=c3=adk?= , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Linus Torvalds From: Juergen Gross Message-ID: <570B3228.90400@suse.com> Date: Mon, 11 Apr 2016 07:12:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160408204032.GR1990@wotan.suse.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/04/16 22:40, Luis R. Rodriguez wrote: > On Wed, Apr 06, 2016 at 10:40:08AM +0100, David Vrabel wrote: >> On 06/04/16 03:40, Luis R. Rodriguez wrote: >>> >>> * You don't need full EFI emulation >> >> I think needing any EFI emulation inside Xen (which is where it would >> need to be for dom0) is not suitable because of the increase in >> hypervisor ABI. > > Is this because of timing on architecture / design of HVMLite, or > a general position that the complexity to deal with EFI emulation > is too much for Xen's taste ? The Xen hypervisor should be as small as possible. Adding an EFI emulator will be adding quite some code. This should be done after a very thorough evaluation only. > ARM already went the EFI entry way for domU -- it went the OVMF route, > would such a possibility be possible for x86 domU HVMLite ? If not why > not, I mean it would seem to make sense to at least mimic the same type > of early boot environment, and perhaps there are some lessons to be > learned from that effort too. The final solution must be appropriate for dom0, too. So don't try to limit the discussion to domU. If dom0 isn't going to be acceptable there will no need to discuss domU. > Are there some lessons to be learned with ARM's effort? What are they? > If that could be re-done again with any type of cleaner path, what > could that be that could help the x86 side ? > > Although emulating EFI may require work, some folks have pointed out > that the amount of work may not be that much. If that is done can > we instead rely on the same code to replace OVMF to support both > Xen ARM and Xen HVMLite on x86 ? What would be the pros / cons of > this ? > >> I also still do not understand your objection to the current tiny stub. > > Its more of a hypothetical -- can an EFI entry be used instead given > it already does exactly what the new small entry does ? Its also rather > odd to add a new entry without evaluating fully a possible alternative > that would provide the same exact mechanism. The interface isn't the new entry only. It 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? You still need a way to distinguish between bare metal EFI and HVMlite. And Xen needs a way to find out whether a kernel is supporting HVMlite to boot it in the correct mode. > A full technical unbiased evaluation of the different approaches is what I'd > hope we could strive to achieve through discussion and peer review, thinking > and prioritizing ultimately what is best to minimize the impact on Linux > and also help take advantage of the best features possible through both > means. Thinking long term, not immediate short term. Sure. Juergen