From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757341AbcDGSvx (ORCPT ); Thu, 7 Apr 2016 14:51:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:50592 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756807AbcDGSvv (ORCPT ); Thu, 7 Apr 2016 14:51:51 -0400 Date: Thu, 7 Apr 2016 20:51:48 +0200 From: "Luis R. Rodriguez" To: George Dunlap Cc: "Luis R. Rodriguez" , Matt Fleming , Michael Chang , Julien Grall , Jan Beulich , "H. Peter Anvin" , Daniel Kiper , the arch/x86 maintainers , =?utf-8?Q?Vojt=C4=9Bch_Pavl=C3=ADk?= , Gary Lin , xen-devel , Jeffrey Cheung , Charles Arndol , Stefano Stabellini , Jim Fehlig , joeyli , Borislav Petkov , Boris Ostrovsky , Juergen Gross , Andrew Cooper , Linux Kernel Mailing List , Andy Lutomirski , David Vrabel , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Takashi Iwai , jeffm@suse.com, torvalds@linux-foundation.org Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Message-ID: <20160407185148.GL1990@wotan.suse.de> References: <20160406024027.GX1990@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Wed, Apr 06, 2016 at 12:07:36PM +0100, George Dunlap wrote: > On Wed, Apr 6, 2016 at 3:40 AM, Luis R. Rodriguez wrote: > > A huge summary of the discussion over EFI boot option for HVMLite is now on a > > wiki [2], below I'll just provide the outline of the discussion. Consider this a > > request for more public review, feel free to take any of the items below and > > elaborate on it as you see fit. > [snip] > > * Issues with boot x86 boot entries > > * Small x86 zero page stubs > [snip] > > * Points against using EFI > > * Nulling the claimed boot loader effect > > I'm a bit confused about this. You list exactly two arguments against > the proposed stub in the "con" section: > 1. Bootloaders may not be able to use the extra entry point > 2. It's an extra entry point > > And then later, in another section, you actually list the reason #1 is > irrelevant: bootloaders don't matter because the stub is there to boot > from the Xen hypervisor. Forgive me, the private thread was ongoing and I really wanted to capture both sides of the expressed arguments and move to the list any extensions to the discussion, this meant annotating both positions and letting others fill in the gaps to determine if in fact one position was really nullified by the other. First I should state that it is only natural for anyone sensible to have any type of knee-jerk reaction to kick and scream about the idea of adding yet a new x86 entry point for Linux... IMO one should not expect it to be sensible to simply accept yet-another-entry-point to Linux, rather is should be the expected behaviour to have people really dig and ensure they did their homework to ensure that if they are going to add yet-another-entry-point they really validate and have exhausted review of all possible avenues. It was Andrew Coopers's position that boot loaders would not need to be involved, and that would seem to nullify Matt's original position on this. While Andrew's position is right in that perhaps only Xen tools have to deal with the HVMLite specific entry, it would also still mean diverging from ARM's own EFI entry only position, which I'd like to clarify that ARM has no custom Xen entry, we should strive to match that. Anything far from that to me really deserves an explanation, specially if we are going to argue that HVMLite is the best that x86 Xen can do. Ultimately unifying entry approaches for Xen in a streamlined fashion seems like a sensible thing to strive for. Anything we push in the other direction, as small as it can be, should deserve at least a 'hey, wait a minute'... > So the only actual argument you have against the proposed PVH stub in > the linked document is that it's an extra entry point. Then you have not really read the document well, more to the point, EFI's entry already does what the small HVMLite stub does, already provides an existing entry and path to the kernel, so why should we add yet another small stub? 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 ? Another position against small stubs which I listed myself is that we may need more semantics for early boot even if the new HVMLite small stub is added. This remains to be seen. If we are going to add new semantics, it would seem best to use something more standard like EFI configuration tables rather than hack on to x86 further custom semantics. Custom sloppy semantics have proven to be misused, and were ultimately a sloppy mess. To take this further, virtualization semantics are being abused even outside of Xen -- drivers developers may think that just because some semantics are available they can use them to customize drivers to fine tune them for virtualized environments. Even the best of our folks have taken positions to claim certain hacks are *impossible* to change [0], when in fact only 4 days later a completely sensible replacement was found [1], and this as even outside of Xen's situation, so its not only Xen I am careful over here with regards to semantics. If we need early boot code semantics or general kernel semantics for virtualization I want to address that now and I want to be very careful with that given the abuse. I'm doing my part to ensure that we clarify sloppy old semantics on Xen [2], and this effort is actually proving to even pave the path for HVMLite, for instance consider the gains of leveraging use of the legacy devices struct in the future for ACPI_FADT_NO_VGA now, which HVMLite's specification seems to annotate it will use. Clearing out the paravirt_enabled() hack for pnpbios helped push for a right architectural solution to pave the path for this in generic fashion. [0] http://lkml.kernel.org/r/s5hvb4151v1.wl-tiwai@suse.de [1] https://www.spinics.net/lists/alsa-devel/msg48627.html [2] http://lkml.kernel.org/r/1459987594-5434-1-git-send-email-mcgrof@kernel.org > > > * Why use EFI for HVMlite > > * EFI calling conventions are standardized > > * EFI entry generalizes what new HVMLite entry proposes > > * Further semantics may be needed > > * Match Xen ARM's clean solution > > * You don't need full EFI emulation > > * Minimal EFI stubs for guests > > * GetMemoryMap() > > * ExitBootServices() > > * EFI stubs which may be needed for guests > > * Exit() > > * Variable operation functions > > * EFI stubs not needed for guests > > * GetTime()/SetTime() > > * SetVirtualAddressMap() > > * ResetSystem() > > * dom0 EFI > > * domU EFI emulation possibilities > > * Xen implements its own EFI environment for guests > > * Xen uses Tianocore / OVMF > > So rather than make a new entry point which does just the minimal > amount of work to run on a software interface (Xen), you want to take > an interface designed for hardware (EFI) and put in hacks so that it > knows that sometimes some EFI services are not available? The purpose of the discussion is to evaluate the EFI entry as a possible alternative candidate to yet another entry point, from a completely engineering neutral position. > That sounds like it's going to make the EFI path just as unmanageable as the > current PV path. Can you describe how? > Using the EFI entry point would certainly make sense if it was > actually simpler than the proposed extra entry point. But it sounds > like it's going to be more complicated, not only for Xen, but also for > Linux. How so? Please provide specifics. Luis